[GCD] A better name for the default branch

Open

Details

11 participants

Greg Hogan
Ekaitz Zarraga
Leo Famulari
Liliana Marie Prikler
Ludovic Courtès
Christopher Baines
Tobias Geerinckx-Rice
Roman Riabenko
Suhail Singh
Simon Tournier
Tomas Volf

Owner: unassigned

Submitted by: Liliana Marie Prikler

Severity: normal

Debbugs page

Liliana Marie Prikler wrote 2 weeks ago

Recipients:(address . guix-patches@gnu.org)

Message-ID:b900cd17b88123af3ae95f4e7d572e540f86e879.camel@gmail.com

Girls do their best now and are preparing. Please watch warmly until it

is ready.

Liliana Marie Prikler wrote 2 weeks ago

Recipients:(address . 76407@debbugs.gnu.org)

Message-ID:79bad06a6410932dd6c7785256fd589cfaff40f6.camel@gmail.com

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

Toggle diff (195 lines)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

Christopher Baines wrote 2 weeks ago

Recipients:(address . 76407@debbugs.gnu.org)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)

Message-ID:87wmdlhmu4.fsf@cbaines.net

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (45 lines)> +## 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.

Toggle quote (2 lines)

> + 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.

Toggle quote (10 lines)> (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.

Toggle quote (5 lines)

> +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.

Liliana Marie Prikler wrote 2 weeks ago

Recipients:

Message-ID:64c4631029ff07927e3a1cb181be2ea05df8a03a.camel@gmail.com

Hi,

Am Mittwoch, dem 19.02.2025 um 17:21 +0000 schrieb Christopher Baines:

Toggle quote (14 lines)> > +  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.

Toggle quote (16 lines)> 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.

Toggle quote (10 lines)> 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.

Toggle quote (10 lines)> > +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.

Toggle quote (7 lines)> 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.

Toggle quote (18 lines)> ...
> 
> 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

Simon Tournier wrote 2 weeks ago

Recipients:(address . info-guix@gnu.org)

Message-ID:87frk8lea9.fsf@gmail.com

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@gmail.com> wrote:

Toggle quote (6 lines)

> +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. :-)

Toggle quote (2 lines)

> +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

Liliana Marie Prikler wrote 2 weeks ago

Recipients:(address . info-guix@gnu.org)

Message-ID:035d5bb2e0fe23419879b1566789d82eb604d887.camel@gmail.com

Am Donnerstag, dem 20.02.2025 um 18:25 +0100 schrieb Simon Tournier:

Toggle quote (4 lines)

> 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.

Toggle quote (5 lines)> 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.

Toggle quote (6 lines)> > +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

Tobias Geerinckx-Rice wrote 2 weeks ago

[GCD] A better name for the default branch

Recipients:(address . 76407@debbugs.gnu.org)

Message-ID:CA3E79B7-498C-44E6-BD90-85E8531AABF5@tobias.gr

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.

Liliana Marie Prikler wrote 2 weeks ago

[bug#76407] [GCD] Rename the default branch

Recipients:(address . 76407@debbugs.gnu.org)

Message-ID:d2db73de82bb7bb3a6589a4299287d02dc961c14.camel@gmail.com

(Moved discussion to bug number)

Am Donnerstag, dem 20.02.2025 um 23:57 +0100 schrieb Ekaitz Zarraga:

Toggle quote (3 lines)

> 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:

Toggle quote (4 lines)

> 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:

Toggle quote (5 lines)> 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.

Toggle quote (7 lines)> 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.

Toggle quote (3 lines)

> [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.

‾\_(ツ)_/‾

Toggle quote (3 lines)

> 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:

Toggle quote (4 lines)

> 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

Ekaitz Zarraga wrote 2 weeks ago

Recipients:(address . 76407@debbugs.gnu.org)

Message-ID:547c549d-970e-4331-8944-dc7a79698426@elenq.tech

Hi,

On 2025-02-21 09:57, Liliana Marie Prikler wrote:

Toggle quote (14 lines)> (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).

Toggle quote (10 lines)> 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!

Toggle quote (3 lines)

> 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.

Toggle quote (4 lines)

> 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.

Toggle quote (11 lines)>> 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.

Toggle quote (17 lines)>> 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.

Liliana Marie Prikler wrote 2 weeks ago

Recipients:(address . 76407@debbugs.gnu.org)

Message-ID:f78d40758e1838026fb3e796f037e917c26f761f.camel@gmail.com

Am Freitag, dem 21.02.2025 um 11:48 +0100 schrieb Ekaitz Zarraga:

Toggle quote (8 lines)> > 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.

Toggle quote (5 lines)> 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.

Toggle quote (6 lines)> 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.

Toggle quote (2 lines)

> 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.

Toggle quote (1 lines)

> I don't think removing the word is really going to change anything.

Acknowledged.

Toggle quote (2 lines)

> 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?

Toggle quote (3 lines)

> 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".

Toggle quote (3 lines)

> 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.

Toggle quote (1 lines)

> Consider me done here.

Okay.

Cheers

Roman Riabenko wrote 2 weeks ago

Recipients:(address . 76407@debbugs.gnu.org)

Message-ID:20250221153520.20b99610afcdf7bea76e9c6e@riabenko.com

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

Simon Tournier wrote 2 weeks ago

Re: [bug#76407] [GCD] A better name for the default branch

Recipients:(address . info-guix@gnu.org)

Message-ID:875xl3rwn2.fsf@gmail.com

Hi,

On Tue, 18 Feb 2025 at 23:14, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (36 lines)> +## 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

Liliana Marie Prikler wrote 2 weeks ago

Recipients:(name . Denis 'GNUtoo' Carikli)(address . GNUtoo@cyberdimension.org)

Message-ID:b52d4742266f6ace2d9eadf6490ed9a833434244.camel@gmail.com

Am Freitag, dem 21.02.2025 um 19:16 +0100 schrieb Simon Tournier:

Toggle quote (13 lines)> 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.

Toggle quote (7 lines)> 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:

Toggle quote (12 lines)> $ git checkout origin/master -b temporary
> $ git push origin HEAD:main
> $ ssh root@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

Suhail Singh wrote 2 weeks ago

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87msefrp0a.fsf@gmail.com

Simon Tournier <zimon.toutoune@gmail.com> writes:

Toggle quote (3 lines)

> 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

Ludovic Courtès wrote 1 weeks ago

Re: bug#76407: [GCD] A better name for the default branch

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 76407@debbugs.gnu.org)

Message-ID:87o6ys3eom.fsf_-_@gnu.org

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (11 lines)> +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.

Toggle quote (2 lines)

>+## Choice of branch name

I’m not convinced this section is necessary. :-)

Toggle quote (5 lines)

> +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’.

Ludovic Courtès wrote 1 weeks ago

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 76407@debbugs.gnu.org)

