GNU bug report logs -
#76407
[GCD] A better name for the default branch
Previous Next
To reply to this bug, email your comments to 76407 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 18 Feb 2025 22:07:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Liliana Marie Prikler <liliana.prikler <at> gmail.com>:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org.
(Tue, 18 Feb 2025 22:07:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Girls do their best now and are preparing. Please watch warmly until it
is ready.
Information forwarded
to
info-guix <at> gnu.org, guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 18 Feb 2025 22:24:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Guix,
this patch introduces GCD 003 “A better name for the default branch”.
I've taken the comments on guix-devel into account (most of them anyway)
and updated the document accordingly. Note that references to GCD 002
are made. That GCD was drafted earlier, but may or may not already be
submitted by the time you read this. Do be patient :)
Cheers
---
003-better-default-branch-name.md | 187 ++++++++++++++++++++++++++++++
1 file changed, 187 insertions(+)
create mode 100644 003-better-default-branch-name.md
diff --git a/003-better-default-branch-name.md b/003-better-default-branch-name.md
new file mode 100644
index 0000000..95952a5
--- /dev/null
+++ b/003-better-default-branch-name.md
@@ -0,0 +1,187 @@
+title: A better name for the default branch
+id: 003
+status: submitted
+discussion: https://issues.guix.gnu.org/76407
+authors: Liliana Marie Prikler
+sponsors: Simon Tournier, Ian Eure, Vagrant Cascadian, Ludovic Courtès
+date: 2025-02-18
+SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
+---
+
+# Summary
+
+Currently, much of Guix's development takes place on the “master”
+branch. This name is neither particularly meaningful nor inclusive;
+choosing to use it may inadvertently alienate potential contributors.
+To mitigate these effects, we should more clearly communicate, what the
+default branch is all about.
+
+# Motivation
+
+It is well known, that Git works with whatever branch name one chooses.
+However, for historical reasons, the default/initial/main branch for
+development used to be “master” — particularly in 2012, when the first
+commit to Guix was made.
+
+Recent versions of Git support arbitrary initial branches and the
+default branch name is subject to change upstream, at least in part
+because the current default — “master” — may be perceived as harmful.
+While the intended meaning is something close to “an original, from
+which copies are made”, there are several other meanings of the word
+that spring to mind more easily, some of have a racist or sexist
+connotation.
+
+One goal of the Guix community is to foster a healthy community around
+the software we use. Using clear language that does not pertain to
+harmful stereotypes is a key towards achieving this goal. Thus, as a
+proactive step, we should rename the default branch.
+
+# Detailed Design
+
+This section explains the chosen solution among the available options,
+the scope of the proposed migration, and a migration path.
+
+## Scope of this document
+
+This document discusses only to change the name of the default branch,
+not to change the branching strategy. Such ideas, e.g. to have a
+“stable” branch containing only bug-fixes and well-tested features
+and an “unstable” or “experimental” branch would need to be discussed
+in a separate document.
+
+## Choice of branch name
+
+In this section, we discuss potential branch names that have been
+considered. The goal is to find a name that Guix contributors, as a
+whole, feel comfortable with.
+
+While this GCD is still being reviewed, new suggestions may be added,
+and benefits and drawbacks for each name discussed. Once this GCD is
+accepted, these benefits and drawbacks shall be shortly summarized,
+and a final decision with a short justification as the one at the end
+of this section shall be the last paragraph of this section.
+
+- The currently used “master” has more than ten different meanings,
+ some of them pertaining to slavery, others to dominance, and yet
+ others merely to skill and expertise. It is understandable that some
+ contributors would feel uncomfortable with this name, given that not
+ all uses are equally frequent.
+
+- The currently proposed alternative “main” has several meanings
+ relating to “importance”, the most obvious being “most important”.
+
+- Other alternatives would be “trunk” as a visual metaphor from
+ which “branches” spawn, and “base” with the same meaning.
+
+- “guix” being the name of the project also serves as an option,
+ albeit one that is not clearly defined (are the other branches
+ not guix as well?)
+
+- Similar to “guix”, “development” merely signifies that some sort
+ of development happens on the branch; a fact that should hold for
+ most, if not all branches.
+
+We choose “main” simply because it is currently the explicit initial
+branch for a git checkout as per `git-fetch` in `(guix build git)`.
+Another name could be chosen by any means that support achieving a
+consensus, e.g. comments on this GCD or a popular vote.
+
+## Manual Updates
+
+Sections 19 (Security Updates) and 22 (Contributing) of the Guix manual
+would need to be reworded to reflect the new default branch. Other
+sections mentioning “master” branches may be reworded at any time
+regardless of this GCD. Some mentions of the word “master” are tied to
+particular services and thus subject to rewording only once upstream
+adopts a different terminology.
+
+## Repository Update Path
+
+For a complete list of repositories associated with the Guix project,
+see GCD 002 ‘Migrating repositories, issues, and patches to Codeberg’.
+Most repositories can rename their default branch with no issue
+(see also Cost of Reverting below).
+
+For Guix itself, we would decide on a **flag day** 14 days after
+acceptance of this GCD at the earliest, and 30 days at the latest.
+On that day, the main development branch would become "main".
+A commit would reflect that by updating:
+
+ 1. the `branch` field in `.guix-channel`;
+ 2. the `branch` field of `%default-guix-channel` in `(guix channels)`;
+ 3. any other reference to the "master" branch of the Guix repository
+ that may appear in the repository (in particular the Manual Updates
+ above).
+
+Following this commit, an entry in `etc/news.scm` would explain the
+migration. The `master` branch would then point at the commit of said
+news entry, and would need to be updated only after said news are
+translated into another language. The `master` branch may keep following
+the `main` branch for a grace period of 30 days anyways.
+
+Even after the `master` branch no longer syncs up to main, it may be
+important to still have it pointing at some commit. Old installation
+media, handcrafted `channels.scm`, external documentation and scripts
+may all still be referring to the `master` branch even long after the
+rename (see also Cost of Reverting below). To ensure that these do
+not fail immediately, the old branch shall not be deleted until
+
+1. at least one year has passed since this GCD has been accepted, AND
+2. enough Guix releases have been made in the meantime, meaning
+ a. at least one major release, OR
+ b. at least three minor releases.
+
+## Continuous Integration
+
+The jobset for the `master` branch would be removed and a jobset for the
+`main` branch with the highest priority and the same set of architectures
+would be created.
+
+## Relation to other Guix Consensus Documents
+
+Since this change has the potential to affect users and contributors in
+ways that will disrupt their workflow for some amount of time as they
+reconfigure their local checkouts to point at the new branch, it should
+best be adopted as the same time as other, similar changes. In particular,
+an adoption at the same time as GCD 002 ‘Migrating repositories, issues,
+and patches to Codeberg’ is desirable.
+
+The repository update path in this GCD is only valid as long as it is
+simultaneously upheld by other, similar GCDs. Again GCD 002 ‘Migrating
+repositories, issues, and patches to Codeberg’ needs to be considered as
+a possibly simultaneous change. For the sake of clarity, the promises
+made in the repository update path w.r.t. the availability of the old
+branch shall not exceed those of any other accepted GCD and instead
+be updated to match.
+
+## Cost of Reverting
+
+This change mostly affects contributors, who would have to run the following
+command once to pull from (and in the case of committers push to) the new
+main branch:
+
+ $ git branch --set-upstream-to <origin>/main
+
+Users of the `guix` CLI would be advised to run `guix pull` again to fetch
+the latest commit from the main branch. Users of old installation media
+(e.g. disk images for version 1.4.0) would continue to use the "master" branch
+and the default channel URL of said installation media until they run
+`guix pull`. A new release may mitigate this annoyance somewhat.
+
+The main branch may be renamed to any other name (including "master") by
+repeating the steps laid out in the Repository Update Path and
+Continuous Integration above, using <name> instead of "main".
+
+# Drawbacks and Open Issues
+
+There is an ongoing political debate as to whether the name “master”,
+standing alone, should be considered harmful. Similar debates may
+well surround other names given enough time and particular
+circumstances. More generally, as language continues to evolve,
+meanings that appear obvious today may no longer remain so in the
+future.
+
+It is unclear, what effect, if any, the name of the default branch has
+to contributor satisfaction. The choice of a name may well appear
+similar to choosing the colour of a bikeshed. What constitutes a
+meaningful branch name will inevitably be a matter of opinion.
--
2.48.1
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 19 Feb 2025 17:22:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> +## Manual Updates
> +
> +Sections 19 (Security Updates) and 22 (Contributing) of the Guix manual
> +would need to be reworded to reflect the new default branch. Other
> +sections mentioning “master” branches may be reworded at any time
> +regardless of this GCD. Some mentions of the word “master” are tied to
> +particular services and thus subject to rewording only once upstream
> +adopts a different terminology.
> +
> +## Repository Update Path
> +
> +For a complete list of repositories associated with the Guix project,
> +see GCD 002 ‘Migrating repositories, issues, and patches to Codeberg’.
> +Most repositories can rename their default branch with no issue
> +(see also Cost of Reverting below).
> +
> +For Guix itself, we would decide on a **flag day** 14 days after
> +acceptance of this GCD at the earliest, and 30 days at the latest.
> +On that day, the main development branch would become "main".
> +A commit would reflect that by updating:
> +
> + 1. the `branch` field in `.guix-channel`;
> + 2. the `branch` field of `%default-guix-channel` in `(guix channels)`;
> + 3. any other reference to the "master" branch of the Guix repository
> + that may appear in the repository (in particular the Manual Updates
> + above).
> +
> +Following this commit, an entry in `etc/news.scm` would explain the
> +migration. The `master` branch would then point at the commit of said
> +news entry, and would need to be updated only after said news are
> +translated into another language. The `master` branch may keep following
> +the `main` branch for a grace period of 30 days anyways.
> +
> +Even after the `master` branch no longer syncs up to main, it may be
> +important to still have it pointing at some commit. Old installation
> +media, handcrafted `channels.scm`, external documentation and scripts
> +may all still be referring to the `master` branch even long after the
> +rename (see also Cost of Reverting below). To ensure that these do
> +not fail immediately, the old branch shall not be deleted until
> +
> +1. at least one year has passed since this GCD has been accepted, AND
> +2. enough Guix releases have been made in the meantime, meaning
> + a. at least one major release, OR
> + b. at least three minor releases.
Thanks for writing this GCD up, I have other comments and thoughts, and
while I'm not against changing the branch name in principle my main
objection is this, I'm not sure we're technically ready (or at least in
a good state) to change the branch name for the default Guix channel.
> + 1. the `branch` field in `.guix-channel`;
This doesn't exist as far as I'm aware?
That record does have a url field, which is important as it means that
Guix can highlight when there is a mismatch between the URL being used
and the contents of the channel.
I think it's worth considering what a similar mechanism might look like
for branch names. Maybe Guix could have a notion of whether it's using
the "primary" branch for a channel (if you pull or time-machine to a
specific --branch, this is ignored), and that record could contain the
name of the primary branch, and then Guix could highlight when the two
differ.
That mechanism would allow for clearer messaging to users, since they
could see it again and again, rather than a news entry which would
usually only be shown once.
> (define-record-type* <channel> channel make-channel
> channel?
> (name channel-name)
> (url channel-url)
> (branch channel-branch (default "master"))
> (commit channel-commit (default #f))
> (introduction channel-introduction (default #f))
> (location channel-location
> (default (current-source-location)) (innate)))
Is changing or removing the channel-branch default in the scope of this
GCD?
I'm in two minds about this. It's just the default, so it's trivial to
change it for the default channel. But ignoring it doesn't seem
consistent with the rest of the proposal.
Additionally, if the guix channel changes, then this might encourage
people managing other channels to make similar changes, and I think
there might be different and potentially more serious technical issues
with managing that change. I think it would be sensible to ensure
there's a good path for channels in general to change branch naming
before making the switch for the Guix channel.
> +Following this commit, an entry in `etc/news.scm` would explain the
> +migration. The `master` branch would then point at the commit of said
> +news entry, and would need to be updated only after said news are
> +translated into another language.
In this scenario, assuming you're suggesting only pushing the news entry
related commits to "master", I think the branches diverging would be
problematic.
Assuming you're using the default channel configuration, if you pull to
one of these commits on "master", which isn't on the new master branch,
then I think the next time you go to pull, you'd hit the downgrade
protections (or at least you should do), since this is exactly the kind
of downgrade attack that it's trying to prevent against. You'd be
pulling a commit which isn't a descendant of the commit you're currently
on.
...
I also haven't even started to think about what implications this would
have for the services I'm involved with maintaining. The data service
instances and the bordeaux build coordinator all have current and
historic references to the "master" branch. In particular, the data
service goes beyond branches being pointers to commits and records the
state of branches over time.
It isn't immediately obvious to me how the data service could be adapted
to handle branches changing name to both capture that a branch may have
never actually pointed at a commit, but that commit is in the history of
the branch in the Git sense. I think with the current behaviour, we'd
have the history of the "master" branch (unless that's deleted), and
then separately the history for the new master (not "master") branch,
but that would start when that branch was cteated, and the two histories
would be separate from the view of the data service, and this
representation seems rather lacking.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 19 Feb 2025 19:02:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
Am Mittwoch, dem 19.02.2025 um 17:21 +0000 schrieb Christopher Baines:
> > + 1. the `branch` field in `.guix-channel`;
>
> This doesn't exist as far as I'm aware?
>
> That record does have a url field, which is important as it means
> that Guix can highlight when there is a mismatch between the URL
> being used and the contents of the channel.
>
> I think it's worth considering what a similar mechanism might look
> like for branch names. Maybe Guix could have a notion of whether it's
> using the "primary" branch for a channel (if you pull or time-machine
> to a specific --branch, this is ignored), and that record could
> contain the name of the primary branch, and then Guix could highlight
> when the two differ.
Nice catch. I did copy the wording from the Codeberg GCD, which talks
about updating URL. If `branch` is not considered by .guix-channel,
that's one field less to update.
> That mechanism would allow for clearer messaging to users, since they
> could see it again and again, rather than a news entry which would
> usually only be shown once.
>
> > (define-record-type* <channel> channel make-channel
> > channel?
> > (name channel-name)
> > (url channel-url)
> > (branch channel-branch (default "master"))
> > (commit channel-commit (default #f))
> > (introduction channel-introduction (default #f))
> > (location channel-location
> > (default (current-source-location)) (innate)))
>
> Is changing or removing the channel-branch default in the scope of
> this GCD?
I think channel-branch should reflect the new default.
> I'm in two minds about this. It's just the default, so it's trivial
> to change it for the default channel. But ignoring it doesn't seem
> consistent with the rest of the proposal.
>
> Additionally, if the guix channel changes, then this might encourage
> people managing other channels to make similar changes, and I think
> there might be different and potentially more serious technical
> issues with managing that change. I think it would be sensible to
> ensure there's a good path for channels in general to change branch
> naming before making the switch for the Guix channel.
Perhaps we could warn channel authors in advance that the default
branch is subject to change and ask them to set "branch" explicitly.
> > +Following this commit, an entry in `etc/news.scm` would explain
> > the
> > +migration. The `master` branch would then point at the commit of
> > said
> > +news entry, and would need to be updated only after said news are
> > +translated into another language.
>
> In this scenario, assuming you're suggesting only pushing the news
> entry related commits to "master", I think the branches diverging
> would be problematic.
The point here is that we don't have to keep master updated
indefinitely, but it should point towards a commit that is also on
main. Denis 'GNUtoo' Carikli has another idea using symbolic
references.
> Assuming you're using the default channel configuration, if you pull
> to one of these commits on "master", which isn't on the new master
> branch, then I think the next time you go to pull, you'd hit the
> downgrade protections (or at least you should do), since this is
> exactly the kind of downgrade attack that it's trying to prevent
> against. You'd be pulling a commit which isn't a descendant of the
> commit you're currently on.
See above.
> ...
>
> I also haven't even started to think about what implications this
> would have for the services I'm involved with maintaining. The data
> service instances and the bordeaux build coordinator all have current
> and historic references to the "master" branch. In particular, the
> data service goes beyond branches being pointers to commits and
> records the state of branches over time.
>
> It isn't immediately obvious to me how the data service could be
> adapted to handle branches changing name to both capture that a
> branch may have never actually pointed at a commit, but that commit
> is in the history of the branch in the Git sense. I think with the
> current behaviour, we'd have the history of the "master" branch
> (unless that's deleted), and then separately the history for the new
> master (not "master") branch, but that would start when that branch
> was cteated, and the two histories would be separate from the view of
> the data service, and this representation seems rather lacking.
Good point, we should add a section talking about the Guix Data
Service.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Thu, 20 Feb 2025 17:26:05 GMT)
Full text and
rfc822 format available.
Message #17 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
A minor comment is to title: “Rename the default branch name“ or “Rename
from master to main”. And not use word as “better”.
The rest is logistical stuff, FWIW.
On Tue, 18 Feb 2025 at 23:14, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:
> +status: submitted
> +discussion: https://issues.guix.gnu.org/76407
> +authors: Liliana Marie Prikler
> +sponsors: Simon Tournier, Ian Eure, Vagrant Cascadian, Ludovic Courtès
> +date: 2025-02-18
Now, it’s submitted, I recommend to push this revision to a dedicated
branch, say ’wip-default-branch-name’ directly to the GCDs repository.
https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git
Well, I did but instead of pushing to it, I only pushed to my personal
copy of the repository:
https://codeberg.org/zimoun/guix-consensus-documents/commits/branch/wip-default-branch-name
Feel free to just fetch and push if it appears to you fine.
Why? Based on the experience of 001, it can quickly become a mess. :-)
There is several revisions in different emails and all becomes harder
and harder to follow. Do I read the last revision? This one? And no
there is this yet another email? And that MUA screwed up the subject…
etc. Hard to follow; especially for the ones who just want to read the
last current revision.
Moreover, it’s more comfortable to read a plain file than a diff, IMHO.
For example, one revision of 001:
https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/0001-rfc-process.md?id=7da54b980efcd23ce662040b00712bd7fa76982e
(It perfectly works with Emacs browser EWW so it works for any browser. ;-))
Last, having all the revisions in a dedicated branch allows to easily
diff between each revision.
My 2 cents. :-)
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
The recommendation is GFDL-1.3-no-invariants-or-later; see [1,2]. And I
think it would be better, no? Maybe you have something specific in
mind?
1: https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/000-template.md?id=c6a594ceb316e23bea975928eb2f40b7df450c94#n8
2: https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/001-gcd-process.md?id=c6a594ceb316e23bea975928eb2f40b7df450c94#n8
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Thu, 20 Feb 2025 18:24:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Donnerstag, dem 20.02.2025 um 18:25 +0100 schrieb Simon Tournier:
> Hi Liliana,
>
> A minor comment is to title: “Rename the default branch name“ or
> “Rename from master to main”. And not use word as “better”.
Okay.
> Now, it’s submitted, I recommend to push this revision to a dedicated
> branch, say ’wip-default-branch-name’ directly to the GCDs
> repository.
> […]
> Feel free to just fetch and push if it appears to you fine.
I fetched and updated; preserving history.
> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-
> > only
>
> The recommendation is GFDL-1.3-no-invariants-or-later; see [1,2].
> And I think it would be better, no? Maybe you have something
> specific in mind?
Nah, I just copied one of the outdated templates D:
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 06:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76407 <at> debbugs.gnu.org (full text, mbox):
There's a (broken) thread discussing this proposal on guix-devel@:
<https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00278.html>
<https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00357.html>
I hope it continues here instead.
Kind regards,
T G-R
Sent on the go. Excuse or enjoy my brevity.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 08:58:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76407 <at> debbugs.gnu.org (full text, mbox):
(Moved discussion to bug number)
Am Donnerstag, dem 20.02.2025 um 23:57 +0100 schrieb Ekaitz Zarraga:
> I don't find this dismissive. At all. I only see a person sharing his
> opinion, which, sadly, I think is pretty hard in this kind of
> subject.
Please educate yourself on right-wing dogwhistles then. I will quote
one for context:
Am Dienstag, dem 18.02.2025 um 06:50 -0900 schrieb Christopher Howard:
> DEI proponents have a compulsive desire to eradicate from society and
> language anything that has some vague connection to what they find
> displeasing.
Am Donnerstag, dem 20.02.2025 um 23:57 +0100 schrieb Ekaitz Zarraga:
> I made questions, and no one has give me an answer that is anything
> more than a feeling of something they don't suffer themselves.
> Nobody, specially not even a single black person, who were supposed
> to be the reason for all this, has ever told me this is something
> they feel represented with this change.
First, this is not just about black people, but any group of people
that feels uncomfortable with the term "master" being used in this
context.
Second, people can care about matters they are not personally affected
by. It's called having empathy.
Third, people who feel represented by this change have no obligation to
tell you that in this level of detail. In fact, given the attitudes of
some people replying to this GCD, it would be wiser for them not to.
> If a change is going to negatively affect the users of the software I
> make I need to justify it properly.
>
> Until this very moment, nobody did. Even if I am actually very
> concerned about human rights, I find the arguments exposed not only
> in this thread but also in the original Git branch naming discussion
> very poor.
I think you are — intentionally or otherwise — overestimating the
negative effects of the proposed change in order to construct a world
where it is infeasible.
> [T]hose who oppose them have to justify them to death,
> while being respectful, but also carefully not to sound like Nazis to
> them.
Well, they could at least be courteous about it and not scream "DEI"
and "woke" at a proposed change they do not like or something.
‾\_(ツ)_/‾
> More specifically in Guix, I'm still yet to find a good thing coming
> from this change, and there are many cons already. It's a net
> negative change from a technical perspective.
There is little technical debate to be had about this change being
feasible. Git supports named branches — it always has — and
sufficiently recent versions also support an initial branch that isn't
"master".
There can be a discussion of what steps would need to be made in Guix
particularly to accommodate this change. This concerns locations in
the code and documentation that assume "master" to be the default name
of a Guix channel, particularly the default Guix channel (i.e. "guix").
The issue of what to name the default branch is entirely a
political/organizational one, one in which we cannot avoid showing the
colour of our hearts as we debate.
Am Donnerstag, dem 20.02.2025 um 14:44 -0900 schrieb Christopher
Howard:
> Also, I think that the word "main" is just as bigoted and non-
> inclusive as "master". I mean, what can be more demeaning than saying
> that one branch is the "main" one and in some sense more important
> than the others?
Perhaps one branch being the "master record", the only trusted,
authentic source, whereas all others — particularly those that had
changes applied to them — are untrusted and/or inauthentic by
distinction.
In practice, the main branch requires certain guarantees that other
branches do not: team branches can (and arguably should) routinely be
rebased on the main branch. If the main branch were to be rebased,
however, all users would receive an error upon pull.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 10:50:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
On 2025-02-21 09:57, Liliana Marie Prikler wrote:
> (Moved discussion to bug number)
>
> Am Donnerstag, dem 20.02.2025 um 23:57 +0100 schrieb Ekaitz Zarraga:
>> I don't find this dismissive. At all. I only see a person sharing his
>> opinion, which, sadly, I think is pretty hard in this kind of
>> subject.
> Please educate yourself on right-wing dogwhistles then. I will quote
> one for context:
>
> Am Dienstag, dem 18.02.2025 um 06:50 -0900 schrieb Christopher Howard:
>> DEI proponents have a compulsive desire to eradicate from society and
>> language anything that has some vague connection to what they find
>> displeasing.
Telling people to educate themselves could also be offensive and all,
but you don't hesitate to do it. Do you actually care about being
welcoming? Just food for thought.
Listen, I don't give a shit about the political views of Christopher, or
whatever you think about them. People has the right to be right-wingers,
weather we like it or not.
Just that is enough to discard somebody's opinion? Is that diversity?
Doesn't "right-with dog-whistle" sound a little bit like "woke". To me,
it does. Keep throwing names to the table, while nobody else in the
world cares about your left vs right debate.
We are making software for people. For all people that wants to use it.
Bad news: many of them are right wingers. And some of them are between
us. And I believe they are also welcome here, as long as they don't
mistreat any other person (the same as the left wingers or the no-wingers).
> Am Donnerstag, dem 20.02.2025 um 23:57 +0100 schrieb Ekaitz Zarraga:
>> I made questions, and no one has give me an answer that is anything
>> more than a feeling of something they don't suffer themselves.
>> Nobody, specially not even a single black person, who were supposed
>> to be the reason for all this, has ever told me this is something
>> they feel represented with this change.
> First, this is not just about black people, but any group of people
> that feels uncomfortable with the term "master" being used in this
> context.
Uncomfortable?
I am uncomfortable writing in english, as it is my third language.
Should we change the language to spanish, my mother tongue?
There's a lot of people in the basque community that get angry when a
basque talks in spanish, so those are going to be uncomfortable... We
should change to Basque! That will make everybody happy.
The term "master" being used in this context does not have anything to
do with anything that should make anyone uncomfortable. Isn't the word
"git" itself way worse in that sense?
Guix is a Catalan surname, maybe some of them are uncomfortable by its
name, we should change it too!
> Second, people can care about matters they are not personally affected
> by. It's called having empathy.
Well, people can also invent a problem, as I just did. That's not empathy.
> Third, people who feel represented by this change have no obligation to
> tell you that in this level of detail. In fact, given the attitudes of
> some people replying to this GCD, it would be wiser for them not to.
Saying "I support" is more than enough, but I would really want to know
if they actually exist, because I'd like to make sure we are doing this
for something.
What do you think it's going to happen if they speak their truth? Are
they going to be harassed? By who?
The only thing I see here is people saying they don't like the change
being mistreated as they were some kind of right wing scum.
>> If a change is going to negatively affect the users of the software I
>> make I need to justify it properly.
>>
>> Until this very moment, nobody did. Even if I am actually very
>> concerned about human rights, I find the arguments exposed not only
>> in this thread but also in the original Git branch naming discussion
>> very poor.
> I think you are — intentionally or otherwise — overestimating the
> negative effects of the proposed change in order to construct a world
> where it is infeasible.
No, I don't think it's infeasible. It is actually very feasible, you
just need to change the branch name and push. Done.
The problem is that some people already shared their concern, while I
don't see any justification for the change that has the same weight.
>> More specifically in Guix, I'm still yet to find a good thing coming
>> from this change, and there are many cons already. It's a net
>> negative change from a technical perspective.
> There is little technical debate to be had about this change being
> feasible. Git supports named branches — it always has — and
> sufficiently recent versions also support an initial branch that isn't
> "master".
>
> There can be a discussion of what steps would need to be made in Guix
> particularly to accommodate this change. This concerns locations in
> the code and documentation that assume "master" to be the default name
> of a Guix channel, particularly the default Guix channel (i.e. "guix").
>
> The issue of what to name the default branch is entirely a
> political/organizational one, one in which we cannot avoid showing the
> colour of our hearts as we debate.
I disagree. Very strongly.
It's you, and those who think like you, who is charging this word with
some political value it doesn't have.
I am NOT in favor of slavery and I am NOT against making everybody's
live easier. (and interestingly I'm probably in the same side of the
political spectrum as you are).
What I discuss here is that I don't think there is any kind of relation
with changing this stupid word and making the world a better place.
That doesn't show the color of my heart, because I'm just trying to be
rational here.
We serve the world. Our political views (or how you call them: the color
of our heart) are very narrow. I don't see any kind of internationalist
approach here, we are just swallowing whatever garbage an US company
throws to us and tells us is good.
This proposal is very US-centric, and goes according to their values,
and religion. That's why it became popular there.
Thankfully for many, the world is not the United States of America. In
my view there's nothing shameful in words, even in the F word or in the
N word. The wrong in is in the intention.
The intention you have here Liliana is good. But I don't think Linus
Torvalds called the branch "master" thinking about slavery or as a way
to shame people, and I don't think removing the word is really going to
change anything. But will do some (maybe little) damage in Guix, as some
people already discussed.
If we need to make the life of a couple US-Americans a little bit
uncomfortable in order to keep our software working as intended, so be
it. I am uncomfortable every time I need to speak in english here (a
reminder of how the USA imperialism is forced upon me), and here we are.
---
This debate is draining me, so consider me done here.
In the end, you are trying to make this look like those who oppose the
change are not welcoming neither empathetic, and that's bullshit.
The funny thing of all this is that the times I have felt unwelcome, and
I have been gaslighted in this community, and I have seen
passive-aggressive answers was coming from you, Liliana, and I have been
trying to avoid interacting with you for long because of it.
I don't like this change, and I don't like to see that you are trying to
make this whole thing look like we are bad people.
I am not convinced.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 12:57:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Freitag, dem 21.02.2025 um 11:48 +0100 schrieb Ekaitz Zarraga:
> > Third, people who feel represented by this change have no
> > obligation to tell you that in this level of detail. In fact,
> > given the attitudes of some people replying to this GCD, it would
> > be wiser for them not to.
>
> Saying "I support" is more than enough, but I would really want to
> know if they actually exist, because I'd like to make sure we are
> doing this for something.
Given that I've received four sponsors over the course of a weekend,
I'm not really concerned that this benefits no one.
> I don't think it's infeasible. It is actually very feasible, you
> just need to change the branch name and push. Done.
>
> The problem is that some people already shared their concern, while I
> don't see any justification for the change that has the same weight.
So you mean that people have non-technical concerns about the name of
the default branch? I won't repeat your arguments, but yes, I
understand that you want it to remain at "master".
I have listed some issues that this GCD does not address at the end of
the document. To my knowledge, these are the points raised so far that
it cannot address. If you would like me to add another that is within
the scope of the document, do let me know.
> I don't see any kind of internationalist approach here, we are just
> swallowing whatever garbage an US company throws to us and tells us
> is good.
>
> This proposal is very US-centric, and goes according to their values,
> and religion. That's why it became popular there.
Even assuming that this is true, how is this any different from
swallowing garbage, that some US entity told us 10 years ago is good
(i.e. the status quo)?
I also don't think there is a clear mapping between "thing happening in
the USA/outside the USA" and "thing good/bad". The world is more
complex than that, with some nuance to it.
In any case, I think that the Guix community can – using the recently
established process for doing so – reach a consensus on what the name
of the default branch shall be.
> I don't think Linus Torvalds called the branch "master" thinking
> about slavery or as a way to shame people,
This is not about Linus' intentions. People can have opinions that
differ from those of Linus Torvalds.
> I don't think removing the word is really going to change anything.
Acknowledged.
> But will do some (maybe little) damage in Guix, as some people
> already discussed.
What damage will it to, exactly? So far, I think the concerns are
- a mild inconvenience to contributors checking out the new default
branch
- a mild inconvenience to channel authors, requiring them to explicitly
state their default branch
- an almost user-invisible change possibly causing them to run
`guix pull` twice on a particularly old checkout
Perhaps, you also consider adoption of this change to result in
reputational damage to Guix. If so, why?
> If we need to make the life of a couple US-Americans a little bit
> uncomfortable in order to keep our software working as intended, so
> be it.
Do we need though? Or are you simply resisting change for the sake of
doing so? Note that this assertion also contradicts the one you made
earlier that this change can "easily be pushed and done".
> I am uncomfortable every time I need to speak in english here (a
> reminder of how the USA imperialism is forced upon me), and here we
> are.
Wir können auch Deutsch miteinander reden, damit hätte ich kein
Problem.
> Consider me done here.
Okay.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 13:36:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello.
Since guix-help was copied on this proposal, I would try to help too.
The word "master" is a metaphor for a subordinate relation. It serves
its technical purpose. It became a boilerplate. So, it is easily
recognisable by sophisticated audience, which makes it difficult to
argue that it is ambiguous for practical purposes. However, being
boilerplate, it does not accurately describe the purpose of that git
branch in guix. For instance, I am not convinced that other branches
being "subordinate" to that branch in some way is its defining
characteristic.
I would argue that the word "main" is also irrelevant because it
describes a relation of importance, which does not seem to be relevant
to the development cycle, neither to building a community. So, the
proposed change to "main" is suboptimal from my perspective.
I would propose the word "release" instead. The word is already widely
used in guix to refer to published source code of stable versions of
software, so it should be easily recognisable and describe the purpose
of the branch accurately. This is the branch where the guix code is
realeased and where the guix releases are published.
I would note that, as long as a better metaphor can be afforded and
considering that the matter has already been considered important
enough to bring it up, discussing the background of the proposal does
not appear to be productive or relevant for arriving at a solution.
Roman
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 19:24:08 GMT)
Full text and
rfc822 format available.
Message #38 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Tue, 18 Feb 2025 at 23:14, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:
> +## Repository Update Path
> +
> +For a complete list of repositories associated with the Guix project,
> +see GCD 002 ‘Migrating repositories, issues, and patches to Codeberg’.
> +Most repositories can rename their default branch with no issue
> +(see also Cost of Reverting below).
> +
> +For Guix itself, we would decide on a **flag day** 14 days after
> +acceptance of this GCD at the earliest, and 30 days at the latest.
> +On that day, the main development branch would become "main".
> +A commit would reflect that by updating:
> +
> + 1. the `branch` field in `.guix-channel`;
> + 2. the `branch` field of `%default-guix-channel` in `(guix channels)`;
> + 3. any other reference to the "master" branch of the Guix repository
> + that may appear in the repository (in particular the Manual Updates
> + above).
> +
> +Following this commit, an entry in `etc/news.scm` would explain the
> +migration. The `master` branch would then point at the commit of said
> +news entry, and would need to be updated only after said news are
> +translated into another language. The `master` branch may keep following
> +the `main` branch for a grace period of 30 days anyways.
> +
> +Even after the `master` branch no longer syncs up to main, it may be
> +important to still have it pointing at some commit. Old installation
> +media, handcrafted `channels.scm`, external documentation and scripts
> +may all still be referring to the `master` branch even long after the
> +rename (see also Cost of Reverting below). To ensure that these do
> +not fail immediately, the old branch shall not be deleted until
> +
> +1. at least one year has passed since this GCD has been accepted, AND
> +2. enough Guix releases have been made in the meantime, meaning
> + a. at least one major release, OR
> + b. at least three minor releases.
My current profile is:
$ guix describe
Generation 8 Sep 09 2024 15:14:29 (current)
guix 056910e
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 056910ec864cb7cf3225a0c27679d94405db7dcd
And many people upgrade guix-daemon less than once a year. :-)
My point is: I’m not sure that a grace period of 30 days will be enough
considering the time to spread the word. But, hey we need to bound
somewhere. :-)
Therefore, maybe we could imagine that the last commit pushed master
introduce a double pull.
Assume I still run this 056910e and we are after the grace period. I
run “guix pull” so it fetch the last commit of master. Now, when I run
again “guix pull”, I will get the last commit of main. This second pull
could be transparent for me.
In other words, I still run this 056910e and we are after the grace
period, then when running “guix pull”, I automatically get the latest
up-to-date commit of main. Obviously, I pay the unavoidable price of a
first pull but under the hood pull.
This might avoid: Oops why don’t I get the last? Because you’re after
the grace period. :-)
I don’t know if my suggestion is worth.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 19:57:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi
Am Freitag, dem 21.02.2025 um 19:16 +0100 schrieb Simon Tournier:
> My current profile is:
>
> $ guix describe
> Generation 8 Sep 09 2024 15:14:29 (current)
> guix 056910e
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: 056910ec864cb7cf3225a0c27679d94405db7dcd
>
> And many people upgrade guix-daemon less than once a year. :-)
>
> My point is: I’m not sure that a grace period of 30 days will be
> enough considering the time to spread the word. But, hey we need to
> bound somewhere. :-)
I put one month there as an optimistic estimate :)
We do have to talk about all the numbers used there as to whether they
are realistic, whether we should be keeping somethings for longer and
whether we can keep them for longer.
> Therefore, maybe we could imagine that the last commit pushed master
> introduce a double pull.
>
> Assume I still run this 056910e and we are after the grace period. I
> run “guix pull” so it fetch the last commit of master. Now, when I
> run again “guix pull”, I will get the last commit of main. This
> second pull could be transparent for me.
I don't think we should do this for two reasons:
First, the "double pull" commit would be introduced to master only,
which would break authentication of the main branch pulled this way.
Second, we would have to break Guix itself to introduce arbitrary code
execution for this particular code 😉
Perhaps instead, we can on the Git side "redirect" the master branch to
main. This would avoid the double pull, and it would be truly
transparent. Perhaps the following sequence of commands would achieve
just that. (CC'ing Denis for their expertise)
Am Mittwoch, dem 19.02.2025 um 02:12 +0100 schrieb Denis 'GNUtoo'
Carikli:
> $ git checkout origin/master -b temporary
> $ git push origin HEAD:main
> $ ssh root <at> server
> $ cd /path/to/repository.git
> $ git symbolic-ref HEAD refs/heads/main # Change the main branch
> $ git symbolic-ref refs/heads/master refs/heads/main # Make master
> point to main
> This might avoid: Oops why don’t I get the last? Because you’re
> after the grace period. :-)
>
> I don’t know if my suggestion is worth.
Fair point. Double-pulling is a source of annoyance in other package
managers, so we should do our best not to make it affect too many
users.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Feb 2025 21:02:03 GMT)
Full text and
rfc822 format available.
Message #44 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> Therefore, maybe we could imagine that the last commit pushed master
> introduce a double pull.
I believe I understand what it's trying to achieve (and believe it is
worthwhile), but I struggled to understand how this would be technically
achieved. Could you please share the technical details of this specific
part?
--
Suhail
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Feb 2025 14:44:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> skribis:
> +For Guix itself, we would decide on a **flag day** 14 days after
> +acceptance of this GCD at the earliest, and 30 days at the latest.
> +On that day, the main development branch would become "main".
> +A commit would reflect that by updating:
> +
> + 1. the `branch` field in `.guix-channel`;
> + 2. the `branch` field of `%default-guix-channel` in `(guix channels)`;
> + 3. any other reference to the "master" branch of the Guix repository
> + that may appear in the repository (in particular the Manual Updates
> + above).
Consider this scenario: I have a machine that I upgrade once every two
months. By the time the switchover is done, my machine still has
‘master’ in its ‘%default-guix-channel’ in its Guix. Thus, when I run
‘guix pull’, I’ll end up pulling ‘master’, which (the GCD does not
clarify this) will either fail because the branch has been removed
altogether, or will give me an old snapshot.
Thus, I think the GCD should propose to keep updating the ‘master’
branch as a mirror of ‘main’ for, say, a year (a cron job can take care
of that).
Also, instead of changing the ‘branch’ field, I would suggest adopting
and finalizing <https://issues.guix.gnu.org/49252> and leaving ‘branch’
unset so that the server-side default branch is taken.
>+## Choice of branch name
I’m not convinced this section is necessary. :-)
> +The repository update path in this GCD is only valid as long as it is
> +simultaneously upheld by other, similar GCDs. Again GCD 002 ‘Migrating
> +repositories, issues, and patches to Codeberg’ needs to be considered as
> +a possibly simultaneous change.
I don’t think this has to be simultaneous: both changes bring the
potential for breakage if we’re not careful enough, but it’s probably
best to deal with a single class of breakage at a time.
Also, perhaps clarify that this GCD is valid whether or not GCD 002 is
adopted.
Apart from that, it LGTM!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Feb 2025 14:45:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Liliana Marie Prikler <liliana.prikler <at> gmail.com> skribis:
> + 1. the `branch` field in `.guix-channel`;
I just realized: there’s no ‘branch’ field in ‘.guix-channel’.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Feb 2025 15:48:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo’,
Am Sonntag, dem 23.02.2025 um 15:42 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler <at> gmail.com> skribis:
>
> > +For Guix itself, we would decide on a **flag day** 14 days after
> > +acceptance of this GCD at the earliest, and 30 days at the latest.
> > +On that day, the main development branch would become "main".
> > +A commit would reflect that by updating:
> > +
> > + 1. the `branch` field in `.guix-channel`;
> > + 2. the `branch` field of `%default-guix-channel` in `(guix
> > channels)`;
> > + 3. any other reference to the "master" branch of the Guix
> > repository
> > + that may appear in the repository (in particular the Manual
> > Updates
> > + above).
>
> Consider this scenario: I have a machine that I upgrade once every
> two months. By the time the switchover is done, my machine still has
> ‘master’ in its ‘%default-guix-channel’ in its Guix. Thus, when I
> run ‘guix pull’, I’ll end up pulling ‘master’, which (the GCD does
> not clarify this) will either fail because the branch has been
> removed altogether, or will give me an old snapshot.
Actually, the GCD does specify this:
> Even after the `master` branch no longer syncs up to main, it may be
> important to still have it pointing at some commit. Old installation
> media, handcrafted `channels.scm`, external documentation and scripts
> may all still be referring to the `master` branch even long after the
> rename (see also Cost of Reverting below). To ensure that these do
> not fail immediately, the old branch shall not be deleted until
>
> 1. at least one year has passed since this GCD has been accepted, AND
> 2. enough Guix releases have been made in the meantime, meaning
> a. at least one major release, OR
> b. at least three minor releases.
> Thus, I think the GCD should propose to keep updating the ‘master’
> branch as a mirror of ‘main’ for, say, a year (a cron job can take
> care of that).
Fair enough. Keeping it updated for one year and then phasing it out
should give folks more time to adopt.
> Also, instead of changing the ‘branch’ field, I would suggest
> adopting and finalizing <https://issues.guix.gnu.org/49252> and
> leaving ‘branch’ unset so that the server-side default branch is
> taken.
SGTM.
> > +## Choice of branch name
>
> I’m not convinced this section is necessary. :-)
How do we achieve consensus on the proposed name itself, then?
> > +The repository update path in this GCD is only valid as long as it
> > is
> > +simultaneously upheld by other, similar GCDs. Again GCD 002
> > ‘Migrating
> > +repositories, issues, and patches to Codeberg’ needs to be
> > considered as
> > +a possibly simultaneous change.
>
> I don’t think this has to be simultaneous: both changes bring the
> potential for breakage if we’re not careful enough, but it’s probably
> best to deal with a single class of breakage at a time.
Perhaps I am missing something crucial here, but IIUC most breakages
would result from the same record; with just one field between them.
Since most configuration ends up being "fire and forget", reducing the
number of times they need to be edited sounds like a benefit to me.
> Also, perhaps clarify that this GCD is valid whether or not GCD 002
> is adopted.
Sure.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Feb 2025 22:08:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hello,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> skribis:
> Actually, the GCD does specify this:
Oh right, sorry.
>> Even after the `master` branch no longer syncs up to main, it may be
>> important to still have it pointing at some commit. Old installation
>> media, handcrafted `channels.scm`, external documentation and scripts
>> may all still be referring to the `master` branch even long after the
>> rename (see also Cost of Reverting below). To ensure that these do
>> not fail immediately, the old branch shall not be deleted until
>>
>> 1. at least one year has passed since this GCD has been accepted, AND
>> 2. enough Guix releases have been made in the meantime, meaning
>> a. at least one major release, OR
>> b. at least three minor releases.
Perfect! Since the notion of major/minor release is fuzzy in Guix, I’d
suggest something like:
2. two or more releases were made in the meantime.
>> > +## Choice of branch name
>>
>> I’m not convinced this section is necessary. :-)
> How do we achieve consensus on the proposed name itself, then?
‘main’ is an established and non-controversial name in this context,
which is why I thought we could omit the section. It’s no big deal
though, we can keep it too.
>> I don’t think this has to be simultaneous: both changes bring the
>> potential for breakage if we’re not careful enough, but it’s probably
>> best to deal with a single class of breakage at a time.
> Perhaps I am missing something crucial here, but IIUC most breakages
> would result from the same record; with just one field between them.
> Since most configuration ends up being "fire and forget", reducing the
> number of times they need to be edited sounds like a benefit to me.
Hmm yes, maybe you’re right. The wording says “possibly simultaneous
change” so that leaves room.
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 25 Feb 2025 18:35:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Fri, Feb 21, 2025 at 03:35:20PM +0200, Roman Riabenko via Guix-patches via wrote:
> I would propose the word "release" instead. The word is already widely
> used in guix to refer to published source code of stable versions of
> software, so it should be easily recognisable and describe the purpose
> of the branch accurately. This is the branch where the guix code is
> realeased and where the guix releases are published.
As I think your message highlights, it's not easy to come up with good
names for things like this. And the harder you think about it, the
harder it becomes.
I think that most of the proposed names for this branch (master, main,
trunk, base) are good enough.
'stable' and 'unstable' are too semantically specific to be accurate,
and 'development' is too long :)
But in my opinion, 'release' is not as good, because we already use the
word "release" to mean something that's different from the 'master'
branch.
Although, our "releases" and our 'master' branch are both released upon
the world with the suggestion that they should be used, unlike our other
Git branches, so there is some similarity too.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 25 Feb 2025 18:36:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 28 Feb 2025 15:47:03 GMT)
Full text and
rfc822 format available.
Message #65 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Tue, Feb 18, 2025 at 5:24 PM Liliana Marie Prikler
<liliana.prikler <at> gmail.com> wrote:
>
> Hi Guix,
>
> this patch introduces GCD 003 “A better name for the default branch”.
> I've taken the comments on guix-devel into account (most of them anyway)
> and updated the document accordingly. Note that references to GCD 002
> are made. That GCD was drafted earlier, but may or may not already be
> submitted by the time you read this. Do be patient :)
Thank you for this submission.
I have yet to meet someone taking passive offense at the "master"
branch but I do purposely mispronounce Guix from the project's
pejorative. Perhaps I can offer that as a future GCD.
And if we are to be offended, why whitewash history? We live
privileged lives in the most privileged nations during the most
privileged time in history. This is not the default state of the
world, to die of old-age peacefully in one's sleep. All of our peoples
were slaves, and all were slavers. More Europeans were trafficked to
Africa in the Barbary slave trade than Africans to America in the
North Atlantic slave trade. Only one of those two peoples survives.
Can we find greater but narrower consensus around the practical
motivation that 1) most users leave unchanged the git default "main",
therefore "master" will become increasingly uncommon and unexpected,
2) the choice of "main" is masterfully similar when tab-completing or
looking through a sorted list of refs, and 3) the move to Codeberg
presents a hopefully rare opportunity combine disruptive changes? We
do not need a comprehensive motivation if we can find consensus on the
outcome.
Greg
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 02 Mar 2025 16:53:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> Hi Guix,
>
> this patch introduces GCD 003 “A better name for the default branch”.
> I've taken the comments on guix-devel into account (most of them anyway)
> and updated the document accordingly. Note that references to GCD 002
> are made. That GCD was drafted earlier, but may or may not already be
> submitted by the time you read this. Do be patient :)
>
> Cheers
>
> ---
> 003-better-default-branch-name.md | 187 ++++++++++++++++++++++++++++++
> 1 file changed, 187 insertions(+)
> create mode 100644 003-better-default-branch-name.md
>
> diff --git a/003-better-default-branch-name.md b/003-better-default-branch-name.md
> new file mode 100644
> index 0000000..95952a5
> --- /dev/null
> +++ b/003-better-default-branch-name.md
> @@ -0,0 +1,187 @@
> +title: A better name for the default branch
> +id: 003
> +status: submitted
> +discussion: https://issues.guix.gnu.org/76407
> +authors: Liliana Marie Prikler
> +sponsors: Simon Tournier, Ian Eure, Vagrant Cascadian, Ludovic Courtès
> +date: 2025-02-18
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> +---
> +
> +# Summary
> +
> +Currently, much of Guix's development takes place on the “master”
> +branch. This name is neither particularly meaningful nor inclusive;
> +choosing to use it may inadvertently alienate potential contributors.
> +To mitigate these effects, we should more clearly communicate, what the
> +default branch is all about.
> +
> +# Motivation
> +
> +It is well known, that Git works with whatever branch name one chooses.
> +However, for historical reasons, the default/initial/main branch for
> +development used to be “master” — particularly in 2012, when the first
> +commit to Guix was made.
> +
> +Recent versions of Git support arbitrary initial branches and the
> +default branch name is subject to change upstream, at least in part
> +because the current default — “master” — may be perceived as harmful.
> +While the intended meaning is something close to “an original, from
> +which copies are made”, there are several other meanings of the word
> +that spring to mind more easily, some of have a racist or sexist
> +connotation.
> +
> +One goal of the Guix community is to foster a healthy community around
> +the software we use. Using clear language that does not pertain to
> +harmful stereotypes is a key towards achieving this goal. Thus, as a
> +proactive step, we should rename the default branch.
Was there any study or statistics about this topic?
The two black people I have asked consider the whole "master -> main"
branch rename ridiculous, and me, descendant of people after who the
Slavery institute is named (Slavs), also do not care. So I am curious
whether there are any hard data on this topic.
> +
> +# Detailed Design
> +
> +This section explains the chosen solution among the available options,
> +the scope of the proposed migration, and a migration path.
> +
> +## Scope of this document
> +
> +This document discusses only to change the name of the default branch,
> +not to change the branching strategy. Such ideas, e.g. to have a
> +“stable” branch containing only bug-fixes and well-tested features
> +and an “unstable” or “experimental” branch would need to be discussed
> +in a separate document.
> +
> +## Choice of branch name
> +
> +In this section, we discuss potential branch names that have been
> +considered. The goal is to find a name that Guix contributors, as a
> +whole, feel comfortable with.
> +
> +While this GCD is still being reviewed, new suggestions may be added,
> +and benefits and drawbacks for each name discussed. Once this GCD is
> +accepted, these benefits and drawbacks shall be shortly summarized,
> +and a final decision with a short justification as the one at the end
> +of this section shall be the last paragraph of this section.
> +
> +- The currently used “master” has more than ten different meanings,
> + some of them pertaining to slavery, others to dominance, and yet
> + others merely to skill and expertise. It is understandable that some
> + contributors would feel uncomfortable with this name, given that not
> + all uses are equally frequent.
> +
> +- The currently proposed alternative “main” has several meanings
> + relating to “importance”, the most obvious being “most important”.
Since this GCD is all about feelings, let me point out that some people
do have negative feelings about the "main" as well. It is a politically
charged name, so I am not sure it satisfies the goal of "Guix
contributors, as a whole, feel comfortable with".
> +
> +- Other alternatives would be “trunk” as a visual metaphor from
> + which “branches” spawn, and “base” with the same meaning.
> +
> +- “guix” being the name of the project also serves as an option,
I like this one.
> + albeit one that is not clearly defined (are the other branches
> + not guix as well?)
But other branches are not Guix. If someone tells me "pull the latest
Guix", I would assume that means master branch (or whatever the new name
would be). I do not think anyone would go to the conclusion "oh, latest
Guix must mean rust-team branch, because it is also a Guix".
In my eyes other branches are not Guix, they are what Guix can become
one day.
> +
> +- Similar to “guix”, “development” merely signifies that some sort
> + of development happens on the branch; a fact that should hold for
> + most, if not all branches.
> +
> +We choose “main” simply because it is currently the explicit initial
> +branch for a git checkout as per `git-fetch` in `(guix build git)`.
> +Another name could be chosen by any means that support achieving a
> +consensus, e.g. comments on this GCD or a popular vote.
> +
> +## Manual Updates
> +
> +Sections 19 (Security Updates) and 22 (Contributing) of the Guix manual
> +would need to be reworded to reflect the new default branch. Other
> +sections mentioning “master” branches may be reworded at any time
> +regardless of this GCD. Some mentions of the word “master” are tied to
> +particular services and thus subject to rewording only once upstream
> +adopts a different terminology.
> +
> +## Repository Update Path
> +
> +For a complete list of repositories associated with the Guix project,
> +see GCD 002 ‘Migrating repositories, issues, and patches to Codeberg’.
> +Most repositories can rename their default branch with no issue
> +(see also Cost of Reverting below).
> +
> +For Guix itself, we would decide on a **flag day** 14 days after
> +acceptance of this GCD at the earliest, and 30 days at the latest.
> +On that day, the main development branch would become "main".
> +A commit would reflect that by updating:
> +
> + 1. the `branch` field in `.guix-channel`;
> + 2. the `branch` field of `%default-guix-channel` in `(guix channels)`;
> + 3. any other reference to the "master" branch of the Guix repository
> + that may appear in the repository (in particular the Manual Updates
> + above).
> +
> +Following this commit, an entry in `etc/news.scm` would explain the
> +migration. The `master` branch would then point at the commit of said
> +news entry, and would need to be updated only after said news are
> +translated into another language.
Just to make sure, the "update" here refers to syncing the master branch
to what main is? So the histories would not diverge, it is just the
master would be behind. Is that correct?
> The `master` branch may keep following
> +the `main` branch for a grace period of 30 days anyways.
> +
> +Even after the `master` branch no longer syncs up to main, it may be
> +important to still have it pointing at some commit. Old installation
> +media, handcrafted `channels.scm`, external documentation and scripts
> +may all still be referring to the `master` branch even long after the
> +rename (see also Cost of Reverting below). To ensure that these do
> +not fail immediately, the old branch shall not be deleted until
Is there a reason to delete it at all? It will not be prominently
displayed anywhere, it would not be updated anymore, so is there any
harm (even to those people who would supposedly get offended by the
current branch name) if it just stays there? Only place where it would
be visible is listing all remote branches, which seems... acceptable?
Having it will allow even old setups to update, at the cost of double
pull.
Or, pushing bit further, is there a reason to not keep it updated? So
that people just can pick branch they feel the most comfortable with?
> +
> +1. at least one year has passed since this GCD has been accepted, AND
> +2. enough Guix releases have been made in the meantime, meaning
> + a. at least one major release, OR
> + b. at least three minor releases.
Given our current release cadence, this basically means the branch stays
forever, so you just as well may say so.
One thing I am not sure about are Guix packages in distributions. For
example, I do not know whether Debian would update Guix to new version
in already released version. So if Trixie is released with current
1.4.0, and we than make a 3 minor releases and delete the master branch,
will Debian users still be able to pull? (I think we have Debian
developer taking care of Guix here on the list, so maybe he can chime
in.)
Not sure what other distributions package Guix, and whether you care
about them in general.
> +
> +## Continuous Integration
> +
> +The jobset for the `master` branch would be removed and a jobset for the
> +`main` branch with the highest priority and the same set of architectures
> +would be created.
> +
> +## Relation to other Guix Consensus Documents
> +
> +Since this change has the potential to affect users and contributors in
> +ways that will disrupt their workflow for some amount of time as they
> +reconfigure their local checkouts to point at the new branch, it should
> +best be adopted as the same time as other, similar changes. In particular,
> +an adoption at the same time as GCD 002 ‘Migrating repositories, issues,
> +and patches to Codeberg’ is desirable.
I am not sure how this plays together with the timeline set above ("14
days after acceptance of this GCD at the earliest, and 30 days at the
latest."). What if this GCD is voted on before the GCD 002? Would it
not make sense to rephrase it to something like "14 days after
acceptance of this GCD or 14 days after result of vote on GCD 002,
whichever happens later"?
> +
> +The repository update path in this GCD is only valid as long as it is
> +simultaneously upheld by other, similar GCDs. Again GCD 002 ‘Migrating
> +repositories, issues, and patches to Codeberg’ needs to be considered as
> +a possibly simultaneous change. For the sake of clarity, the promises
> +made in the repository update path w.r.t. the availability of the old
> +branch shall not exceed those of any other accepted GCD and instead
> +be updated to match.
> +
> +## Cost of Reverting
> +
> +This change mostly affects contributors, who would have to run the following
> +command once to pull from (and in the case of committers push to) the new
> +main branch:
> +
> + $ git branch --set-upstream-to <origin>/main
> +
> +Users of the `guix` CLI would be advised to run `guix pull` again to fetch
> +the latest commit from the main branch. Users of old installation media
> +(e.g. disk images for version 1.4.0) would continue to use the "master" branch
> +and the default channel URL of said installation media until they run
> +`guix pull`. A new release may mitigate this annoyance somewhat.
These two paragraphs above seem to have no connection to "Cost of
Reverting".
> +
> +The main branch may be renamed to any other name (including "master") by
> +repeating the steps laid out in the Repository Update Path and
> +Continuous Integration above, using <name> instead of "main".
> +
> +# Drawbacks and Open Issues
One drawback that is missing here is the impact on scripting and tools
that people have on their machines. I have at least few scripts that
operate with origin/master that will need to be updated. I would not be
surprised if various crons that break will keep being discovered for
weeks or months after the rename.
It is valid to consider that an acceptable cost, but I think the general
fallout across the ecosystem should be recognized in this document, and
clearly declared as acceptable.
> +
> +There is an ongoing political debate as to whether the name “master”,
> +standing alone, should be considered harmful. Similar debates may
> +well surround other names given enough time and particular
> +circumstances. More generally, as language continues to evolve,
> +meanings that appear obvious today may no longer remain so in the
> +future.
> +
> +It is unclear, what effect, if any, the name of the default branch has
> +to contributor satisfaction.
In that case time spent debating this GCD and doing all the work it
would cause, would maybe be better spent on some outreach programs
and/or workshops for less fortunate people?
> The choice of a name may well appear
> +similar to choosing the colour of a bikeshed. What constitutes a
> +meaningful branch name will inevitably be a matter of opinion.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 05 Mar 2025 21:12:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Montag, dem 24.02.2025 um 23:07 +0100 schrieb Ludovic Courtès:
> Perfect! Since the notion of major/minor release is fuzzy in Guix,
> I’d suggest something like:
>
> 2. two or more releases were made in the meantime.
Adopted.
I also extended the grace periods to allow daemon idling for longer,
and added a section regarding other channels.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 07 Mar 2025 17:07:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
On Fri, 21 Feb 2025 at 20:56, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:
>> Therefore, maybe we could imagine that the last commit pushed master
>> introduce a double pull.
>>
>> Assume I still run this 056910e and we are after the grace period. I
>> run “guix pull” so it fetch the last commit of master. Now, when I
>> run again “guix pull”, I will get the last commit of main. This
>> second pull could be transparent for me.
>
> I don't think we should do this for two reasons:
>
> First, the "double pull" commit would be introduced to master only,
> which would break authentication of the main branch pulled this way.
At this end of the grace period, you have a direct path from the HEAD of
’main’ to the authenticated commit. And you also have a direct path
from the HEAD of ’master’ to the authenticated commit.
Assuming, this commit with “double pull” lives only in ’master’ and
’master’ forks from ’main’ – fork because it holds the very commit.
I do not know the detail about switching from an authenticable branch to
another authenticable branch. Because indeed, the HEAD of both branches
’main’ and ’master’ would not be in the same closure.
Hum, something I need to check for my understanding. :-)
> Second, we would have to break Guix itself to introduce arbitrary code
> execution for this particular code 😉
Why? We only need to introduce a special case in
’update-cached-checkout’, no?
Somehow, we would have:
* main
| * master
|/
* End grace period
so we could have something like introduced in the ’master’ branch.
--8<---------------cut here---------------start------------->8---
1 file changed, 1 insertion(+), 1 deletion(-)
guix/git.scm | 2 +-
modified guix/git.scm
@@ -653,7 +653,7 @@ (define* (update-cached-checkout url
#:cleanup-period
%checkout-cache-cleanup-period)))
- (values cache-directory (oid->string oid) relation)))))
+ (update-cached-checkout ... #:ref `(branch . "main") ...)))))
(define* (latest-repository-commit store url
#:key
--8<---------------cut here---------------end--------------->8---
Well, modulo the former question about authentication. :-)
> Perhaps instead, we can on the Git side "redirect" the master branch to
> main. This would avoid the double pull, and it would be truly
> transparent. Perhaps the following sequence of commands would achieve
> just that. (CC'ing Denis for their expertise)
Yeah, who can more can less. :-)
> Am Mittwoch, dem 19.02.2025 um 02:12 +0100 schrieb Denis 'GNUtoo'
> Carikli:
>> $ git checkout origin/master -b temporary
>> $ git push origin HEAD:main
>> $ ssh root <at> server
>> $ cd /path/to/repository.git
>> $ git symbolic-ref HEAD refs/heads/main # Change the main branch
>> $ git symbolic-ref refs/heads/master refs/heads/main # Make master
>> point to main
>
>> This might avoid: Oops why don’t I get the last? Because you’re
>> after the grace period. :-)
>>
>> I don’t know if my suggestion is worth.
>
> Fair point. Double-pulling is a source of annoyance in other package
> managers, so we should do our best not to make it affect too many
> users.
Assuming we are allowed to do that on the server hosting the Git
repository.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 07 Mar 2025 17:07:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Tomas,
On Sun, 02 Mar 2025 at 17:51, Tomas Volf <~@wolfsden.cz> wrote:
> Was there any study or statistics about this topic?
>
> The two black people I have asked consider the whole "master -> main"
> branch rename ridiculous, and me, descendant of people after who the
> Slavery institute is named (Slavs), also do not care. So I am curious
> whether there are any hard data on this topic.
[...]
> Since this GCD is all about feelings, let me point out that some people
> do have negative feelings about the "main" as well. It is a politically
> charged name, so I am not sure it satisfies the goal of "Guix
> contributors, as a whole, feel comfortable with".
Since this appears to me the premise for the rest, let be sure we have
this premise. :-)
1. Can you live with “main” as the branch name?
Or cannot you live with it?
2. The same question for these people.
Let me share my opinion, FWIW. When discussing such topics where I
don’t really feel personally concerned, I refrain to ask myself if it is
founded or not – slippery slope –, and instead, I try to focus on what
the change costs me and I ask to myself if I can or if cannot live with
this change.
Somehow, whatever if I consider the rename deeply ridiculous or highly
important or something in the middle, instead I answer: Ok, it costs me
nothing and I can live with this rename. Then I scrutinize the details
using the same frame. :-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 07 Mar 2025 17:07:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, 23 Feb 2025 at 15:42, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Consider this scenario: I have a machine that I upgrade once every two
> months. By the time the switchover is done, my machine still has
> ‘master’ in its ‘%default-guix-channel’ in its Guix. Thus, when I run
> ‘guix pull’, I’ll end up pulling ‘master’, which (the GCD does not
> clarify this) will either fail because the branch has been removed
> altogether, or will give me an old snapshot.
After the end of the grace period, I propose to introduce a commit, thus
to have master as a fork of main, and such commit would teach
’update-cached-checkout’ to automatically switch.
The only question is about dealing with authentication; well it requires
a special care. But it appears to me doable since both master and main
would be authenticated.
> Thus, I think the GCD should propose to keep updating the ‘master’
> branch as a mirror of ‘main’ for, say, a year (a cron job can take care
> of that).
Even one year isn’t enough. ;-) I’m not sure to run “guix pull” once a
year as root. And many irregular users will have an old snapshot.
Just to me mention that new issues are still reported about v1.2.0
released… Sorry I’m too old to remember such ancient time. ;-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sat, 08 Mar 2025 18:16:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm not overly opinionated on this; although I would slightly prefer to
keep as is for consistency (and that I feel most arguments of this sort
are a bit contrived). If the name must be changed I'd vote against
'main' and go for something like 'stable' as I feel it describes the
use case a bit better than 'main' does. The usage of 'main' to me can
be slightly ambiguous as it raises the question, 'main of what?' vs
'stable' which indicates usage better IMO.
v/r,
Aaron Covrig
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 18 Mar 2025 16:46:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Epa Ekaitz!
Hi Christopher, all,
On Fri, 21 Feb 2025 at 11:48, Ekaitz Zarraga <ekaitz <at> elenq.tech> wrote:
> This debate is draining me, so consider me done here.
[...]
> I am not convinced.
Personally, the only question I ask to myself is:
Can I live with “main” as the branch name?
Or cannot I live with it?
Let me share my reasoning, FWIW. When discussing such topics where I
don’t really feel personally concerned, I do not try to rationalize and
I refrain to ask myself if it is founded or not – slippery slope toward
time vortex –, and instead, I try to focus on what the change costs me
and I ask to myself if I can or if I cannot live with this change.
Somehow, whatever if I rationally consider the rename deeply ridiculous
or highly important, or something in the middle, instead I answer: Ok,
it costs me nothing and I can live with this rename. Then I scrutinize
the details using the same frame. :-)
Cheers,
simon
PS:
> Guix is a Catalan surname, maybe some of them are uncomfortable by its
> name, we should change it too!
Ah I didn’t know… That’s why:
https://img.over-blog.com/300x282/1/50/22/38/chats/chats2/Lepic-guix-100.JPG
Raymond Guix is a painter in Paris. :-)
Good to know.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 18 Mar 2025 17:27:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Simon
> Let me share my reasoning, FWIW. When discussing such topics where I
> don’t really feel personally concerned, I do not try to rationalize and
> I refrain to ask myself if it is founded or not – slippery slope toward
> time vortex –, and instead, I try to focus on what the change costs me
> and I ask to myself if I can or if I cannot live with this change.
>
> Somehow, whatever if I rationally consider the rename deeply ridiculous
> or highly important, or something in the middle, instead I answer: Ok,
> it costs me nothing and I can live with this rename. Then I scrutinize
> the details using the same frame. :-)
I understand, but this way of thinking only encourages more decisions
that many "can live with", but they are not meaningful.
Also, what drains me from this is not only the fact that this is an
unreasonable change in many levels, but the fact that those who push for
it don't care about being reasonable but do care about winning and
labeling others as "far right". Because that's what all this is about.
Making others look like they are worse human beings because they don't
match the political agenda of some (the only one that is right!). And
this is simply disgusting.
I reject not only the debate itself, but also its reasons and the way it
has been conducted. I think it has been unfair to those who don't like
the change.
Of course, I can live with this. Same way those who ask for the change
can live with 'master' (and have been doing so for almost 15 years in
this community). I wouldn't say anybody is unable to live with one or
the other.
So, what are we doing here?
It's just image.
It's the same if someone proposes to put a "Free Palestine" flag in the
Guix website. It's going to be an extremely divisive decision, that for
no reason we need to take or even debate[^1]. But just proposing it is
free internet points for the one who does. (Note that anyone can live
with a flag, as they are not hazardous)
Guix already pretty clearly stated we are against any form of oppression
(one of my points has always been that the word `master` by itself does
not oppress anyone). What else do we need to do?
But hey! Calling people this and that during the process is all in order
to encourage inclusion and make a healthy community.
I can live with it, but I'm not convinced.
---
[^1]: Don't we all agree on that? Isn't it superobvious? 100% of the
world population does!
DISCLAIMER: The point is not to debate about any current political
conflict, but the fact that none of them are universal. The one
mentioned in this email is the best case I could find to illustrate the
problem, for obvious reasons.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Mar 2025 19:14:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Ekaitz,
On Tue, 18 Mar 2025 at 18:25, Ekaitz Zarraga <ekaitz <at> elenq.tech> wrote:
> I can live with it, but I'm not convinced.
On my side, I do not think in term of “being convinced“. Instead, I do
my best to think in term of “do I consent?”
We do not need to be convinced by something to consent about it, IMHO,
Here, I refrain to ask myself if the current proposal is a good strategy
for tackling what it attempts to fix – obviously, I have a (strong)
opinion too! Yes, as a geek I have opinions on many topics. :-)
However, here I hide behind this position:
1. What does my own opinion value?
And
2. Does the change hurt my principles?
For instance, assume I would not be convinced by <proposal>, i.e., I
would consider some proposed strategy would change absolutely nothing
about whatever <issue>; assume my conviction of this proposed strategy
would appear to me as the null strategy of the void. And instead, my
conviction would be about doing X and Y and maybe <issue> would be
deeper than human scale. The question still reads:
a) Does the <proposal> hurt my principles? If no,
b) does the <proposal> block my conviction about what we should do
instead?
Cheers,
simon
PS: On many other points, I partially agree and I refrain to engage a
discussion… because such discussion deserves pintxo and some cider
your country have the secret. :-)
> I understand, but this way of thinking only encourages more
> decisions that many "can live with", but they are not meaningful.
Yes, being social implies we consent to decision that appears to us
meaningless. When playing “which superpower would you like to
have?“, my answer is always: being able to see the world as other
see it, because I would help me to deal with all these decisions
that appear to me meaningless.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 21 Mar 2025 20:17:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
I know this change is going to happen regardless of what those who
oppose it think. That's why I just say I'm not convinced.
Reasons behind it don't convince me, meaning that for me it's a useless
change that only wants to make some imaginary people more comfortable
making some real people uncomfortable. In my view, it's stupid.
The interesting way you are putting it is like you are trying to make me
think my opinion or feelings are not that important, which is exactly my
point against the change. I still didn't get any real person telling me
they are hurt by the word 'master'.
I'm "hurt" by this because this is the result of US American (moral)
imperialism at work, and I reject it, as a citizen of the world.
And following your points, my opinion does NOT have a value, but
ARGUMENTS do (or should have). That's how I wish projects were handled.
We cannot please everybody, what I argue here is we are selecting who we
please, using poor arguments, and talking about imaginary people.
In summary, looks like we are more open to change things to please
imaginary people than pleasing, lets say, just me, a real person, that
is actually part of the project. If our goal was pleasing those that are
uncomfortable, that would be a real debate to have.
That's never been the goal of any of this, and that also I reject.
This conversation has been confrontational, specially by who opened it
in the name of inclusion and "making people comfortable". If that was
the real concern, this was a pretty poor way to do it. So, I also reject
the way this has been conducted.
I've also been pretty critical about moving to a forge, and I shared my
concerns about it in the past. But the way the proposal has been
conducted is not confrontational, and its arguments are solid. I can't
do anything else than support that change.
That's how things should be done.
About cider and pintxos, I have some homemade cider I'd love to share
with you anytime, if you come for a visit.
About meaningless things, it's not that this "appears" to be
meaningless, it's that nobody even bothered to make it even reasonable.
If we are really proposing a change, let me do my part and demand proper
justifications. This discussion has been just some people agreeing and
not explaining while they called others fascists or told them they
SHOULD KNOW why we need to do this to become more inclusive. I think it
is my right (as it is of others) as part of the community to demand some
explanation for the change, and for ANY change, the same way I would
demand explanations for commits I don't understand. Isn't that my job here?
In the end, this has been put as those who reject the change are against
social justice, and that's not an acceptable way to propose anything
because it eliminates any possibility for a debate and erases the chance
of anyone to be against the change. Reducing the issue to "If you
confront -> you are against social justice".
This (by itself, regardless if the change is stupid or not) only fosters
division in our community, and I have to reject that too.
So, if you prefer:
I'm AGAINST the change because:
1. I don't think the proposal allowed honest discussion, so it's biased.
2. I don't think the proposal has any base.
3. I don't think the change will make the project more inclusive, but
may be counterproductive.
4. The change does minimal harm, but more than an absolute zero.
5. I think this change opens the door to similar proposals, which I
don't think are positive for the community, specially if they are
conducted like this one.
6. I think the initial goal for the proposal was actually to look for
confrontation.
Tl;dr:
I do NOT consent. Maybe if this whole thing was done differently I
would, and I'm still open to ARGUMENTS that change my mind.
In any case, I believe it's going to be done, regardless of what I share
here, and some people will start to look at me with different eyes
because of this. Thanks, I suppose.
Best,
Ekaitz
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sat, 22 Mar 2025 04:49:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I think I share Simon's point of view on this proposal. I'm basically
indifferent about the outcome of the proposal. I'd want to see a group
effort on enumerating, testing, and solving the technical challenges
before we make the change. There has been some discussion about that. I
think we should be careful about the technical stuff.
On Fri, Mar 21, 2025 at 09:16:35PM +0100, Ekaitz Zarraga wrote:
> In summary, looks like we are more open to change things to please imaginary
> people than pleasing, lets say, just me, a real person, that is actually
> part of the project.
After I read Ekaitz's message here, I went back and read the thread. As
I read it, Ekaitz's message highlights that there has not been much
consensus-building. I think that when there is disagreement about a GCD,
there needs to be be active work to build a consensus that is
enthusiastic --- not indifferent.
I've been intimately involved in organizations that govern themselves
with a structured consensus system like the GCD process, and it's work
that requires a lot of energy and strong social skills.
My experience made me think that the range of topics that can be
successfully handled with consensus may be limited to that which
pertains to the shared experience of the members. Else, the group may
not be able to actually reach a consensus, and maybe it comes to a vote,
or some people just accept a change indifferently or with calculated
resignation. (Those can be okay outcomes too, IMO, even the last one.
You can't always get what you want.) My point is that we all share an
experience with Guix, computing, Git, etc, but not with English language
or the English and American societies.
Guix team members are the constituents of the GCD process. If some of
them have objections to a proposal, that means there is work to do, from
all of us.
To quote the Decision Making section of the GCD text itself (GCD 001):
------
Contributors and even more so team members are expected to help build
consensus. By using consensus, we are committed to finding solutions that
everyone can live with.
Thus, no decision is made against significant concerns; these concerns are
actively resolved through counter proposals. A deliberating member
disapproving a proposal bears a responsibility for finding alternatives,
proposing ideas or code, or explaining the rationale for the status quo.
To learn what consensus decision making means and understand its finer
details, you are encouraged to read
<https://www.seedsforchange.org.uk/consensus>.
------
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 10:25:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hello,
Leo Famulari <leo <at> famulari.name> skribis:
> I think I share Simon's point of view on this proposal. I'm basically
> indifferent about the outcome of the proposal. I'd want to see a group
> effort on enumerating, testing, and solving the technical challenges
> before we make the change. There has been some discussion about that. I
> think we should be careful about the technical stuff.
I agree. It seems to me that the document proposes something doable and
reasonable technically, but having more eyeballs would help find
omissions or potential issues.
FWIW I renamed the default branch of a few repositories over the past
few years, notably Cuirass and Shepherd; it was rather friction-less but
of course these are smaller repos with fewer contributors.
> Guix team members are the constituents of the GCD process. If some of
> them have objections to a proposal, that means there is work to do, from
> all of us.
Agreed.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 10:55:03 GMT)
Full text and
rfc822 format available.
Message #104 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Egun on Ekaitz,
Ekaitz Zarraga <ekaitz <at> elenq.tech> skribis:
> Also, what drains me from this is not only the fact that this is an
> unreasonable change in many levels, but the fact that those who push
> for it don't care about being reasonable but do care about winning and
> labeling others as "far right". […]
I haven’t read in detail the previous discussion on guix-devel that you
must be referring to, but derogatory comments like those you report
could be a violation of the code of conduct.
At any rate, that and the “us vs. them” rhetoric (as in “those who push
for it”) is unhelpful and very different from how I think we like to
work together here.
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 16:48:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Freitag, dem 21.03.2025 um 21:16 +0100 schrieb Ekaitz Zarraga:
> Reasons behind it don't convince me, meaning that for me it's a
> useless change that only wants to make some imaginary people more
> comfortable making some real people uncomfortable. In my view, it's
> stupid.
What makes you uncomfortable about the proposed name? Is there any
proposed alternative that you would like to see instead? If not, would
you like to suggest an alternative?
> The interesting way you are putting it is like you are trying to make
> me think my opinion or feelings are not that important, which is
> exactly my point against the change. I still didn't get any real
> person telling me they are hurt by the word 'master'.
What Simon is actually trying to achieve is to tell you that your
opinion is not *the only one* that matters. It may well be, that
everyone who thus far told you they are hurt by the word 'master' are
actually bots (beep boop) and/or engaging in US imperialism. But there
also exists a chance that you have thus far merely avoided –
deliberately or otherwise – any real person who could convince you that
it's hurtful.
Let's take a survey to get some actual numbers. According to [1],
master appears inoffensive to about 80% of people and offensive to less
than 10%, with the rest abstaining. Clearly, this must mean that
branch naming is a non-issue, right? Right? Sadly, it's not that
simple. For if you take a moment to consider that these people _are
real_ and they feel offended by the word master, perhaps there is
something offensive about it.
Now, if you look into the comments, you will find some more arguments
defending various people's choices of a default branch name that apply
to their personal projects and what not. Some of those may be relevant
to Guix, some of those may be not. As for arguments that are important
to the Guix project, I think these would be or have been brought up in
the discussion.
> I'm "hurt" by this because this is the result of US American (moral)
> imperialism at work, and I reject it, as a citizen of the world.
Changes happen. Even if this were the result of US imperialism – which
for the record you keep postulating without evidence; at least as far
as I can see – you would have to find a way of dealing with it. Now,
you can choose to ignore that Git allows you to change the default
branch name and reject any proposal to do so, but I think not everyone
will do the same.
> In summary, looks like we are more open to change things to please
> imaginary people than pleasing, lets say, just me, a real person,
> that is actually part of the project. If our goal was pleasing those
> that are uncomfortable, that would be a real debate to have.
I am not convinced, that I should please you, particularly, rather than
anyone else who participated in this process. If you have a reason as
to why your opinion should be given special weight, I would like to
hear it.
As for only pleasing imaginary people, have you stopped to consider
that those in favour of the change could be real people and not
displeased by the change? Because it could just so happen to be that
some folks would prefer another name over master. Personally, I'm one
of them. I would feel quite happy with 'main' or 'trunk'; even
'stable' if we could make that guarantee. Now, I am aware, that this
is all a preference and to an extent de gustibus, but I think we can
come to a shared preference that maximizes happiness and minimizes harm
for Guix contributors.
> This discussion has been just some people agreeing and
> not explaining while they called others fascists or told them they
> SHOULD KNOW why we need to do this to become more inclusive.
Which of these mails [2,3] called others fascist? Do feel free to
point out ones that don't appear in either query and quote them.
> I think it is my right (as it is of others) as part of the community
> to demand some explanation for the change, and for ANY change, the
> same way I would demand explanations for commits I don't understand.
> Isn't that my job here?
That ought to be covered in the Motivation of a GCD, no? I personally
feel motivated by it. You're free to feel differently, I have no
control over you. But I don't think it's fair to say there's no
explanation.
> In the end, this has been put as those who reject the change are
> against social justice, and that's not an acceptable way to propose
> anything because it eliminates any possibility for a debate and
> erases the chance of anyone to be against the change. Reducing the
> issue to "If you confront -> you are against social justice".
So, assuming that you are for social justice, but against this change,
do you think this change constitutes a social injustice?
Or; assuming you are against social justice, would you rather not be
perceived as such?
> 6. I think the initial goal for the proposal was actually to look for
> confrontation.
Believe it or not, I actually was not prepared for the backlash I
received. I actually thought this would be a straight-forward change
to implement given the values that folks here share, and I'm not happy
to be proven wrong on that.
Cheers
[1] https://www.reddit.com/r/dotnet/comments/wrci66/is_the_name_master_branch_offensive/
[2] https://yhetil.org/guix-devel/?q=fascist+s%3Amain+s%3Abranch
[3] https://yhetil.org/guix-patches/?q=fascist+s%3A76407
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 18:44:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi
On 2025-03-23 17:47, Liliana Marie Prikler wrote:
>> The interesting way you are putting it is like you are trying to make
>> me think my opinion or feelings are not that important, which is
>> exactly my point against the change. I still didn't get any real
>> person telling me they are hurt by the word 'master'.
> What Simon is actually trying to achieve is to tell you that your
> opinion is not *the only one* that matters. It may well be, that
> everyone who thus far told you they are hurt by the word 'master' are
> actually bots (beep boop) and/or engaging in US imperialism. But there
> also exists a chance that you have thus far merely avoided –
> deliberately or otherwise – any real person who could convince you that
> it's hurtful. > Let's take a survey to get some actual numbers. According to [1],
> master appears inoffensive to about 80% of people and offensive to less
> than 10%, with the rest abstaining. Clearly, this must mean that
> branch naming is a non-issue, right? Right? Sadly, it's not that
> simple. For if you take a moment to consider that these people _are
> real_ and they feel offended by the word master, perhaps there is
> something offensive about it.
This is not as a solid argument as you think.
The survey was done years after the renaming campaign started, letting
the idea of "master is bad" sink, the amount of people that took part is
too low, and reddit is a biased community. Still, it only got a 10%. And
the first comment in the thread, that has hundreds of upvotes says:
"I am a black man and have no issue with the word "master" in the
context of git branches. I am intelligent enough to know the difference
between an electronic hierarchy and human suffrage and racism."
On the other hand, the fact that some people is offended by something
doesn't mean that thing is offensive. You can get offense on anything in
the world, that doesn't mean you are right.
Sadly, there's more than a 10% of population in the world (probably more
around a 60% or so) that think trans people don't exist and are offended
by them. Does that mean they are right? Does it mean we should please
them, removing all references to trans people from the world?
>> I'm "hurt" by this because this is the result of US American (moral)
>> imperialism at work, and I reject it, as a citizen of the world.
> Changes happen. Even if this were the result of US imperialism – which
> for the record you keep postulating without evidence; at least as far
> as I can see – you would have to find a way of dealing with it. Now,
> you can choose to ignore that Git allows you to change the default
> branch name and reject any proposal to do so, but I think not everyone
> will do the same.
I say it is related with the US because this originated on a campaign by
an US corporation that exported the US thinking of trying to comfort
others, censor swear words in tv and so on. I could talk for long about
why that is related to their religion and so on...
In any case, the point here is we should choose our fate. They imposed
enough things on us, like the language, and we should now just apply
this change because some US corporation lobbied for it and made some
people think there was anything wrong with one specific word of the
dictionary. You chose to follow them, and I chose to reject it.
(Some had already shared their concerns about Guix's pronunciation, are
we also open to change the project's name?)
> As for only pleasing imaginary people, have you stopped to consider
> that those in favour of the change could be real people and not
> displeased by the change? Because it could just so happen to be that
> some folks would prefer another name over master. Personally, I'm one
> of them. I would feel quite happy with 'main' or 'trunk'; even
> 'stable' if we could make that guarantee. Now, I am aware, that this
> is all a preference and to an extent de gustibus, but I think we can
> come to a shared preference that maximizes happiness and minimizes harm
> for Guix contributors.
I understand that you can *prefer* something else. I also prefer to talk
in spanish and here we are. If I knew german, I would be happy to talk
to you in german if we both agreed to it in those terms: preference.
If you told me that speaking in any other language than german could
offend people or hurt them I would reject your arguments, which is what
I'm doing here.
I don't care to use master, main, guix, or anything else. That's not the
problem I'm pointing to.
Maybe the GDC should be called: Let's change the branch name to
something I like more. It would be fairer that way, but it may have more
risk to be rejected.
>> This discussion has been just some people agreeing and
>> not explaining while they called others fascists or told them they
>> SHOULD KNOW why we need to do this to become more inclusive.
> Which of these mails [2,3] called others fascist? Do feel free to
> point out ones that don't appear in either query and quote them.
You told me to educate myself in "far-right dog-whistles" implying
another person was using them, and thus implying they were far-right
extremists. Maybe I took it too seriously.
(Also that person had called the proposal "woke" and I don't like that
framing either)
>> I think it is my right (as it is of others) as part of the community
>> to demand some explanation for the change, and for ANY change, the
>> same way I would demand explanations for commits I don't understand.
>> Isn't that my job here?
> That ought to be covered in the Motivation of a GCD, no? I personally
> feel motivated by it. You're free to feel differently, I have no
> control over you. But I don't think it's fair to say there's no
> explanation.
Well, the explanation is quite vague, and does not include possible
drawbacks like the social price we are paying for it. Some may think
that's because you were wiling to pay it.
In the document I read "may be perceived as harmful" or "that spring to
mind more easily" but both are vague suggestions of a possible harm.
Nothing that actually exists.
Every word may be perceived as harmful.
People that supports your proposal do it for preference, but not because
they are actually hurt by the word "master". It is fine, though.
>> In the end, this has been put as those who reject the change are
>> against social justice, and that's not an acceptable way to propose
>> anything because it eliminates any possibility for a debate and
>> erases the chance of anyone to be against the change. Reducing the
>> issue to "If you confront -> you are against social justice".
> So, assuming that you are for social justice, but against this change,
> do you think this change constitutes a social injustice?
> Or; assuming you are against social justice, would you rather not be
> perceived as such?
I think, this original let's rename the branches idea gained traction in
the last years because it creates some social division where people
could just check the default branch name of software projects to see if
they were more left or right leaning and I don't like that. That's why I
don't like it being applied here.
Oftentimes this kind of proposals are made to stretch the project's
social structure and try to find holes.
We did have a similar episode with a patch being sent to the CoC for
good initial reasons but what happened to be a person that claimed that
trans women could not be considered women. I didn't read his intentions
very well at the beginning, but if I'm not mistaken, you did.
I think your proposal here is also a stretch in the social dynamics of a
very diverse project.
>> 6. I think the initial goal for the proposal was actually to look for
>> confrontation.
> Believe it or not, I actually was not prepared for the backlash I
> received. I actually thought this would be a straight-forward change
> to implement given the values that folks here share, and I'm not happy
> to be proven wrong on that.
Well, what happened here is what triggered my reserves since the very
beginning, and I think I told you in the previous thread.
You underestimated how diverse Guix is. Guix has people from all over
the globe, and it shouldn't surprise you that many people here were not
affected by the original push for the branch rename as much as you were.
When I took part in the discussion it wasn't only in my name. Surely I
could be more precise on it, but I tried to make you understand that
those things that we consider superobvious (master might be offensive ->
we change it) might not be so obvious to others, and we might pay a
social price for discussing them in the terms you did.
In a previous email I asked what would happen if we started a discussion
about putting a "free palestine" label in the Guix website. Many
software projects did that (also with Ukranian flags). The problem here
is also related with what Ludovic mentioned: he changed the branch name
in the shepherd without any hassle. He surely could put the "free
palestine" label in the Shepherd website easily.
But Guix is a global project, and thinking such a proposal would not
have any backlash is very naive.
That's why I think we should refrain from trying this kind of "very
obvious" changes that are really rooted in our political views. We might
be asking for too much for such a diverse group of people.
Best,
Ekaitz
> Cheers
>
> [1] https://www.reddit.com/r/dotnet/comments/wrci66/is_the_name_master_branch_offensive/
> [2] https://yhetil.org/guix-devel/?q=fascist+s%3Amain+s%3Abranch
> [3] https://yhetil.org/guix-patches/?q=fascist+s%3A76407
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 18:55:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello,
>
> Leo Famulari <leo <at> famulari.name> skribis:
>
>> I think I share Simon's point of view on this proposal. I'm basically
>> indifferent about the outcome of the proposal. I'd want to see a group
>> effort on enumerating, testing, and solving the technical challenges
>> before we make the change. There has been some discussion about that. I
>> think we should be careful about the technical stuff.
>
> I agree. It seems to me that the document proposes something doable and
> reasonable technically, but having more eyeballs would help find
> omissions or potential issues.
>
> FWIW I renamed the default branch of a few repositories over the past
> few years, notably Cuirass and Shepherd; it was rather friction-less but
> of course these are smaller repos with fewer contributors.
Coincidentally, guix-cuirass and shepherd are the only two repositories
I mirror that have the wrong default branch in my cgit instance. Now I
know why, I have probably started mirroring before this change was done
and have missed the announcement about the change. I should figure out
how to fix it...
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 21:48:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Sonntag, dem 23.03.2025 um 19:43 +0100 schrieb Ekaitz Zarraga:
> Sadly, there's more than a 10% of population in the world (probably
> more around a 60% or so) that think trans people don't exist and are
> offended by them. Does that mean they are right? Does it mean we
> should please them, removing all references to trans people from the
> world?
It is funny that you'd suggest that – not sincerely, I know – given
that it's exactly what is currently happening in the US. Yet, I think
that no one would suggest in honest, and that Guix would resist such an
attempt at othering our trans comrades.
> I say it is related with the US because this originated on a campaign
> by an US corporation that exported the US thinking of trying to
> comfort others, censor swear words in tv and so on. I could talk for
> long about why that is related to their religion and so on...
To my knowledge, the change in Git was initiated by SF Conservancy,
which is indeed a US nonprofit. That being said, merely being based in
the US is not yet a reason to disregard their opinion – I think I've
already outlined that before. Both FSF and GNU were started in the US
too, without them we'd have considerably less free software (regardless
of anyone's opinion on RMS, might I add).
> In any case, the point here is we should choose our fate. They
> imposed enough things on us, like the language, and we should now
> just apply this change because some US corporation lobbied for it and
> made some people think there was anything wrong with one specific
> word of the dictionary. You chose to follow them, and I chose to
> reject it.
I agree with the first sentence of this paragraph. I don't think that
keeping master because someone way back when decided that that was a
good name is much of "choosing our fate", though. If anything, had
people accepted the status quo all the way down, we'd still use SVN and
'trunk' :)
> (Some had already shared their concerns about Guix's pronunciation,
> are we also open to change the project's name?)
Maybe, maybe not. If folks wanted a rebrand, because they don't like
the sound of Guix or think it has been forever tainted by the whole
GuixSD thing that is woefully outdated yet still being used, I could
see myself supporting that. I could not currently come up with a punny
French name myself, though, and I don't think this is a concern for
many Guix at the moment.
>
> I understand that you can *prefer* something else. I also prefer to
> talk in spanish and here we are. If I knew german, I would be happy
> to talk to you in german if we both agreed to it in those terms:
> preference.
>
> If you told me that speaking in any other language than german could
> offend people or hurt them I would reject your arguments, which is
> what I'm doing here.
>
> I don't care to use master, main, guix, or anything else. That's not
> the problem I'm pointing to.
>
> Maybe the GDC should be called: Let's change the branch name to
> something I like more. It would be fairer that way, but it may have
> more risk to be rejected.
Speaking to people in languages other than German can, actually,
depending on the context, hurt them. Now, we are not in such a context
and I think we are all fine with using English as a language to
communicate our GCDs in – which to be fair, isn't perfect either, and
for tech support and other things it's often more helpful to use folks'
first languages, but I don't think we could seriously consider the
alternative of translating those documents into all languages used by
contributors with the current number of people contributing towards
them.
Now, I will take you by your word and assume you'd agree with me if
this was merely about a choice of preference. Which, to be fair, as
long as we choose from a pool of harmless choices, it is. The matter
still remains, that the currently used 'master' is not eligible per
that criterion as even in the face of some token black people declaring
it not an issue, it remains demonstrably offensive for the reasons
pointed out.
> >
> > Which of these mails [2,3] called others fascist? Do feel free to
> > point out ones that don't appear in either query and quote them.
>
> You told me to educate myself in "far-right dog-whistles" implying
> another person was using them, and thus implying they were far-right
> extremists. Maybe I took it too seriously.
>
> (Also that person had called the proposal "woke" and I don't like
> that framing either)
I used the word "right-wing dogwhistles", but fair enough. I can
assure you that the person in question was indeed using said dog
whistles (of the American right as well) – whether they were aware of
it or not.¹ And mind you, I was not defending myself here, but
responding to you dismissing someone else's observation that their
comment had indeed been dismissive.
To be completely honest, this entire exchange read like the age old
script of some right winger making an extremely unhinged take and being
called out on it, before a free speech absolutist steps in to defend
them. And to continue, your response to that felt like you were more
concerned with their right to be right winger, having already
determined they are one, than the sensibilities of any minority under
the threat of right wing rhetoric and/or action.
You told me back than that you were drained by the discussion, that I
made you feel unwelcome and that I've been gaslighting you. So let me
tell you: your comment was not even the worst I received for making
that suggestion. And that's just talking for myself. People have been
made to feel quite uncomfortable by the "actually, master is fine"
crowd. So yeah, please understand that folks are a little on edge, and
don't be surprised when no one's typing "I'm black and I feel offended
by the name 'master'" in the comments.
> Well, the explanation is quite vague, and does not include possible
> drawbacks like the social price we are paying for it. Some may think
> that's because you were wiling to pay it.
>
> In the document I read "may be perceived as harmful" or "that spring
> to mind more easily" but both are vague suggestions of a possible
> harm. Nothing that actually exists.
>
> Every word may be perceived as harmful.
>
> People that supports your proposal do it for preference, but not
> because they are actually hurt by the word "master". It is fine,
> though.
I think the social price we pay is rather small in this instance,
particularly as we aim to cater towards our own group of contributors.
We did see some not-so-nice sides of folks lurking around Guix surface,
though, I'll grant you that.
> >
> I think, this original let's rename the branches idea gained traction
> in the last years because it creates some social division where
> people could just check the default branch name of software projects
> to see if they were more left or right leaning and I don't like that.
> That's why I don't like it being applied here.
>
> Oftentimes this kind of proposals are made to stretch the project's
> social structure and try to find holes.
I mean, it helps that they become vehicles for folks to scream DEI and
woke at the mere suggestion, but apart from those deliberate
interruptions, I do think we can be reasonable people and collectively
choose a colour for our bikeshed :)
> We did have a similar episode with a patch being sent to the CoC for
> good initial reasons but what happened to be a person that claimed
> that trans women could not be considered women. I didn't read his
> intentions very well at the beginning, but if I'm not mistaken, you
> did.
I do remember that episode. The "good initial reasons" were actually a
smoke screen because they failed to get their changes adopted upstream.
That is quite a different matter than what we're currently discussing,
because "upstream" (Git) already supports free choice of a default
branch name and we're not (yet) making use of that feature.
> > > 6. I think the initial goal for the proposal was actually to look
> > > for confrontation.
> > Believe it or not, I actually was not prepared for the backlash I
> > received. I actually thought this would be a straight-forward
> > change to implement given the values that folks here share, and I'm
> > not happy to be proven wrong on that.
>
> Well, what happened here is what triggered my reserves since the very
> beginning, and I think I told you in the previous thread.
>
> You underestimated how diverse Guix is. Guix has people from all over
> the globe, and it shouldn't surprise you that many people here were
> not affected by the original push for the branch rename as much as
> you were.
You make me sound like a villain whose evil plot is being foiled. Let
me remind you that I'm part of what makes Guix diverse ;)
> When I took part in the discussion it wasn't only in my name. Surely
> I could be more precise on it, but I tried to make you understand
> that those things that we consider superobvious (master might be
> offensive -> we change it) might not be so obvious to others, and we
> might pay a social price for discussing them in the terms you did.
Now, I'm aware that it might not be super obvious to everyone, but I
did kinda expect most Guix to have a basic amount of empathy with those
who are affected by such "trivial" things as branch names. They did
put in the effort to fight on everyone's behalf to make the default
configurable, after all.
> In a previous email I asked what would happen if we started a
> discussion about putting a "free palestine" label in the Guix
> website. Many software projects did that (also with Ukranian flags).
> The problem here is also related with what Ludovic mentioned: he
> changed the branch name in the shepherd without any hassle. He surely
> could put the "free palestine" label in the Shepherd website easily.
> But Guix is a global project, and thinking such a proposal would not
> have any backlash is very naive.
>
> That's why I think we should refrain from trying this kind of "very
> obvious" changes that are really rooted in our political views. We
> might be asking for too much for such a diverse group of people.
I think we could discuss at lengths about flags on web pages, but we
should take that part of the discussion off-list as off-topic. For
now, let me just agree that putting a flag on some web appearance is
pretty low effort for no serious gain; especially if such efforts are
not backed by a more serious commitment towards a cause.
I do however think that changing our default branch name is very much
in line with our overall values, not just a bit to score Internet
brownie points, and that we can be a guide to other projects somewhat
married to Git attempting to do the same. And to be sure: we've
already committed to the change where it was trivial, so let's follow
through on the repositories where there's a small technological hurdle
to overcome.²
Cheers
¹ The purpose of dogwhistling is partly to mark one's intent while
blending in a larger crowd oblivious to the meaning behind the phrases
they use.
² I'm aware that this could alternatively read like a sunk cost
fallacy, but I mean this more in the "practice what we preach" sense.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 23 Mar 2025 22:20:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Liliana, I told you what I believed, and I'll continue to do so, but I
didn't I make any comment in bad faith and hurting you has never been my
intention.
I know you know that, even if we disagree.
I understand that we all got defensive, but that doesn't make comments
in bad faith acceptable, so if you got some I'm sorry. Those should be
reported.
On 2025-03-23 22:47, Liliana Marie Prikler wrote:
> I'm part of what makes Guix diverse 😉
We all are.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 12:01:03 GMT)
Full text and
rfc822 format available.
Message #122 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi all,
Sorry, I am missing something – I’ve re-read all the thread. As Leo
pointed, are we building all together a consensus here? Reminder:
Contributors and even more so team members are expected to help build
consensus. By using consensus, we are committed to finding solutions that
everyone can live with.
Thus, no decision is made against significant concerns; these concerns are
actively resolved through counter proposals. A deliberating member
disapproving a proposal bears a responsibility for finding alternatives,
proposing ideas or code, or explaining the rationale for the status quo.
Therefore, if some of us do not care to use master or main, then it
means some of us consent in one way or the other, no? That’s what I’m
missing, I guess.
Consent does not mean we are all convinced, neither we fully support,
neither we are deeply aligned, neither our own opinion reads “yeah this
change the best idea ever”, etc. Consent means accepting another angle
than our own, one angle that I do not fully share but I can live with.
In full transparency, I sponsor the GCD but I do not support it: I agree
(consent) to change the branch name. Somehow, it removes me nothing
neither adds me something, and for the rest, I do not feel qualified
enough to publicly share a strong opinion. Ah, we are not yet in the
“Deliberation Period“. :-)
Hey, we are still in the “Discussion Period”. :-)
In the “Discussion Period”, the main rule is to listen the other points
of view and challenge our first impression or initial opinion. In other
words, we ask more explanations about some wording, we propose new
wordings, we ask more details about the motivation, etc. More
importantly, we challenge the technical bits.
And always being very specific with the GCD at hand.
Making decision with consensus isn’t passive – scanning the document and
then answering yes or no – but consensus is active: Ask questions and/or
Propose alternatives and/or Explain the rationale for the status quo.
In this thread, are we working all together to build a consensus?
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 14:09:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2025 at 8:01 AM Simon Tournier <zimon.toutoune <at> gmail.com> wrote:
[...]
> Making decision with consensus isn’t passive – scanning the document and
> then answering yes or no – but consensus is active: Ask questions and/or
> Propose alternatives and/or Explain the rationale for the status quo.
>
> In this thread, are we working all together to build a consensus?
Consensus on both the what and the *why*.
We can more easily find consensus by saying less (the opposite of a
majoritarian system).
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 16:49:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2025 at 10:08:23AM -0400, Greg Hogan wrote:
> We can more easily find consensus by saying less (the opposite of a
> majoritarian system).
That's a really interesting point that I've noticed intuitively, but
hadn't ever identified explicitly.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 16:57:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2025 at 12:34:33PM +0100, Simon Tournier wrote:
> Consent does not mean we are all convinced, neither we fully support,
> neither we are deeply aligned, neither our own opinion reads “yeah this
> change the best idea ever”, etc. Consent means accepting another angle
> than our own, one angle that I do not fully share but I can live with.
Now we get into semantics, but I disagree that "consent means accepting
another angle than our own".
Consent should be active and, at least to some degree, enthusiastic.
If we can't reach an enthusiastic consensus without strong objections
from team members, then we can talk about using another method of making
a decision, like I mentioned in my earlier email. But we shouldn't call
it consensus.
To repeat my earlier email again, I've been involved in decisions made
by "consensus" where the reality is that a small group of advocates
pushed very hard to make a change and eventually exhausted those with
objections. The objectors made a calculated decision to accept the
change because the cost to them, personally, of ultimately rejecting the
proposal was too high.
I think that's a valid way to decide, but it's not consensus.
I understand the GCD process to aim higher than that. It requires us all
to demonstrate leadership, solidarity, and care. It's easy to propose
something, but then the work begins.
Maybe I'm too pessimistic, but I don't think it will be possible to
reach a consensus on every subject we discuss.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 18:51:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Leo,
On Mon, 24 Mar 2025 at 17:56, Leo Famulari <leo <at> famulari.name> wrote:
> Now we get into semantics, but I disagree that "consent means accepting
> another angle than our own".
The other part “one angle that I do not fully share but I can live with”
of the quote matters, IMHO. :-)
Anyway.
If my wording was poor or misleading, sorry, so let point to the
dictionary: If you give your consent to something, you give someone
permission to do it. If you consent to something, you agree to do it or
to allow it to be done.
Yes, I agree that Making Decision based on consensus is a challenging
bet at the scale of Guix. The most difficult part, IMHO, is to keep
some conditions [1] under the constraints asynchronous and full remote.
I’m still confident. :-) We will see…
In the all cases – whatever any other final decision making system as
voting we would pick–, the practice of trying to reach a consensus
appears to me sane and healthy because it pushes all the participants to
be active in finding solutions. Yeah some subjects – choosing between
the color yellow or orange for stuff – seem inadequate, but consensus is
still worth to try, IMHO. :-)
As said elsewhere, I’ve a rough draft of a GCD for amending GCDs. Then,
it would allow to amend GCD 001 and improve the process itself; for
instance, we could imagine a mechanism that triggers some last resort
option falling back to some voting method – well it raises many details
that need to be discussed in some dedicated thread. ;-)
For now with the GCD at hand, I think we all need to work on the
objections specific to the document. Because, re-reading all the
thread, what I observe is some general arguments not focused on the
document itself.
Somehow, in all this thread, after re-reading it, I’m still missing the
“active” part from: « these concerns are actively resolved through
counter proposals. A deliberating member disapproving a proposal bears
a responsibility for finding alternatives, proposing ideas or code, or
explaining the rationale for the status quo. »
Well, I am going to do my homework… :-)
Cheers,
simon
1: https://www.seedsforchange.org.uk/consensus#conditions
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 18:51:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Greg,
On Mon, 24 Mar 2025 at 10:08, Greg Hogan <code <at> greghogan.com> wrote:
> We can more easily find consensus by saying less (the opposite of a
> majoritarian system).
Do you specifically speak about the GCD at hand proposing to rename the
branch from “master” to “main”? Or about generically about consensus?
Well, IIUC, it’s about the GCD at hand and your concrete proposal [1]
is:
Can we find greater but narrower consensus around the practical
motivation that 1) most users leave unchanged the git default "main",
therefore "master" will become increasingly uncommon and unexpected,
2) the choice of "main" is masterfully similar when tab-completing or
looking through a sorted list of refs, and 3) the move to Codeberg
presents a hopefully rare opportunity combine disruptive changes? We
do not need a comprehensive motivation if we can find consensus on the
outcome.
Right?
This appears to me reasonable. Your proposal is to narrow the
Motivation section, right?
Cheers,
simon
1: [bug#76407] [GCD] A better name for the default branch
Greg Hogan <code <at> greghogan.com>
Fri, 28 Feb 2025 10:46:05 -0500
id:CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg <at> mail.gmail.com
https://issues.guix.gnu.org/76407
https://issues.guix.gnu.org/msgid/CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg <at> mail.gmail.com
https://yhetil.org/guix/CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg <at> mail.gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 24 Mar 2025 21:24:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Simon Tournier <zimon.toutoune <at> gmail.com> writes:
> Somehow, in all this thread, after re-reading it, I’m still missing the
> “active” part from: « these concerns are actively resolved through
> counter proposals. A deliberating member disapproving a proposal bears
> a responsibility for finding alternatives, proposing ideas or code, or
> explaining the rationale for the status quo. »
But we are not in a deliberation period yet, so there, by definition, is
no "A deliberating member disapproving a proposal". At least if I read
the GCD #1 correctly.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 25 Mar 2025 13:02:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Tomas,
On Mon, 24 Mar 2025 at 22:23, Tomas Volf <~@wolfsden.cz> wrote:
> Simon Tournier <zimon.toutoune <at> gmail.com> writes:
>
>> Somehow, in all this thread, after re-reading it, I’m still missing the
>> “active” part from: « these concerns are actively resolved through
>> counter proposals. A deliberating member disapproving a proposal bears
>> a responsibility for finding alternatives, proposing ideas or code, or
>> explaining the rationale for the status quo. »
>
> But we are not in a deliberation period yet, so there, by definition, is
> no "A deliberating member disapproving a proposal". At least if I read
> the GCD #1 correctly.
The GCD reads:
Anyone who is a team member is a deliberating member
Contributors and even more so team members are expected to help
build consensus.
Therefore, my understanding of the paragraph,
A deliberating member disapproving a proposal bears a
responsibility for finding alternatives, proposing ideas or
code, or explaining the rationale for the status quo.
reads “deliberating member” <==> “team member” here.
Well, I do not know if the GCD #001 appears to you unclear but, to me,
it reads:
+ We discuss the specific elements of the document for building a
consensus. The discussion is open to anyone; team members are
expected to help build consensus.
+ Once it’s done, team members deliberate.
Somehow, it would not make much sense that a team member waits the
(last) Deliberation Period to be active in finding alternatives,
proposing ideas or code, or explaining the rationale for the status quo.
When such activity fits the Discussion Period, IMHO.
That’s said, I read good faith in the intent of your comment and I
refrain myself to see some nitpicking.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 12:22:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hello all,
echoing Leo's statement, my intuition is that this proposal is poorly
suited for a consensus based approach. There is not much compromise
possible (in the end, we need a branch name and only one), on a subject
where preferences are mainly based on feelings rather than technical
merits (in reality, any branch name would work, it is purely a matter
of convention).
More generally, the GCD process has a strong bias in favour of change
for bikeshedding issues: Unless a person strongly opposes the change
(which is difficult to do, since then one is expected to work towards
a consensus on whether the shed should be painted in red or blue), it
is enough that 25% of the participants do reply with a weak "I accept"
(and in practice I suppose that at least the author will support).
So as Leo said, in such cases one is almost certain that a proposal will
be accepted without there being a strong consensus that it is a good
change.
The proposal has a few technical drawbacks (there is always a cost
involved in changing), but it looks to me like these can be overcome
without too many problems as already suggested by several participants
to the discussion. There do not seem to be real gains (except for people
feeling better about a different name, which is somewhat vague for
people not sharing that feeling).
Concerning the name, the current standard for git repositories is "master".
Apart from that, I have only seen "main". So maybe we can agree that all
other names are not practical? There is muscle memory involved in typing
"git checkout ...", and I do not see any point in choosing a completely
separate name only for the Guix project. Also the "git checkout m<tab>"
argument is convincing. Practically speaking, we could also stick with
"master" and wait and see whether "main" becomes the majority, and
decide to switch only if and when that happens.
Also, my impression is that it would be better to rather quickly delete
the master branch if we change names instead of keeping it around. It
would be better to create an error instead of letting people stick with
an outdated branch. In particular, we should make sure that "guix pull"
either works with the new name or breaks visibly, so that people do not
remain on "master" while thinking they are updating their system.
Now to the bike shedding part. Personally, I only associate positive
things with "master" and its versions in other languages. Usually
the word designates a person with particular training in a skill:
A "master of arts" has a university degree, a "maître menuisier" or
"Tischlermeister" is particularly trained in original woodwork, more so
than a "compagnon" or "Geselle", a "maestro" takes part in creating
exceptionally nice music.
The negative connotations of the word "master" seem to come only from a
US American viewpoint from the word pair "master"/"slave"; so from my
point of view, we are importing a US American culture war, by which I do
not feel concerned, into our international project.
Ekaitz writes: "the USA imperialism is forced upon me."
Even before reading his words, I essentially felt the same. Maybe we
could call it "US American cultural dominance" to be a bit more neutral.
We are already expected to communicate in English (while I may regret
that Latin has gone out of fashion, I must admit that English is just
the most practical solution right now). We are expected to use
US American spelling. Now we consider pandering to US American
sensitivities with respect to their history on how we name our branches.
(As far as I understand, the author of the proposal is not from the USA,
but this does not invalidate the argument about cultural dominance.)
All this is somewhat ironic: We start by using a language that is foreign
to many or probably even most of us, and end up being expected to share
also the cultural connotations linked to that language (in a particular
part of the world) that would not pose a problem if we had used a
different language from the start.
So maybe we should name the principal branch "caput" or "κεφάλαιο".
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 13:53:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Mittwoch, dem 26.03.2025 um 13:21 +0100 schrieb Andreas Enge:
> Concerning the name, the current standard for git repositories is
> "master". Apart from that, I have only seen "main". So maybe we can
> agree that all other names are not practical? There is muscle memory
> involved in typing "git checkout ...", and I do not see any point in
> choosing a completely separate name only for the Guix project.
I'm pretty sure SVN users will remember trunk :)
And I don't think that "practical" is necessarily defined on the number
of other projects that use the same branch name. Perhaps within the
wider Guix ecosystem, though, a single default branch name is
preferable over an "anything goes" approach, and we seem to be heading
towards "main" if we follow this route.
> Also, my impression is that it would be better to rather quickly
> delete the master branch if we change names instead of keeping it
> around. It would be better to create an error instead of letting
> people stick with an outdated branch. In particular, we should make
> sure that "guix pull" either works with the new name or breaks
> visibly, so that people do not remain on "master" while thinking they
> are updating their system.
Could you elaborate on this? My proposal to keep "master" for the time
being, but pointing it towards "main" would make it unlikely that an
upgrade is not a real upgrade. Then, once configurations default to
using main, we can make upgrades smooth for everyone using the default
configuration.
The default configuration holds a special place here, because Guix is
also used by people who do not have a deep understanding of all of its
parts and would find a sudden, unprompted `guix pull' failure quite
confusing.
> Now to the bike shedding part. Personally, I only associate positive
> things with "master" and its versions in other languages. Usually
> the word designates a person with particular training in a skill:
> A "master of arts" has a university degree, a "maître menuisier" or
> "Tischlermeister" is particularly trained in original woodwork, more
> so than a "compagnon" or "Geselle", a "maestro" takes part in
> creating exceptionally nice music.
I think this is clearer in other languages, where the use of the word
master is more narrow and some uses, e.g. the German "lord over a
people or dominion" have fallen out of fashion. Also, "master" doesn't
translate uniquely into those languages, e.g. in German it's "meister"
for the Tischlermeister, but "magister" or "magistra" for the academic
degree – that is, until we started using English wherever we had
previously used Latin or French.
> The negative connotations of the word "master" seem to come only from
> a US American viewpoint from the word pair "master"/"slave"; so from
> my point of view, we are importing a US American culture war, by
> which I do not feel concerned, into our international project.
There is also the German word "Herrenrasse" which translates into
English as "master race"… and I don't think UK or US English makes much
of a difference w.r.t. that.
Also, I don't know enough French computing lingo to be sure, but TIL
that according to Wiktionary, maître/esclave is a thing.
> All this is somewhat ironic: We start by using a language that is
> foreign to many or probably even most of us, and end up being
> expected to share also the cultural connotations linked to that
> language (in a particular part of the world) that would not pose a
> problem if we had used a different language from the start.
Well, using a common language, we can come to a common understanding.
> So maybe we should name the principal branch "caput" or "κεφάλαιο".
Maybe "head", alluding to "HEAD"? "caput" sadly has the meaning
"broken" if we pronounce it German ;) We could also use "tête" if we
wanna be French about it :)
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 14:28:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Wed, Mar 26, 2025 at 02:52:40PM +0100 schrieb Liliana Marie Prikler:
> > Also, my impression is that it would be better to rather quickly
> > delete the master branch if we change names instead of keeping it
> > around. It would be better to create an error instead of letting
> > people stick with an outdated branch. In particular, we should make
> > sure that "guix pull" either works with the new name or breaks
> > visibly, so that people do not remain on "master" while thinking they
> > are updating their system.
> Could you elaborate on this? My proposal to keep "master" for the time
> being, but pointing it towards "main" would make it unlikely that an
> upgrade is not a real upgrade. Then, once configurations default to
> using main, we can make upgrades smooth for everyone using the default
> configuration.
Sorry, I do not know well enough how "guix pull" works to really elaborate.
And I am not sure what you mean by "master points towards main". Assume
we change the default branch; then as a committer I will push to "main",
and "master" is one commit behind. I do not think that it is possible in
git to have "master" just be an alias for "main"? (Or maybe it is on
codeberg?) Then we would have to manually or automatically let master
follow main; by running a script as a git hook doing the equivalent of
"git checkout master; git rebase origin/main; git push"
(beware of recursive "git push" hooks...)?
(Hm, this is a bit twisted, but it would be perfectly possible to have a
local branch main that follows origin/master or vice versa, right? So
locally each of us could use their own favourite terminology.)
The first time one does a "guix pull", I think it amounts to a "git
clone", so whatever the default branch is at this time will be used.
Supposedly the next "guix pull" just does the equivalent of "git pull",
so if I am on master (and master is not updated to follow main after
every commit) I will not get the update.
Probably if master is simply deleted, I will get an error message, and
could then be invited to delete $HOME/.cache/guix/checkouts? That would
be okay in my opinion.
But as said, I am convinced the technical details can be worked out,
but this requires to know exactly how "guix pull" works (which is
probably your case).
> > So maybe we should name the principal branch "caput" or "κεφάλαιο".
> Maybe "head", alluding to "HEAD"? "caput" sadly has the meaning
> "broken" if we pronounce it German ;)
Well, I sort of liked the self-deprecating pun here :)
But this was only in the bike shedding part about what we feel with
respect to the change; as said before, in reality I would oppose anything
but "master" or "main". I do not think anybody has a real problem with
"main", and then it is simply a matter of practicality to switch to the
second most used branch name instead of our own invention.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:45:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Em 26 de março de 2025 10:52:40 BRT, Liliana Marie Prikler <liliana.prikler <at> gmail.com> escreveu:
>I'm pretty sure SVN users will remember trunk :)
I never used SVN, but I always appreciate whenever I
see "trunk", because of the Git tree analogy ("branches").
--
Gabriel Santos
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:46:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:48:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas,
I share many of your points and for some others, I need to re-read with
my full attention. Here a quick comment on one specific point…
On Wed, 26 Mar 2025 at 13:21, Andreas Enge <andreas <at> enge.fr> wrote:
> ractically speaking, we could also stick with
> "master" and wait and see whether "main" becomes the majority, and
> decide to switch only if and when that happens.
…when creating a new repository, Codeberg advises:
--8<---------------cut here---------------start------------->8---
Creating a new repository on the command line
touch README.md
git init
git checkout -b main
git add README.md
git commit -m "first commit"
git remote add origin https://codeberg.org/zimoun/test.git
git push -u origin main
Pushing an existing repository from the command line
git remote add origin https://codeberg.org/zimoun/test.git
git push -u origin main
--8<---------------cut here---------------end--------------->8---
And Gitlab, Github, Bitbucket, etc. propose the same.
The initial announcement is from 2020 [1]. Well, already 5 years but I
have not found a list of projects (or examples) that switched. For
instance, FreeBSD uses main but they’ve probably started to use Git
after 2020. :-)
Well, I’ve just opened the Explore webpage [3] and browsed the first
page of repositories:
main IIIIIIIIII
master IIIII
forgejo I
linkita I
demo I
nixos I
v3 I
For sure, it’s highly biased. :-)
1: https://sfconservancy.org/news/2020/jun/23/gitbranchname/
2: https://codeberg.org/FreeBSD
3: https://codeberg.org/explore/repos
Cheers,
simon
PS:
> while I may regret
> that Latin has gone out of fashion
[…]
> "κεφάλαιο".
At the time when Latin was fashionable, people raised the exact same
argument about cultural dominance… so they proposed another good
ol’: ἡ κοινὴ διάλεκτος ! :-) But koine greek was also at some point
culturally dominant, so people proposed classical עִבְרִית. And so on.
Hum, yet another bootstrap problem. ;-)
Yeah, a branch named caput because it’s always kaputt. :-D
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:49:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas,
On Wed, 26 Mar 2025 at 15:27, Andreas Enge <andreas <at> enge.fr> wrote:
> I do not think that it is possible in
> git to have "master" just be an alias for "main"?
Hum, it seems possible directly with Git: Make master point to main
$ git symbolic-ref refs/heads/master refs/heads/main
Well, Denis gave the tips [1]. It requires an access to Savannah itself
and I’m sure Savannah admins will process if we open a ticket. :-)
Do I miss something?
Cheers,
simon
1: Re: [GCD] Migrating repositories, issues, and patches to Codeberg
Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
Wed, 19 Feb 2025 02:12:40 +0100
id:20250219021240.7ad429f1 <at> primary_laptop
https://lists.gnu.org/archive/html/guix-devel/2025-02
https://yhetil.org/guix/20250219021240.7ad429f1 <at> primary_laptop
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:49:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Em 26 de março de 2025 11:27:27 BRT, Andreas Enge <andreas <at> enge.fr> escreveu:
>[I]n reality I would oppose anything but "master" or "main".
Oh, nevermind my previous comment on "trunk" then.
I'll read up on this GCD later to see if I have anyrhing
to add to this conversation.
--
Gabriel Santos
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:50:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 15:58:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Mittwoch, dem 26.03.2025 um 15:27 +0100 schrieb Andreas Enge:
> Sorry, I do not know well enough how "guix pull" works to really
> elaborate. And I am not sure what you mean by "master points towards
> main". Assume we change the default branch; then as a committer I
> will push to "main", and "master" is one commit behind. I do not
> think that it is possible in git to have "master" just be an alias
> for "main"? (Or maybe it is on codeberg?) Then we would have to
> manually or automatically let master follow main; by running a script
> as a git hook doing the equivalent of
> "git checkout master; git rebase origin/main; git push"
> (beware of recursive "git push" hooks...)?
Git does support symbolic references – someone else already wrote about
those. Other than that, it'd probably be periodic runs of
git push origin main:master
i.e. push the current main to master. We would need to prevent
inadvertent pushes to master, though.
> (Hm, this is a bit twisted, but it would be perfectly possible to
> have a local branch main that follows origin/master or vice versa,
> right? So locally each of us could use their own favourite
> terminology.)
Yes, that is possible. We are merely talking here about the remote
view and the Guix tooling associated with it.
> The first time one does a "guix pull", I think it amounts to a "git
> clone", so whatever the default branch is at this time will be used.
> Supposedly the next "guix pull" just does the equivalent of "git
> pull", so if I am on master (and master is not updated to follow main
> after every commit) I will not get the update.
> Probably if master is simply deleted, I will get an error message,
> and could then be invited to delete $HOME/.cache/guix/checkouts? That
> would be okay in my opinion.
I think you wouldn't even have to do that, because `guix pull' supports
branches, so the pulled branch would simply switch from master to main.
> But as said, I am convinced the technical details can be worked out,
> but this requires to know exactly how "guix pull" works (which is
> probably your case).
>
> > > So maybe we should name the principal branch "caput" or
> > > "κεφάλαιο".
> > Maybe "head", alluding to "HEAD"? "caput" sadly has the meaning
> > "broken" if we pronounce it German ;)
>
> Well, I sort of liked the self-deprecating pun here :)
>
> But this was only in the bike shedding part about what we feel with
> respect to the change; as said before, in reality I would oppose
> anything but "master" or "main". I do not think anybody has a real
> problem with "main", and then it is simply a matter of practicality
> to switch to the second most used branch name instead of our own
> invention.
Fair enough.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 16:08:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Mittwoch, dem 26.03.2025 um 16:00 +0100 schrieb Simon Tournier:
> Yeah, a branch named caput because it’s always kaputt. :-D
caput for core-updates 2026 :)
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 17:07:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 76407 <at> debbugs.gnu.org (full text, mbox):
First of all Andreas, thanks for your thoughtful message.
It seems like you pretty much agree with what I shared, including the
association you make with the name master ("maestro" for me, which could
be a teacher, or a person that excels in something, but also the first
original-essential work you use for others (production molds, pillars in
buildings and so on).
In any case, it's not our association what we are considering but the
association a possible minority (which I argue that it may not exist)
may have (which I argue it may be fabricated by the fact some people
decided the word "master" was offensive).
Btw, the other day I was informed that the University of Southern
California's School of Social Work removed the "field" work from their
curriculum because it may have racist connotations related to slavery. I
think the "master" case is the same. The only difference is "master"
looks more like a natural change because we have too many voices telling
us it is.
On 2025-03-26 13:21, Andreas Enge wrote:
> The negative connotations of the word "master" seem to come only from a
> US American viewpoint from the word pair "master"/"slave"; so from my
> point of view, we are importing a US American culture war, by which I do
> not feel concerned, into our international project.
> Ekaitz writes: "the USA imperialism is forced upon me."
> Even before reading his words, I essentially felt the same. Maybe we
> could call it "US American cultural dominance" to be a bit more neutral.
> We are already expected to communicate in English (while I may regret
> that Latin has gone out of fashion, I must admit that English is just
> the most practical solution right now). We are expected to use
> US American spelling. Now we consider pandering to US American
> sensitivities with respect to their history on how we name our branches.
> (As far as I understand, the author of the proposal is not from the USA,
> but this does not invalidate the argument about cultural dominance.)
> All this is somewhat ironic: We start by using a language that is foreign
> to many or probably even most of us, and end up being expected to share
> also the cultural connotations linked to that language (in a particular
> part of the world) that would not pose a problem if we had used a
> different language from the start.
But this is something I wanted to highlight, that I think we are kind of
avoiding discussing. It's not that it is forced upon us only, it's that
we should, in my opinion, prevent that from happening because Guix is of
all people, including those that are "cultural enemies" of the USA
(because of their own reasons or because the cultural context where they
had the chance to be raised in). And they are already doing a huge
effort to be here, an effort US Americans don't need to do.
I'd rather make software for the majority of the world, than only for
those that feel comfortable with the US American eccentricities.
This includes *people* in Iran, Russia, North Korea, China (just for
mentioning some) and the rest of the globe. The world is too large, and
it's crowded.
If we want to make *people* (not just *some* people) feel comfortable,
we should take a look to the broad picture and stop looking at our own
belly button (spanish idiom :) ).
The name of the branch is the color of the bikeshed, I agree with you
all. I'd prefer if the discussion wasn't put in the terms of "which of
the colors of the US American flag do we want to use to paint it".
Because if there's no possibility to discuss the very core of this
proposition, that's how it sounds to me, and I'm not particularly a
hater of the USA. I cannot even imagine how could this all sound to others.
Being clear, changing the branch name to please US American sensibility
may be counterproductive, those that might feel underrepresented in Guix
(and probably in (free-) software development) might see how we lean
towards a worldview that is too far from theirs. No surprise that some
countries use their own software ecosystem. I don't like to work only
for less than a quarter of the planet. I think people from any place in
the world deserves this work, and those who we are trying to please are
the ones that need it the less.
This I wanted to point out when I proposed putting the Palestinian flag
in the Guix website. I'm sure that I didn't make people think as much as
I expected to, because this conversation was more confrontational than
anything. But please think about it again. We cannot pretend that a
discussion like that one would be only positive for the project, like I
think this GCD does. There is a possible negative outcome, for example,
that those who think that is unfair (maybe because they grew up watching
missiles falling in their city) leave the project. We can agree or
disagree, but that is a possibility and we should be empathetic enough
to understand it and predict it the same way we try to predict the
negative outcomes of our technical decisions.
I think my previous messages were understood as I was opposing the
change just because I'm a free-speech absolutist (heh) or an
anti-"woke". It's not the change what I oppose, I reject its terms, and
the premises it is proposed on top of, which I think are simply
counterproductive in a way that is not even contemplated in the document.
And if you wish, strictly speaking on the document. It describes
potential social benefits using heavy loaded words ("harmful", "racist",
"sexist") but it doesn't list any social drawback. That's more than
enough to understand how biased the proposal is (it's just so obvious!)
and how difficult that is to argue against. The belligerence this has
been defended with doesn't help much to try to understand the answers it
got.
I could say mea culpa a for my part, maybe my wording wasn't the best,
but I don't think my previous arguments were really listened to, simply
because the rename *is the right thing to do*.
I don't know if Simon's question "are we really looking for consensus
here?" was pointed to me, but I've been trying to. Maybe poorly,
addressing the core issues of the proposal, and saying, probably we
shouldn't have even started it.
I hope this speaks more clearly about what I said before.
Best,
Ekaitz
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 20:21:03 GMT)
Full text and
rfc822 format available.
Message #182 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Ekaitz, all,
On Wed, 26 Mar 2025 at 18:06, Ekaitz Zarraga <ekaitz <at> elenq.tech> wrote:
> I don't know if Simon's question "are we really looking for consensus
> here?" was pointed to me, but I've been trying to. Maybe poorly,
> addressing the core issues of the proposal, and saying, probably we
> shouldn't have even started it.
Not specifically to you, Ekaitz; specifically to you, all. :-)
Still, I am not convinced we are trying to build something together.
For example, you, Ekaitz wrote in the message I reply:
And if you wish, strictly speaking on the document. It describes
potential social benefits using heavy loaded words ("harmful", "racist",
"sexist") but it doesn't list any social drawback. That's more than
enough to understand how biased the proposal is (it's just so obvious!)
and how difficult that is to argue against. The belligerence this has
been defended with doesn't help much to try to understand the answers it
got.
And this is the typical anti-pattern – IMHO – How to not build together
a consensus. This is confrontational, again IHMO. For instance,
Ekaitz, compare this frame or one of [1] and the first question below.
FWIW, my views about how consensus works is to friendly ask about
specific wording and propose alternatives. It’s not to have a judgement
or express a dismissive opinion.
Then, it’s because we are specific on the document itself that we can
build something together – as we do with regular patches. By asking
specifically on the document itself, it’s possible to friendly point
something that might appear useless or poorly worded, and maybe the GCD
itself might become weak or pointless. Well, as we do with regular
patches, no? Else all is doomed before we even try.
IIUC, the master problem is about these two sections:
# Summary
Currently, much of Guix's development takes place on the “master”
branch. This name is neither particularly meaningful nor inclusive;
choosing to use it may inadvertently alienate potential contributors.
To mitigate these effects, we should more clearly communicate, what the
default branch is all about.
# Motivation
It is well known, that Git works with whatever branch name one chooses.
However, for historical reasons, the default/initial/main branch for
development used to be “master” — particularly in 2012, when the first
commit to Guix was made.
Recent versions of Git support arbitrary initial branches and the
default branch name is subject to change upstream, at least in part
because the current default — “master” — may be perceived as harmful.
While the intended meaning is something close to “an original, from
which copies are made”, there are several other meanings of the word
that spring to mind more easily, some of have a racist or sexist
connotation.
One goal of the Guix community is to foster a healthy community around
the software we use. Using clear language that does not pertain to
harmful stereotypes is a key towards achieving this goal. Thus, as a
proactive step, we should rename the default branch.
Therefore, being active and engaging would mean:
+ Can we rewrite the Motivation section? Because people have Master
degree and the diploma’s not yet renamed, to my knowledge. Is the
words master really harmful, racist or sexist?
+ About the Motivation, why not narrow the scope and focus on some
aspects: quoting [1] « a) most users leave unchanged the Git default
"main", therefore "master" will become increasingly uncommon and
unexpected, b) the choice of "main" is masterfully similar when
tab-completing or looking through a sorted list of refs, and c) the
move to Codeberg presents a hopefully rare opportunity combine
disruptive changes »
+ The Motivation appears to me poorly written because I’ve never heard
that the term master would be harmful or racist or sexist. Do we have
references for backing this claim?
Etc.
Bah after a frank but friendly discussion, if the Motivation appears
empty, then it answers by itself, no?
Why do people need to drag in the discussion – in no specific order–: my
Black friends, personal history with slavery or dictatorship, opinions
on US imperialism, Gaza massacre, English language, Ukrainian war, a
quote of Frantz Fanon, etc.
Do not take me wrong, I see the gift to have people with different
backgrounds on board, and I celebrate because people do not fear to
generously share what they think. Even, I’m never the last to
cross-pollinate^W -battle ideas or learn about what other people think.
However, let be honest, this dragging, is it really helpful to build
something together?
Build a consensus implies a self-discipline when approaching the
discussion. It’s about patience and stay on the document itself. I let
you all to judge who drifted or framed it out of the scope.
Somehow, I’m very disappointed about not being able to build together.
Bah I’m still confident about Decision Making via consensus, even on
such bikeshedding topic! Well, I’m confident because I’m sure we will
all learn about this GCD and so reset to friendly questions on the
document itself when approaching the Discussion Period.
Anyway, I’m done with this GCD.
Bye.
simon
1: Re: [GCD] Rename “main” branch
Ekaitz Zarraga <ekaitz <at> elenq.tech>
Thu, 20 Feb 2025 23:57:35 +0100
id:c2532d09-e54b-49fe-9ace-dca55239f394 <at> elenq.tech
https://lists.gnu.org/archive/html/guix-devel/2025-02
https://yhetil.org/guix/c2532d09-e54b-49fe-9ace-dca55239f394 <at> elenq.tech
2: [bug#76407] [GCD] A better name for the default branch
Greg Hogan <code <at> greghogan.com>
Fri, 28 Feb 2025 10:46:05 -0500
id:CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg <at> mail.gmail.com
https://issues.guix.gnu.org/76407
https://issues.guix.gnu.org/msgid/CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg <at> mail.gmail.com
https://yhetil.org/guix/CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg <at> mail.gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 21:01:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am Mittwoch, dem 26.03.2025 um 18:06 +0100 schrieb Ekaitz Zarraga:
> In any case, it's not our association what we are considering but the
> association a possible minority (which I argue that it may not exist)
> may have (which I argue it may be fabricated by the fact some people
> decided the word "master" was offensive).
Can we move past arguments that deny the existence of people? I think
that discussion was already had five years ago and we do not need to
rehash it.
> But this is something I wanted to highlight, that I think we are kind
> of avoiding discussing. It's not that it is forced upon us only, it's
> that we should, in my opinion, prevent that from happening because
> Guix is of all people, including those that are "cultural enemies" of
> the USA (because of their own reasons or because the cultural context
> where they had the chance to be raised in). And they are already
> doing a huge effort to be here, an effort US Americans don't need to
> do.
>
> I'd rather make software for the majority of the world, than only for
> those that feel comfortable with the US American eccentricities.
>
> This includes *people* in Iran, Russia, North Korea, China (just for
> mentioning some) and the rest of the globe.
So, in your opinion, is using a branch name other than master something
that precludes people from Iran, Russia, the DPRK or China from
contributing, or would this only be the case if we chose a name that is
particularly hostile – either directly or by accident – to those
people. Continuing, if we had a sizable community of e.g. Chinese
people telling us that using this or that sinophobic term as branch
name is a bad idea, should we not honour those as well?
Now, I am personally not aware that any of the current suggestions are
sinophobic or discriminatory w.r.t. any other ethnicity, religion,
etc., but I am willing to be corrected on that.
> The name of the branch is the color of the bikeshed, I agree with you
> all. I'd prefer if the discussion wasn't put in the terms of "which
> of the colors of the US American flag do we want to use to paint it".
So, the US flag is composed of *checks notes* a desire to avoid racist
and sexist rhetoric? Well, that colours me surprised.
> Being clear, changing the branch name to please US American
> sensibility may be counterproductive, those that might feel
> underrepresented in Guix (and probably in (free-) software
> development) might see how we lean towards a worldview that is too
> far from theirs. No surprise that some countries use their own
> software ecosystem. I don't like to work only for less than a quarter
> of the planet. I think people from any place in the world deserves
> this work, and those who we are trying to please are the ones that
> need it the less.
Can I get 1 USD the next time you insinuate that this proposal exists
solely to placate the interests of people in the US? I also accept
euros if need be.
Now there might be a nugget of truth within this paragraph in that
there is a risk to inadvertently choose a branch name that alienates a
particular group of people. If you feel that this is not sufficiently
discussed as a drawback to the proposal, then perhaps I concede that
such wording ought to be added.
Other than that, I do think it is understood based on our CoC that we
should not choose such a name in the first place and such names should
not be up for debate. In fact, the section on the choice of a name
opens up with the goal to find a name that "Guix contributors, as a
whole, feel comfortable with".
Perhaps it was a bit naïve of me to assume a name exists that all of us
can actually get behind. It appears as though some people will feel
uncomfortable with anything but master for the mere reason that people
dared questioning "master". I can't help but feel like all this talk
about US imperialism this, US imperialism that is to waste time and
effort that could otherwise be spent towards effecting positive change.
I know I am not reviewing any patches as I type out this reply.
> This I wanted to point out when I proposed putting the Palestinian
> flag in the Guix website. I'm sure that I didn't make people think as
> much as I expected to, because this conversation was more
> confrontational than anything. But please think about it again. We
> cannot pretend that a discussion like that one would be only positive
> for the project, like I think this GCD does.
This is not at all how I read your proposal towards putting flags on
websites. In fact, it didn't even look like a proposal.
> There is a possible negative outcome, for example, that those who
> think that is unfair (maybe because they grew up watching missiles
> falling in their city) leave the project. We can agree or disagree,
> but that is a possibility and we should be empathetic enough to
> understand it and predict it the same way we try to predict the
> negative outcomes of our technical decisions.
Should we also predict that those who grew up watching missiles falling
in their city are at some point actually hit by said missiles? I mean,
there is a possible negative outcome wherein we discuss trivial matters
such as branch naming while the powers that be invest in arms to start
a third world war. Should we not be in the streets in this very
instant to stop our local governments from spending money on war
machines that would be much more direly needed in the education and
healthcare sectors?
> And if you wish, strictly speaking on the document. It describes
> potential social benefits using heavy loaded words ("harmful",
> "racist", "sexist") but it doesn't list any social drawback. That's
> more than enough to understand how biased the proposal is (it's just
> so obvious!)
I do have a small drawbacks section containing loaded words such as
"evolve", "future", "satisfaction", and "opinion". Oh, and "obvious".
> I don't know if Simon's question "are we really looking for consensus
> here?" was pointed to me, but I've been trying to. Maybe poorly,
> addressing the core issues of the proposal, and saying, probably we
> shouldn't have even started it.
Simon already pointed out (in reply to Andreas) how Codeberg et al.
advise "main" as the default branch for new projects and how projects
currently appear to be using "main" a lot as a result.
If anything about the framing of the GCD is wrong, it's that we are not
the vanguard – we are in fact lagging behind.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 21:27:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
On 2025-03-26 22:00, Liliana Marie Prikler wrote:
> Am Mittwoch, dem 26.03.2025 um 18:06 +0100 schrieb Ekaitz Zarraga:
>> In any case, it's not our association what we are considering but the
>> association a possible minority (which I argue that it may not exist)
>> may have (which I argue it may be fabricated by the fact some people
>> decided the word "master" was offensive).
> Can we move past arguments that deny the existence of people? I think
> that discussion was already had five years ago and we do not need to
> rehash it.
I'm going just to ignore this.
>> But this is something I wanted to highlight, that I think we are kind
>> of avoiding discussing. It's not that it is forced upon us only, it's
>> that we should, in my opinion, prevent that from happening because
>> Guix is of all people, including those that are "cultural enemies" of
>> the USA (because of their own reasons or because the cultural context
>> where they had the chance to be raised in). And they are already
>> doing a huge effort to be here, an effort US Americans don't need to
>> do.
>>
>> I'd rather make software for the majority of the world, than only for
>> those that feel comfortable with the US American eccentricities.
>>
>> This includes *people* in Iran, Russia, North Korea, China (just for
>> mentioning some) and the rest of the globe.
> So, in your opinion, is using a branch name other than master something
> that precludes people from Iran, Russia, the DPRK or China from
> contributing, or would this only be the case if we chose a name that is
> particularly hostile – either directly or by accident – to those
> people. Continuing, if we had a sizable community of e.g. Chinese
> people telling us that using this or that sinophobic term as branch
> name is a bad idea, should we not honour those as well?
No.
I said we should be very aware of what kind of worldview we impose in
our project.
And the main point that I've been trying to make is that a Chinese
person is way less likely to propose such a change because of their culture.
> Now, I am personally not aware that any of the current suggestions are
> sinophobic or discriminatory w.r.t. any other ethnicity, religion,
> etc., but I am willing to be corrected on that.
>
>> The name of the branch is the color of the bikeshed, I agree with you
>> all. I'd prefer if the discussion wasn't put in the terms of "which
>> of the colors of the US American flag do we want to use to paint it".
> So, the US flag is composed of *checks notes* a desire to avoid racist
> and sexist rhetoric? Well, that colours me surprised.
>
>> Being clear, changing the branch name to please US American
>> sensibility may be counterproductive, those that might feel
>> underrepresented in Guix (and probably in (free-) software
>> development) might see how we lean towards a worldview that is too
>> far from theirs. No surprise that some countries use their own
>> software ecosystem. I don't like to work only for less than a quarter
>> of the planet. I think people from any place in the world deserves
>> this work, and those who we are trying to please are the ones that
>> need it the less.
> Can I get 1 USD the next time you insinuate that this proposal exists
> solely to placate the interests of people in the US? I also accept
> euros if need be.
I'm not insinuating it. I'm saying it. USA and those places that adopted
their culture.
> Now there might be a nugget of truth within this paragraph in that
> there is a risk to inadvertently choose a branch name that alienates a
> particular group of people. If you feel that this is not sufficiently
> discussed as a drawback to the proposal, then perhaps I concede that
> such wording ought to be added.
That's not what I'm saying.
I don't care about the new name we choose. Is the act of changing names
that might be uncomfortable to many.
It is to me. I don't think words are this important.
And please don't answer me I don't understand because I am privileged.
> Other than that, I do think it is understood based on our CoC that we
> should not choose such a name in the first place and such names should
> not be up for debate. In fact, the section on the choice of a name
> opens up with the goal to find a name that "Guix contributors, as a
> whole, feel comfortable with".
>
> Perhaps it was a bit naïve of me to assume a name exists that all of us
> can actually get behind. It appears as though some people will feel
> uncomfortable with anything but master for the mere reason that people
> dared questioning "master". I can't help but feel like all this talk
> about US imperialism this, US imperialism that is to waste time and
> effort that could otherwise be spent towards effecting positive change.
> I know I am not reviewing any patches as I type out this reply.
>
Our argument is a waste of time?
It's you who wanted to discuss this (nah, you didn't, you just wanted to
apply it), it's several people telling you this is related with US
American world view (I count 3 already). Real people.
>> This I wanted to point out when I proposed putting the Palestinian
>> flag in the Guix website. I'm sure that I didn't make people think as
>> much as I expected to, because this conversation was more
>> confrontational than anything. But please think about it again. We
>> cannot pretend that a discussion like that one would be only positive
>> for the project, like I think this GCD does.
> This is not at all how I read your proposal towards putting flags on
> websites. In fact, it didn't even look like a proposal.
That's the point. Your GCD, as it is worded, is not a proposal.
I proposed that as a thought exercise.
>> There is a possible negative outcome, for example, that those who
>> think that is unfair (maybe because they grew up watching missiles
>> falling in their city) leave the project. We can agree or disagree,
>> but that is a possibility and we should be empathetic enough to
>> understand it and predict it the same way we try to predict the
>> negative outcomes of our technical decisions.
> Should we also predict that those who grew up watching missiles falling
> in their city are at some point actually hit by said missiles? I mean,
> there is a possible negative outcome wherein we discuss trivial matters
> such as branch naming while the powers that be invest in arms to start
> a third world war. Should we not be in the streets in this very
> instant to stop our local governments from spending money on war
> machines that would be much more direly needed in the education and
> healthcare sectors?
It's really hard to discuss with you, Liliana.
That has nothing to do with what I said.
You are trying to make a change that has a huge political and religious
background, if you don't understand that it might have social drawbacks
maybe you are not the right person to propose this kind of change.
You have been taking all my arguments literally and distorting them to
the extreme. I'm trying to give you some context. I'm not great at it.
But you are not helping at all.
>> And if you wish, strictly speaking on the document. It describes
>> potential social benefits using heavy loaded words ("harmful",
>> "racist", "sexist") but it doesn't list any social drawback. That's
>> more than enough to understand how biased the proposal is (it's just
>> so obvious!)
> I do have a small drawbacks section containing loaded words such as
> "evolve", "future", "satisfaction", and "opinion". Oh, and "obvious".
Come on.
>> I don't know if Simon's question "are we really looking for consensus
>> here?" was pointed to me, but I've been trying to. Maybe poorly,
>> addressing the core issues of the proposal, and saying, probably we
>> shouldn't have even started it.
> Simon already pointed out (in reply to Andreas) how Codeberg et al.
> advise "main" as the default branch for new projects and how projects
> currently appear to be using "main" a lot as a result.
>
> If anything about the framing of the GCD is wrong, it's that we are not
> the vanguard – we are in fact lagging behind.
>
> Cheers
In the vanguard of what?
It's a very spanish thing to tell your kids "If the other kids jump of a
cliff, do you jump too?"
Again, you are doing the same thing you have been doing since the
beginning, trying to counter what I say point by point, taking literally
a couple of words of the picture I'm trying to paint.
It is clear to me that we are not compatible at all, as it was already
from previous interaction.
Consider me done.
This is just nonsense. This is not a conversation.
Bye.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 26 Mar 2025 21:41:03 GMT)
Full text and
rfc822 format available.
Message #191 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>> There is a possible negative outcome, for example, that those who
>> think that is unfair (maybe because they grew up watching missiles
>> falling in their city) leave the project. We can agree or disagree,
>> but that is a possibility and we should be empathetic enough to
>> understand it and predict it the same way we try to predict the
>> negative outcomes of our technical decisions.
> Should we also predict that those who grew up watching missiles falling
> in their city are at some point actually hit by said missiles? I mean,
> there is a possible negative outcome wherein we discuss trivial matters
> such as branch naming while the powers that be invest in arms to start
> a third world war. Should we not be in the streets in this very
> instant to stop our local governments from spending money on war
> machines that would be much more direly needed in the education and
> healthcare sectors?
Military spending should increase, not decrease. I personally would
prefer if more of those money stayed in Europe by spending them on
weapons manufactured here, instead of paying the protection racket to
the US (which, with Trump, looks increasingly like a bad deal).
But given the Russian invasion and atrocities committed by them, Europe
needs a strong, self-sufficient fighting force to act as an deterrent.
And, as demonstrated in last ~30 years, it is *hard* to have that force
by spending less than 2% of GDP.
So, to answer your question, no, I do not think we should be in the
streets with the goal of forcing *our* governments to spend less on
tools needed for our defense.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 14:08:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Guix,
as the date for the GCD 003 was set to February 18th, the discussion
period actually ended on Saturday already. I have incorporated some
changes on Sunday to realign the proposal with GCD 002 (the Codeberg
one), but barring any emergency changes there, GCD 003 is now to be
considered final.
As outlined in GCD 001, please respond to this mail with one of the
following:
- “I support”, meaning that you support the proposal;
- “I accept”, meaning that you consent to the implementation of the
proposal;
- “I disapprove”, meaning that you oppose the implementation of the
proposal.
To count my own vote, I support the change of the default branch name
to “main”.
Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 15:19:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Liliana,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
I support.
Ludo’.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 15:20:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 16:19:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept.
Liliana Marie Prikler <liliana.prikler <at> gmail.com> ezt írta (időpont:
2025. ápr. 21., H, 16:07):
>
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 17:08:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I disapprove.
--
Christopher Howard
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 17:18:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I support.
- Dave
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 17:39:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
I accept.
P.S. The link in “On other channels” has the wrong syntax. The link and
label are swapped.
- [https://issues.guix.gnu.org/49252](HEAD may be used freely)
+ [HEAD may be used freely](https://issues.guix.gnu.org/49252)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 18:06:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I disapprove
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 18:08:03 GMT)
Full text and
rfc822 format available.
Message #218 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Christopher Howard <christopher <at> librehacker.com> writes:
> I disapprove.
>
> --
> Christopher Howard
Hi Christopher,
It seems like you are not a member of any team. This means you are not
eligible to vote on the GCD.
In any case, please explain your rationale for disapproval. To quote the
GCD process:
>Thus, no decision is made against significant concerns; these concerns are
>actively resolved through counter proposals. A deliberating member
>disapproving a proposal bears a responsibility for finding alternatives,
>proposing ideas or code, or explaining the rationale for the status quo.
Have a nice day,
Noé
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 18:11:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hello,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
I support.
Regards,
--
Nicolas Goaziou
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 18:16:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 76407 <at> debbugs.gnu.org (full text, mbox):
“I accept”
On 2025-04-21 14:07, Liliana Marie Prikler wrote:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
(for future votes can the Deliberation period notice please provide a
reference to the discussion page and the relevant GCD(s))
https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/003-rename-default-branch.md?h=main
Note the irony of the flag above -- if its fine on the savannah,... ;)
https://issues.guix.gnu.org/76407
Jonathan McHugh
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 18:44:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 76407 <at> debbugs.gnu.org (full text, mbox):
> It seems like you are not a member of any team. This means you are not
> eligible to vote on the GCD.
Oh okay. The request for votes, address to "Guix", didn't mention the voter requirements. If you would that in future vote requests, you might avoid a lot of pointless responses.
>
> In any case, please explain your rationale for disapproval. To quote the
> GCD process:
>
>>Thus, no decision is made against significant concerns; these concerns are
>>actively resolved through counter proposals. A deliberating member
>>disapproving a proposal bears a responsibility for finding alternatives,
>>proposing ideas or code, or explaining the rationale for the status quo.
>
I am fundamentally opposed to avoiding the branch name "master", simply because this word supposedly has racist overtones. I perceive this is part of a larger CRT and PC movement that aims to eradicate from public consciousness and history anything that can be remotely connected to something that people find offensive.
The branch name "master" has a long historical precedent. Furthermore, the branch name "master" is much more colorful and descriptive than "main". I like to think of the "master disk", which is a very important recording from which other copies are made.
Also, even if the intended analogy of "master" was intended to refer to "master" and "slave" branches, that wouldn't make the word a bad choice, and is not an inherently racist idea. The concepts of "master" and "slave" can be used in computing to refer to software or networking architectures where some processes are totally subservient to others. Because we design some processes to be slaves to others, that doesn't mean that anyone is advocating for sailing off to foreign shores and kidnapping humans.
Furthermore, isn't it offensive, to people whose ancestors actually were slaves, to go around eradicating from human memory all cultural, lexical, and historical references that might possibly remind us of the past existence of slavery?
--
Christopher Howard
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 19:00:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-04-21, Liliana Marie Prikler wrote:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
I accept.
...with reservations...
While I initially had been inclined to "support" this as an issue of
little consequence that would be simple enough to move forward with,
there were some very strongly contrary responses that I feel went
essentially unresolved.
The nature of (at least some of) those responses were largely a negation
that left little room to discuss how to move forward, which left me at
an impass as to how to even continue the discussion.
Only in retrospect of having encountered this situation did I realize
there is a fundamental flaw in the GCD process (at least in my
opinion)... in that there is a presumption of moving forward and
accepting the proposed changes (in some capacity), rather than
maintaining the status quo. E.g. a person has to propose improvements in
order to reject the proposal, but there is nowhere in the process that
handles a fundamental disagreement about the proposal in any form. This
is contrary to any other genuine consensus process I have worked with.
Which... is certainly out of scope for GCD 003 "Rename the default
branch", but because it is a clear example of a flaw of this GCD
process, figured it was worth noting.
live well,
vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 19:00:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 21, 2025 at 2:08 PM Noé Lopez <noelopez <at> free.fr> wrote:
>
> Christopher Howard <christopher <at> librehacker.com> writes:
> It seems like you are not a member of any team. This means you are not
> eligible to vote on the GCD.
Where is this documented? Perhaps we should better distinguish votes
by deliberating members. Apache "PMC members have formally binding
votes, but in general communities encourage all their members to vote,
even if their votes are only advisory"
[https://www.apache.org/foundation/voting.html].
> In any case, please explain your rationale for disapproval. To quote the
> GCD process:
>
> >Thus, no decision is made against significant concerns; these concerns are
> >actively resolved through counter proposals. A deliberating member
> >disapproving a proposal bears a responsibility for finding alternatives,
> >proposing ideas or code, or explaining the rationale for the status quo.
This "finding alternatives, proposing ideas or code, or explaining the
rationale for the status quo" is the discussion period. I do agree
that summarizing one's viewpoints (and how these issues went
unaddressed) when voting for "disapproval" is worthwhile ("withdrawal
does not necessarily equate with rejection; it could mean that more
discussion and thought is needed before ideas in the GCD are accepted
by the community").
> Have a nice day,
> Noé
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 19:27:01 GMT)
Full text and
rfc822 format available.
Message #236 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Greg Hogan <code <at> greghogan.com> writes:
> On Mon, Apr 21, 2025 at 2:08 PM Noé Lopez <noelopez <at> free.fr> wrote:
>>
>> Christopher Howard <christopher <at> librehacker.com> writes:
>> It seems like you are not a member of any team. This means you are not
>> eligible to vote on the GCD.
>
> Where is this documented? Perhaps we should better distinguish votes
> by deliberating members. Apache "PMC members have formally binding
> votes, but in general communities encourage all their members to vote,
> even if their votes are only advisory"
> [https://www.apache.org/foundation/voting.html].
>
I am not a native english speaker, so a difference between eligibile and
deliberating member was not what I was trying to point out, it seems the
example you provide is similar to our GCD process.
The GCD process can be found at
<https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/tree/001-gcd-process.md>.
Here is the related paragraph:
>The *deliberation period* starts when the authors publish a final version
>of the GCD at `info-guix <at> gnu.org`. Anyone who is a team member is a
>deliberating member and is encouraged to contribute to the deliberation.
>> In any case, please explain your rationale for disapproval. To quote the
>> GCD process:
>>
>> >Thus, no decision is made against significant concerns; these concerns are
>> >actively resolved through counter proposals. A deliberating member
>> >disapproving a proposal bears a responsibility for finding alternatives,
>> >proposing ideas or code, or explaining the rationale for the status quo.
>
> This "finding alternatives, proposing ideas or code, or explaining the
> rationale for the status quo" is the discussion period. I do agree
> that summarizing one's viewpoints (and how these issues went
> unaddressed) when voting for "disapproval" is worthwhile ("withdrawal
> does not necessarily equate with rejection; it could mean that more
> discussion and thought is needed before ideas in the GCD are accepted
> by the community").
>
Agreed, though it is not specified that the quoted paragraph refers only
to the discussion period. It is part of a section on consensus based
decision making, which applies to the whole GCD process and Guix in
general.
Have a nice day,
Noé
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 21:29:09 GMT)
Full text and
rfc822 format available.
Message #239 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
Vagrant Cascadian <vagrant <at> debian.org> writes:
> Only in retrospect of having encountered this situation did I realize
> there is a fundamental flaw in the GCD process (at least in my
> opinion)... in that there is a presumption of moving forward and
> accepting the proposed changes (in some capacity), rather than
> maintaining the status quo. E.g. a person has to propose improvements in
> order to reject the proposal, but there is nowhere in the process that
> handles a fundamental disagreement about the proposal in any form. This
> is contrary to any other genuine consensus process I have worked with.
The fundamental disagreement is expressed with “I disapprove”, meant to
be a last resort if all attempts to build consensus failed.
I’m curious how else this could be handled, based on your experience.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 21:52:03 GMT)
Full text and
rfc822 format available.
Message #242 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
I disapprove.
I do actually still support the idea of moving away from master as a
branch name, but I think the implementation of GCD 003 as it currently
stands is lacking.
I've been using trunk as the master branch for the last couple of months
for some of the Guix Git repositories that I'm more involved in on
Savannah. There's still a need to delete the branch master, but I'm
unclear whether if this GCD goes through, it would be necessary to
change from trunk to main. Personally I dislike main as a branch name
and prefer trunk.
Going back to my concerns earlier in the discussion, there's nothing in
GCD 003 about keeping the data service or bordeaux build farm working
with a change to the master branch name. Maybe it's not necessary to
include anything in the GCD about branch name replacements in
configuration, but both the build farm and data service have data
connected to the Git branch, and it's less clear what to do with this
data and how to handle historic references to the master branch.
Maybe these are just minor issues and not worth disapproving the GCD
over, but it feels like it's these kind of issues that the process in
general should address, even if that is to just note that it was raised,
discussed and the conclusion was to not include it in the scope.
I do still hope that an agreement to change the master branch name can
be reached, but I think it's important to handle it well, both in terms
of this GCD process which is in it's infancy still, and also the actual
technical/user impactful changes.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 21 Apr 2025 22:26:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo'
On Mon, Apr 21 2025, Ludovic Courtès wrote:
> I’m curious how else this could be handled
Vagrant will surely repond better than I can, but just to get the ball
rolling: Debian has a mandated "further discussion" (FD) option, which
was somehow renamed to "none of the above" (NOTA). [1]
Kind regards
Felix
[1] https://www.debian.org/vote/2021/vote_003
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 22 Apr 2025 00:00:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I support, because main is a better name and the cost will be handled
well.
Despite and not because renaming sends a political message, specifically
Ekaitz wrote <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76407#95>:
3. I don't think the change will make the project more inclusive, but
may be counterproductive.
(I disagree with Ekaitz’ other numbers.)
The GCD embraces and emphasizes inclusiveness as motivation for naming,
though it acknowledges the ongoing political debate in the drawbacks.
The GCD’s wording is honest, but is not why I say I support.
Regards,
Florian
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 22 Apr 2025 03:59:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the
> discussion
> period actually ended on Saturday already. I have incorporated
> some
> changes on Sunday to realign the proposal with GCD 002 (the
> Codeberg
> one), but barring any emergency changes there, GCD 003 is now to
> be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of
> the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of
> the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of
> the
> proposal.
>
> To count my own vote, I support the change of the default branch
> name
> to “main”.
>
I support.
Thanks,
-- Ian
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 22 Apr 2025 07:37:03 GMT)
Full text and
rfc822 format available.
Message #254 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 22 Apr 2025 08:12:01 GMT)
Full text and
rfc822 format available.
Message #257 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On 21 Apr, Liliana Marie Prikler wrote:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
>
I disapprove.
I don't think the deliberations on this have gone well either from a group dynamics or technical perspective. It may be that it's simply too social-political to go well, or that as a group we're too new at this type of formal consensus building to do it well. It's an extremely difficult area. At this point I think it needs some calm and further discussion.
Steve / Futurile
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 03:39:01 GMT)
Full text and
rfc822 format available.
Message #260 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
dom 23 mar 2025 às 11:54:25 (1742741665), ludo <at> gnu.org enviou:
> Egun on Ekaitz,
>
> Ekaitz Zarraga <ekaitz <at> elenq.tech> skribis:
>
> > Also, what drains me from this is not only the fact that this is an
> > unreasonable change in many levels, but the fact that those who push
> > for it don't care about being reasonable but do care about winning and
> > labeling others as "far right". […]
>
> I haven’t read in detail the previous discussion on guix-devel that you
> must be referring to, but derogatory comments like those you report
> could be a violation of the code of conduct.
>
I have spent quite some time reading the discussion and what I saw
was the exact opposite of what Ekaitz is claiming.
For the record: I do not personally believe for one second that
Ekaitz has either argued in good faith on this thread or that their
interjections were aimed at consensus building at all. I also do
believe that their wording were inviting others to harass Liliana
and anyone who openly supports oppressed minorities. And I see
that as being very problematic since it's comming from someone with
commit rights on our project. I'll elaborate on this further down.
Normally, I would have just skipped this whole thread after the first
few troublesome remarks I've read, as I do know that nothing good
comes out of this sort of interactions and I'm beyond hoping some
people to face that they are very much part of the problem and to
change their harmful ways toward others.
However, this community is very dear to me and, being so, I don't
want to let this kind of behaviour be normalized around here. I also
know I've been wrong many times in my life and hopefully this is one
of those times.
That being said, I'll reframe the issue at hand in the hopes of
untangling it from some dead end discussions, most importantly those
related to subjective perceptions, cultural-societal customs and
mores and personal intentions.
First of all: the strugle against oppression and for human rights
is _NOT_ one that can be put to majority voting, opinion polling or
other numerical methods of decision making. That would be tantamount
to requiring oppressed minorities to be majorities to have their
issues, interests taken seriously.
The paradox is clear cut. However, Ekaitz has leaned on this numbers
game more than once as if saying that "a minority is a minority" were
some kind of "argument" or ARGUMENT as they put it. Make Minorities
Great Again.
If that was the whole of it, one could ascribe it to a lack of a
proper logical education or reasoning on their part. But they didn't
stop there. Over and over they put into question the actual
_existence_ of such minority, proceeded to claim that these people
are "imaginary", claimed that their lack of interactions with this
minority is some kind of proof of their non-existence and _demanded_
to be _convinced_ of the contrary.
There are many issues on that reasoning, but for us here three stand
out:
1. They are implying that those who proposed/supported this GCD are
either brainwashed puppets, liers, ill-intentioned or non-people;
2. They are demanding that people who are oppressed/victimized "show
their faces" on this public fora, conveniently ignoring that those
people could and probably would be targeted after showing their
faces, which is a form of violence in itself;
3. They are posing as if they have to be convinced for things to
proceed, not as if the burden was on them to show that their
disagreement is based on reasons that are shared by the community.
More than that, they then proceeded to claim that this non-existent
imaginary folks where some kind of super majority which would win by
a land slide on this GCD and to pose as some sort of vilanized
defender of _real_ oppressed people which would be very much harmed
by such a change, even though they don't say _HOW_ such people are
being harmed by the current GCD. This is all well-known playbook
tactics of fascists/nazis which no one claimed them to be, but which
they themselves rushed to say they are being labeled. Another old
trick on the aforementioned playbook. Say it first so as to
discredit any one who says it later. Play the victim of a
Schrödinger enemy, one that is at the same time super strong and
patetically weak.
To add insult to injury, they then proceeded to claim that they
couldn't care less for the name of the default branch. So, even
though they don't actually care, they somehow find the strenght, time
and resources to be _very_ involved in denying that the proposal
could have any meaning or benefit at all and that it is outright
harmful to the project, opening the gates to some flood of similar
proposals. Similar on what? On being against oppression?
Polical movements, ethical considerations and a clear stance against
oppression all require that we take sides and that we make some
people unconfortable.
The question is _NOT_ which is the optimal decision that will make
the greater number of people happy. That is easy: go by the status
quo, it is the status quo because the majority is conformant to it.
The question is: which decision brings us closer to a society without
or with the bare minimum possible oppression?
Also, oppression does not cease to be oppression because those who
are oppressed do not or cannot recognize it as oppression. It does
not matter that you happen to know someone who is a black, blind,
handicaped, fat, old, trans, muslim, schizo, cognitively impaired
illegal immigrant who happens to not care about this issue. Their
opinion is not the "truth" on the matter at hand. It's just their
opinion. And they are only a flawed human who are trying to cope
with their lot on life. The fact that they have a huge following,
became internet influencers and got thousands of likes on their
message saying that they don't care is not proof that this is not
an issue, it is rather proof that there is social aceptance for
things to stay as they are. But then again, oppression has always
had social acceptance, it cannot exist without it, there is no need
to prove it.
Finally, I despise imperialism, I despise corporations, I despise PR
stunts and I despise propaganda, but corporations and empires trying
to pander to progressive causes is _NOT_ the reason I despise them.
The reason I despise them is because they do cause and maintain a
state of normalized oppression. But unlike me, there are those who
don't have any issues with oppression as long as they themselves can
assume the role of oppressors. These are the people who have issues
every time someone tries to critically question the status quo and
to propose tiny changes to the way we talk, behave, think.
Of course branch names on guix won't end oppression, no one is
expecting that. Of course "master" has other meanings which are
unrelated to slavery, no one is saying it does not. However, the
harmful meaning was brought up and some people showed issued with
it. Is there a strong reason to keep this handle for our repos in
sight of that? Some prople brought valid concerns: guix time machine
for instance.
Pandering to those who might feel alienated by moving away from this
name is not a valid concern IMO. Why is this word so special to
them? Or, if it is not special to them, why all this noise?
PS: many times people's rights were invoked to defend this position.
Let me then remember that capitalists have a right to hoard wealth,
slavers had a right to trade on human lives and copyright holders
have a right to keep their code proprietary. That does not mean
we should support their "rights". At least for the last one, I think
it is safe to say that our project very much does not support that
right.
PPS: Since nation-states were brought up as a subject, here is my 2c
on that front: Spain is well-known for having excelled at two things:
inquisition and genocide.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 03:41:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
seg 21 abr 2025 às 16:07:14 (1745262434), liliana.prikler <at> gmail.com enviou:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
I support.
Thanks!
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 09:13:02 GMT)
Full text and
rfc822 format available.
Message #266 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On 2025-04-23 05:37, André Batista wrote:
> I do not personally believe for one second that
> Ekaitz has either argued in good faith
Dude, relax.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 11:24:03 GMT)
Full text and
rfc822 format available.
Message #269 received at 76407 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Apr 2025 22:07:14 +0800,
Liliana Marie Prikler wrote:
>
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
I accept.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 15:02:03 GMT)
Full text and
rfc822 format available.
Message #272 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 15:49:04 GMT)
Full text and
rfc822 format available.
Message #275 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi,
I disapprove the current state of the GCD; although I sponsor the GCD
and I think renaming from master to main is the right direction.
IMHO, the section Motivations would require a complete revamp and
technical bits need more adjustments.
I hope we will be able to revisit this proposal in the near future
keeping in mind that confrontational discussion is helpless and
consensus requires self-discipline [1].
Cheers,
simon
1: [bug#76407] About consensus, again (was Re: [bug#76407] [GCD] Rename the default branch)
Simon Tournier <zimon.toutoune <at> gmail.com>
Wed, 26 Mar 2025 21:20:36 +0100
id:871pujtugb.fsf <at> gmail.com
https://issues.guix.gnu.org/76407
https://issues.guix.gnu.org/msgid/871pujtugb.fsf <at> gmail.com
https://yhetil.org/guix/871pujtugb.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 23 Apr 2025 15:49:07 GMT)
Full text and
rfc822 format available.
Message #278 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Vagrant, all,
On Mon, 21 Apr 2025 at 11:58, Vagrant Cascadian <vagrant <at> debian.org> wrote:
> The nature of (at least some of) those responses were largely a negation
> that left little room to discuss how to move forward, which left me at
> an impass as to how to even continue the discussion.
>
> Only in retrospect of having encountered this situation did I realize
> there is a fundamental flaw in the GCD process (at least in my
> opinion)...
I think the fundamental flaw comes from the lack of self-discipline.
Somehow, I’ve seen too: « a negation that left little room to discuss
how to move forward ». Building consensus requires a friendly mindset
of the participants. Did we read that?
> in that there is a presumption of moving forward and
> accepting the proposed changes (in some capacity), rather than
> maintaining the status quo. E.g. a person has to propose improvements in
> order to reject the proposal, but there is nowhere in the process that
> handles a fundamental disagreement about the proposal in any form. This
> is contrary to any other genuine consensus process I have worked with.
As I wrote in [1]:
Why do people need to drag in the discussion – in no specific order–:
Black friends, personal history with slavery or dictatorship, opinions
on US imperialism, Gaza massacre, English language, Ukrainian war, a
quote of Frantz Fanon, etc.
Well, from my point of view, the flaw isn’t about “proposing
improvements in order to reject the proposal”, the flaw comes from the
inadequate mindset when approaching the proposal. For instance, one
might disagree with the motivations section and instead of locking the
discussion in some confrontational opinions, instead one might frame:
+ Can we rewrite the Motivation section? Because people have Master
degree and the diploma’s not yet renamed, to my knowledge. Is the
words master really harmful, racist or sexist?
+ About the Motivation, why not narrow the scope and focus on some
aspects: quoting [-] « a) most users leave unchanged the Git default
"main", therefore "master" will become increasingly uncommon and
unexpected, b) the choice of "main" is masterfully similar when
tab-completing or looking through a sorted list of refs, and c) the
move to Codeberg presents a hopefully rare opportunity combine
disruptive changes »
+ The Motivation appears to me poorly written because I’ve never heard
that the term master would be harmful or racist or sexist. Do we have
references for backing this claim?
Etc.
Maybe I’m missing something but, IMHO, building consensus requires to be
very specific on the document itself. Similarly as we do about patches
– we do not discuss in the vacuum of the abstract but based on concrete
code; I do not see why it would be fully different for the GCDs.
> Which... is certainly out of scope for GCD 003 "Rename the default
> branch", but because it is a clear example of a flaw of this GCD
> process, figured it was worth noting.
All that said, I agree that the GCD process needs refinements! Well, we
could name these refinements some “flaws”. :-) IMHO, we need to bound
the scope “how to build consensus” and we need to reinforce the
positions of « Sponsor » who are the guards against the derailment.
WDYT? Although we should discuss that elsewhere. :-)
Cheers,
simon
1: [bug#76407] About consensus, again (was Re: [bug#76407] [GCD] Rename the default branch)
Simon Tournier <zimon.toutoune <at> gmail.com>
Wed, 26 Mar 2025 21:20:36 +0100
id:871pujtugb.fsf <at> gmail.com
https://issues.guix.gnu.org/76407
https://issues.guix.gnu.org/msgid/871pujtugb.fsf <at> gmail.com
https://yhetil.org/guix/871pujtugb.fsf <at> gmail.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 27 Apr 2025 12:04:01 GMT)
Full text and
rfc822 format available.
Message #281 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I support.
On Mon, 21 Apr 2025 at 16:07, Liliana Marie Prikler
<liliana.prikler <at> gmail.com> wrote:
>
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 27 Apr 2025 12:55:01 GMT)
Full text and
rfc822 format available.
Message #284 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Liliana Marie Prikler writes:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
I accept.
Greetings,
Janneke
--
Janneke Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 27 Apr 2025 13:36:01 GMT)
Full text and
rfc822 format available.
Message #287 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I follow what I understood of the opinions of Steve/futurile and Simon
Tournier here.
I approve.
Or actually I don't know but I guess "I approve" fits best? I don't
want this to fail just because of me stating my opinion but I find the
amount of political discussion (on cultural/historical topics of the
angloshpere) not qualified to be held in this arena of contributors to a
free software project. These discussions tend to divide more than they
bring us together.
Let's try to stick to the GNU Kind Communications Guidelines[0] even
more.
[0] https://www.gnu.org/philosophy/kind-communication.en.html
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 27 Apr 2025 15:04:02 GMT)
Full text and
rfc822 format available.
Message #290 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept.
On Mon Apr 21, 2025 at 4:07 PM CEST, Liliana Marie Prikler wrote:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 27 Apr 2025 19:17:02 GMT)
Full text and
rfc822 format available.
Message #293 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon, 2025-04-21 at 16:07 +0200, Liliana Marie Prikler wrote:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
>
I support.
Regards,
Ashvith
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sun, 27 Apr 2025 22:42:01 GMT)
Full text and
rfc822 format available.
Message #296 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Keeping as it is, no support on this GCD from me.
As aikido practitioner and sound engineer I would suprise to call
my teacher main or trunk instead of master or Sensei ;-)
Same in sound - mastering - moving from raw to production state.
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5
… наш разум - превосходная объяснительная машина которая способна найти
смысл почти в чем угодно, истолковать любой феномен, но совершенно не в
состоянии принять мысль о непредсказуемости.
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 28 Apr 2025 09:38:04 GMT)
Full text and
rfc822 format available.
Message #299 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liliana Marie Prikler <liliana.prikler <at> gmail.com> skribis:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
I accept.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 29 Apr 2025 06:46:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Tue, 29 Apr 2025 18:09:05 GMT)
Full text and
rfc822 format available.
Message #305 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Am 21.04.25 um 16:07 schrieb Liliana Marie Prikler:
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
I disapprove.
~Jonathan
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 30 Apr 2025 16:25:04 GMT)
Full text and
rfc822 format available.
Message #308 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
qua 23 abr 2025 às 17:44:39 (1745441079), zimon.toutoune <at> gmail.com enviou:
> Hi Vagrant, all,
>
> On Mon, 21 Apr 2025 at 11:58, Vagrant Cascadian <vagrant <at> debian.org> wrote:
>
> > The nature of (at least some of) those responses were largely a negation
> > that left little room to discuss how to move forward, which left me at
> > an impass as to how to even continue the discussion.
> >
> > Only in retrospect of having encountered this situation did I realize
> > there is a fundamental flaw in the GCD process (at least in my
> > opinion)...
>
> I think the fundamental flaw comes from the lack of self-discipline.
>
> Somehow, I’ve seen too: « a negation that left little room to discuss
> how to move forward ». Building consensus requires a friendly mindset
> of the participants. Did we read that?
>
>
> > in that there is a presumption of moving forward and
> > accepting the proposed changes (in some capacity), rather than
> > maintaining the status quo. E.g. a person has to propose improvements in
> > order to reject the proposal, but there is nowhere in the process that
> > handles a fundamental disagreement about the proposal in any form. This
> > is contrary to any other genuine consensus process I have worked with.
>
> As I wrote in [1]:
>
> Why do people need to drag in the discussion – in no specific order–:
> Black friends, personal history with slavery or dictatorship, opinions
> on US imperialism, Gaza massacre, English language, Ukrainian war, a
> quote of Frantz Fanon, etc.
>
> Well, from my point of view, the flaw isn’t about “proposing
> improvements in order to reject the proposal”, the flaw comes from the
> inadequate mindset when approaching the proposal. For instance, one
> might disagree with the motivations section and instead of locking the
> discussion in some confrontational opinions, instead one might frame:
>
I agree, but this mindset maybe has to be either "fixed" or taken in
account by the process itself.
Blind, arbitrary negation shouldn't be valid, IMU. People need to
understand that if a GCD was worked on and has supporters, there is an
issue to be addressed and that our personal preferences aren't what we
are being asked for, aka, this is not a pure voting system.
So even if the issue described does not affect one ("works here"), that
does not mean the issue is non-existent.
With this in mind, the bias towards approval is not a flaw or something
that was overlooked, but how we should work on it.
It could be that some proposal didn't get support, had an improper
solution, raised other issues which were not addressed, etc. However,
it should not be admissable to disapprove without having "made
constructive comments during the discussion period", as GCD-1 stated.
In sum, disapproval blockades are not valid.
The flaw I see with this is: how do we decide if "constructive
comments" were made? Vote counting becomes convoluted and recursive.
Vote invalidation becomes a sore issue among us.
IMO, right now we give it time to mature, before trying any premature
"optimization" to the process.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Wed, 30 Apr 2025 18:04:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I disapprove.
On 21 April 2025 14:07:14 GMT, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:
>Hi Guix,
>
>as the date for the GCD 003 was set to February 18th, the discussion
>period actually ended on Saturday already. I have incorporated some
>changes on Sunday to realign the proposal with GCD 002 (the Codeberg
>one), but barring any emergency changes there, GCD 003 is now to be
>considered final.
>
>As outlined in GCD 001, please respond to this mail with one of the
>following:
>
>- “I support”, meaning that you support the proposal;
>- “I accept”, meaning that you consent to the implementation of the
> proposal;
>- “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
>To count my own vote, I support the change of the default branch name
>to “main”.
>
>Cheers
>
Divya Ranjan, Mathematics, Philosophy and Libre Software
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Thu, 01 May 2025 00:02:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I support.
I did note thoughtful comments from some people who support the goal of renaming but have concerns about implementation specifics. I hope constructive suggestions to improve implementation will be welcome (though I don't have any myself), but I especially support making this change now, in conjunction with GCD 002.
Since I haven't seen it mentioned elsewhere in this discussion, one factor that's informed my view is that, while "master" indeed has many meanings, its use in Git appears to derive from its use in Bitkeeper, the non-free version control system Git was written to replace, and Bitkeeper explicitly uses "master" as part of a "master"/"slave" model. Some references:
- https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html
- https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/
- https://x.com/xpasky/status/1272958618124595201
- https://lore.kernel.org/git/Pine.LNX.4.58.0506242257450.11175 <at> ppc970.osdl.org/
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Thu, 01 May 2025 09:47:01 GMT)
Full text and
rfc822 format available.
Message #317 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Thu, 01 May 2025 10:11:01 GMT)
Full text and
rfc822 format available.
Message #320 received at 76407 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I support
--
(Life is like a pencil that will surely run out,
but will leave the beautiful writing of life)
(D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
(hkp://keys.openpgp.org))
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Thu, 01 May 2025 22:44:02 GMT)
Full text and
rfc822 format available.
Message #323 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I support.
Thanks for taking this up!
-
Katherine
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Fri, 02 May 2025 11:21:02 GMT)
Full text and
rfc822 format available.
Message #326 received at 76407 <at> debbugs.gnu.org (full text, mbox):
I accept.
Sent on the go. Excuse or enjoy my brevity.
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Mon, 05 May 2025 17:01:01 GMT)
Full text and
rfc822 format available.
Message #329 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi all,
I collated the results from the voting on GCD003.
Voting by members:
- 49 people in the voting pool
- 29 votes in total
- 10 Support, 12 Accept
- 7 Disapprove
- Declarations by observers (people not in teams):
- 5 declarations in total
- 2 Support
- 2 Accept
- 1 Disapprove
Voting result:
- 45% (22 votes) voted to pass the GCD
- 14% voted to disapprove
- 41% abstained by not voting
This GCD is withdrawn as it didn't achieve full consensus:
"The GCD is accepted if (1) at least 25% of all team members–as of the start
of the “Deliberation Period”–send a reply, and (2) no one disapproves. In
other cases, the GCD is withdrawn" (from GCD 001)↩
It may be presented again to the members, at a later time, following further efforts to achieve consensus.
* Please check that I captured **your vote** correctly, the voting tally is here:
https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd003-voting-record.rec
* Voting summary for this GCD is here:
https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd003-voting-summary.md
Hope this is useful!
Steve / Futurile
On 21 Apr, Liliana Marie Prikler wrote:
> Hi Guix,
>
> as the date for the GCD 003 was set to February 18th, the discussion
> period actually ended on Saturday already. I have incorporated some
> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
> one), but barring any emergency changes there, GCD 003 is now to be
> considered final.
>
> As outlined in GCD 001, please respond to this mail with one of the
> following:
>
> - “I support”, meaning that you support the proposal;
> - “I accept”, meaning that you consent to the implementation of the
> proposal;
> - “I disapprove”, meaning that you oppose the implementation of the
> proposal.
>
> To count my own vote, I support the change of the default branch name
> to “main”.
>
> Cheers
>
Information forwarded
to
guix-patches <at> gnu.org:
bug#76407; Package
guix-patches.
(Sat, 10 May 2025 16:10:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 76407 <at> debbugs.gnu.org (full text, mbox):
Hi Guix,
Now that the results are out, I just wanted to thank Liliana for
starting this GCD, and everyone else who contributed to the effort and
supported/accepted.
I would have been too intimidated to broach such a controversial topic;
and even if I could get over that fear, the amount of effort needed to
write a GCD and then spend the next few weeks reading and responding to
everyone's comments was clearly enormous. I believe that this collective
effort couldn't have been motivated by anything other than a genuine
love for the community, and a desire to be as welcoming as possible to
people from diverse backgrounds.
And looking at the proportion of people who supported/accepted, I feel
reassured that I've chosen a good project and community to put my spare
time and energy into. That feeling is rare to come by these days, so
once again - thank you.
Steve George <steve <at> futurile.net> writes:
> Hi all,
>
> I collated the results from the voting on GCD003.
>
> Voting by members:
> - 49 people in the voting pool
> - 29 votes in total
> - 10 Support, 12 Accept
> - 7 Disapprove
>
> - Declarations by observers (people not in teams):
> - 5 declarations in total
> - 2 Support
> - 2 Accept
> - 1 Disapprove
>
> Voting result:
> - 45% (22 votes) voted to pass the GCD
> - 14% voted to disapprove
> - 41% abstained by not voting
>
> This GCD is withdrawn as it didn't achieve full consensus:
>
> "The GCD is accepted if (1) at least 25% of all team members–as of the start
> of the “Deliberation Period”–send a reply, and (2) no one disapproves. In
> other cases, the GCD is withdrawn" (from GCD 001)↩
>
> It may be presented again to the members, at a later time, following further efforts to achieve consensus.
>
> * Please check that I captured **your vote** correctly, the voting tally is here:
>
> https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd003-voting-record.rec
>
> * Voting summary for this GCD is here:
>
> https://codeberg.org/futurile/guix-org/src/branch/master/gcd-voting-summary/gcd003-voting-summary.md
>
> Hope this is useful!
>
> Steve / Futurile
>
>
> On 21 Apr, Liliana Marie Prikler wrote:
>> Hi Guix,
>>
>> as the date for the GCD 003 was set to February 18th, the discussion
>> period actually ended on Saturday already. I have incorporated some
>> changes on Sunday to realign the proposal with GCD 002 (the Codeberg
>> one), but barring any emergency changes there, GCD 003 is now to be
>> considered final.
>>
>> As outlined in GCD 001, please respond to this mail with one of the
>> following:
>>
>> - “I support”, meaning that you support the proposal;
>> - “I accept”, meaning that you consent to the implementation of the
>> proposal;
>> - “I disapprove”, meaning that you oppose the implementation of the
>> proposal.
>>
>> To count my own vote, I support the change of the default branch name
>> to “main”.
>>
>> Cheers
>>
This bug report was last modified 34 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.