Message-ID:87jz9g3em9.fsf_-_@gnu.org

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (2 lines)

> + 1. the `branch` field in `.guix-channel`;

I just realized: there’s no ‘branch’ field in ‘.guix-channel’.

Ludo’.

Liliana Marie Prikler wrote 1 weeks ago

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 76407@debbugs.gnu.org)

Message-ID:8fea9aa02c0dec4574686d636d92fd74997d2c85.camel@gmail.com

Hi Ludo’,

Am Sonntag, dem 23.02.2025 um 15:42 +0100 schrieb Ludovic Courtès:

Toggle quote (24 lines)> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@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:

Toggle quote (15 lines)> 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.

Toggle quote (4 lines)

> 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.

Toggle quote (3 lines)

> > +## Choice of branch name

> I’m not convinced this section is necessary. :-)

How do we achieve consensus on the proposed name itself, then?

Toggle quote (11 lines)> > +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.

Toggle quote (2 lines)

> Also, perhaps clarify that this GCD is valid whether or not GCD 002

> is adopted.

Sure.

Cheers

Ludovic Courtès wrote 1 weeks ago

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 76407@debbugs.gnu.org)

Message-ID:8734g3ro8p.fsf_-_@gnu.org

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (2 lines)

> Actually, the GCD does specify this:

Oh right, sorry.

Toggle quote (12 lines)>> 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.

Toggle quote (5 lines)

>> > +## 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.

Toggle quote (8 lines)

>> 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’.

Leo Famulari wrote 7 days ago

Re: [bug#76407] [GCD] Rename the default branch

Recipients:(name . Roman Riabenko via Guix-patches via)(address . guix-patches@gnu.org)(address . 76407@debbugs.gnu.org)

Message-ID:Z74NQ1wSjVq5YB1I@jasmine.lan

On Fri, Feb 21, 2025 at 03:35:20PM +0200, Roman Riabenko via Guix-patches via wrote:

Toggle quote (6 lines)

> 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.

Greg Hogan wrote 4 days ago

Re: [bug#76407] [GCD] A better name for the default branch

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 76407@debbugs.gnu.org)

Message-ID:CA+3U0ZmnhHSbd=sKRYVhYDJ+c4AJZBos91GKMwSAm7OEQ4Wmkg@mail.gmail.com

On Tue, Feb 18, 2025 at 5:24 PM Liliana Marie Prikler

<liliana.prikler@gmail.com> wrote:

Toggle quote (9 lines)

> 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

Tomas Volf wrote 43 hours ago

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 76407@debbugs.gnu.org)

Message-ID:87ldtnml3k.fsf@wolfsden.cz

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (59 lines)> 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.

Toggle quote (35 lines)> +
> +# 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".

Toggle quote (6 lines)

> +

> +- 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.

Toggle quote (3 lines)

> + 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.

Toggle quote (42 lines)> +
> +- 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?

Toggle quote (10 lines)> 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?

Toggle quote (6 lines)

> +

> +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.

Toggle quote (16 lines)> +
> +## 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"?

Toggle quote (23 lines)> +
> +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".

Toggle quote (7 lines)

> +

> +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.

Toggle quote (11 lines)> +
> +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?

Toggle quote (4 lines)

> 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.

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 76407@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 76407

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags

mumi command -t +confirmed -t +easy

Or, remove the moreinfo tag and set the help tag

mumi command -t -moreinfo -t +help

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date