Re: DEP-14: renaming master to main?
On Mon, Jun 22, 2020 at 06:45:50PM +0100, Simon McVittie wrote: > > On Mon, 2020-06-22 at 17:50 +0200, Michael Biebl wrote: > > > there has been a lot of talk recently about how master is a loaded term > > > that should be avoided. > > > If I read the news correctly, github and others are going to change the > > > default master branch to main. > > > I don't really have any strong opinion on that matter myself. > > Is there consensus that, in projects that want to rename away from > 'master', 'main' is the best replacement name? (I've also seen 'default' > or 'devel' suggested, for example.) >... How well have replacement terms been vetted to ensure they do not have the same problem in other parts of the world than the stated reason for the renaming? There are people on the internet claiming "main/other" would be terminology for discrimination against the Ainu people. I cannot judge whether this specific claim is true or not, only wondering whether anyone has done a global vetting on replacement names. > smcv >... cu Adrian
Re: DEP-14: renaming master to main?
Hi Otto, Thank you for providing an alternative voice in this discourse. Otto Kekäläinen writes: > Hello! > > Just my 2 cents: I hope Debian would not rush to any changes here. > Lets just stay neutral for now. The subject seems very US-centric and > there is a risk that it is creating division among people forcing them > to take sides on issues that previously were not political at all. > Agreed, although I do think that master/slave binary thinking is harmful. That said, I'm primarily concerned about the repercussions of unilaterally vilifying all words that match the string "master", eg: mastery, mastered, mastering (the learning process), masters degree, master of foo, martial arts master, master trades person, master craftsmanship (proof of mastery and excellence), ftpmaster[s], etc. These things are not negative and have nothing to do with slavery. Trades people, academics, martial artists, and everyone else who strive for excellence should not be made to feel ashamed of their titles. I suspect this sense of "master" comes from magister (latin, one who has achieved excellence such that they are qualified to teach) and I think "magis" might also have connotations of wisdom rather than domination or power, but "magistrate" also has that substring...Does anyone here know latin/etymology, and could you explain this please? Adam, thank you for introducing the medieval thought, that is what jogged my memory. The English sense of "headmaster" is also useful for explaining this, because the construction appears to be "head" (director/manager/authority) + "master" (teacher). eg: if "master" meant "director/person-in-power" then there would be no need for the "head" prefix. While it could be argued that high achievers are slaves to excellence, that's a metaphorical comparison, and is a bit cynical and/or for purposes ofhumour...and isn't it an even worse application of master/slave binary thinking to say such a thing? At any rate, a concrete example: While "ftpmasters" have "master" in the title, and they can reject packages and/or ask for additional work, there is §2.1.1 in the Debian Constitution: Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. So the ftpmasters are not masters of slaves, because they cannot compel anyone to do work. Thus, we have a precedent in Debian for how master/slave thinking does not apply to all circumstances. > Here is some background of what philosophical meaning the term had in git: > > https://public-inbox.org/git/20200618152300.cw7teo2jmxyfsl2l@chatter.i7.local/ >> This is actually an important philosophical point with software like >> git. There is no such thing as master.kernel.org for the very specific >> reason that we position kernel.org to be merely a convenient place where >> to get a *copy* of Linux. The "master copy" of the mainline tree exists >> only in one place -- on Linus's computer. > Exactly, thank you for the reference, and--in my mind at least--Linus "masters" a release by merging many "tracks" (git branches) into the "master" track (master branch), similarly to typical digital audio workstation workflow, or the "master" (also known as "mix") bus on an analogue console, then tags it (like pressing a "gold master record"). > Let's wait and see if upstream Git changes the default, then others > will naturally follow next time they run 'git init'. > > So far upstream git has removed a couple of mentions of slavs: > - https://github.com/git/git/commit/f33b5bddaf7ac1535c6c37fde168597e252872b3 > - https://github.com/git/git/commit/08dc26061f3ff9ee79e6cfda88f0c825b8730e54 > > Python had a similar discussion in 2018 and they concluded that the > term 'master' does not have any political undertone when used in git > master, postmaster or hostmaster: https://bugs.python.org/issue34605 Oops, should have read that issue first...it some overlap with what I wrote. Regards, Nicholas signature.asc Description: PGP signature
Re: DEP-14: renaming master to main?
Hi, Le 22/06/2020 à 05:50, Michael Biebl a écrit : […] > If we deem that [whatever] is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? FWIW, I’d welcome such change, (almost) whatever name end up being used instead of “master”. If we agree on such change and decide to address it on our repositories before the rest of the community, and then later, another name become the de facto standard, I don’t care that we end up having to change another way around in the following years. One or two changes in a few years laps of time is what we’ve been used to in the last ten years anyway (be it internal Alioth changes, or the recent salsa move). For once, I’d be happy to address such change for “human” reasons, rather than being forced to for technical ones. Regards David
Re: DEP-14: renaming master to main?
Hello! Just my 2 cents: I hope Debian would not rush to any changes here. Lets just stay neutral for now. The subject seems very US-centric and there is a risk that it is creating division among people forcing them to take sides on issues that previously were not political at all. Here is some background of what philosophical meaning the term had in git: https://public-inbox.org/git/20200618152300.cw7teo2jmxyfsl2l@chatter.i7.local/ > This is actually an important philosophical point with software like > git. There is no such thing as master.kernel.org for the very specific > reason that we position kernel.org to be merely a convenient place where > to get a *copy* of Linux. The "master copy" of the mainline tree exists > only in one place -- on Linus's computer. Let's wait and see if upstream Git changes the default, then others will naturally follow next time they run 'git init'. So far upstream git has removed a couple of mentions of slavs: - https://github.com/git/git/commit/f33b5bddaf7ac1535c6c37fde168597e252872b3 - https://github.com/git/git/commit/08dc26061f3ff9ee79e6cfda88f0c825b8730e54 Python had a similar discussion in 2018 and they concluded that the term 'master' does not have any political undertone when used in git master, postmaster or hostmaster: https://bugs.python.org/issue34605
Re: DEP-14: renaming master to main?
On 24-06-2020 12:56, Gunnar Wolf wrote: > Colin Watson dijo [Mon, Jun 22, 2020 at 10:13:31PM +0100]: >> I think my ranked preferences are: >> >> 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a >> nice allusion to this list) >> 2. trunk (historical familiarity from other VCSes) >> 3. main or maybe mainline (some tab-completion similarity to master, >> though the confusion with components in a Debian context is >> unfortunate) > > I never really understood the word "trunk" when I used older > VCSes... Because, as a non-native English speaker, I always understood > "trunk" as the part of the car you store stuff in. > > The "right" meaning is quite obvious, and it makes much more sense > when expressed together with "branches": What in Spanish we call > "tronco" (should be a giveaway! How come I never understood it > before?), the core part of a tree. Thing is, in English I always used > the word "stem" for it. > > I'm only sending this message to help explain the term to other people > who might find it odd. So, a DVCS is a tree, and you can follow the > _trunk_ to find its "core" or "main" development direction. > > There are many _branches_ splitting, first from the trunk itself, then > from other branches. > > So, trunk makes quite a bit of sense for me in that light. Just a though inspired by Gunnar email. I am not a native English speaker and I should admit that I always felt cold about the discomfort people reported in the use of loaded terms such as slave/master. I am a physicist and those terms are used a lot in the literature and they always felt "normal". So normal that it is common practice to use these English words in technical communication also in my native language. Recently I started translating them in my head into my native language every time I read them. I felt immediately different and I felt ashamed I contributed to support their used in many articles I wrote. These English words are used so often in a metaphoric sense that my brain registers the neologism as the main meaning rather than the other way around. I feel think kind of normalization of the terms worrisome. I am trying to understand if a similar mechanism exists for the perception of gender pronouns (another issue I feel I am not completely understanding, despite wrongly identifying my gender from my name is a fairly common occurrence) for persons whose native language has gender for all pronouns (usually assigned in what may seem a random way) and thus the fact that there is a gender associated with personal pronouns is somehow diluted I haven't come to a conclusion yet. Cheers, Dan
Re: DEP-14: renaming master to main?
Colin Watson dijo [Mon, Jun 22, 2020 at 10:13:31PM +0100]: > I think my ranked preferences are: > > 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a > nice allusion to this list) > 2. trunk (historical familiarity from other VCSes) > 3. main or maybe mainline (some tab-completion similarity to master, > though the confusion with components in a Debian context is > unfortunate) I never really understood the word "trunk" when I used older VCSes... Because, as a non-native English speaker, I always understood "trunk" as the part of the car you store stuff in. The "right" meaning is quite obvious, and it makes much more sense when expressed together with "branches": What in Spanish we call "tronco" (should be a giveaway! How come I never understood it before?), the core part of a tree. Thing is, in English I always used the word "stem" for it. I'm only sending this message to help explain the term to other people who might find it odd. So, a DVCS is a tree, and you can follow the _trunk_ to find its "core" or "main" development direction. There are many _branches_ splitting, first from the trunk itself, then from other branches. So, trunk makes quite a bit of sense for me in that light.
Re: DEP-14: renaming master to main?
On Tue, Jun 23, 2020 at 11:40:47AM +0100, Colin Watson wrote: > Not really. The master/slave metaphor prompted me to think about this > sort of thing more and give it a higher priority, that's all. I still > think we'd be better off using a different name. So use a different metaphor. For git, we can use the medieval system of master/terminator (terminator = "apprentice" but the latter sounds human only). A terminator does what he's ordered to, but may graduate to journeyman then master, especially when moving to another workshop (repo). Upsides: * we keep the name, ingrained in millions of scripts/etc * clones get a more glorious name (but there's nothing that enforces it) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: DEP-14: renaming master to main?
On Tue, Jun 23, 2020 at 08:14:37AM +0200, Christian Kastner wrote: > On 2020-06-23 02:12, Colin Watson wrote: > > On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote: > >> On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote: > >>> [1] > >>> https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html > >> > >> You might be interested in [2] as well. Speculation is often wrong. > >> > >> [2]: > >> https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html > > > > Good to know, but I think it doesn't really change my conclusions. > > Could you expand on that? I interpreted your conclusions to be > necessitated by what was written in the first mail. Not really. The master/slave metaphor prompted me to think about this sort of thing more and give it a higher priority, that's all. I still think we'd be better off using a different name. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DEP-14: renaming master to main?
On 2020-06-23 08:14, Christian Kastner wrote: > If it's not, then it's just about utility, and then honestly I don't see > enough of it to merit the head-ache of breaking with the conventional name. Having thought about that part some more, I realized I need to retract it. I might not see the utility of it, but seeing as a lot of thought already went into DEP-14, I can only conclude that a sufficient number of other people see it.
Re: DEP-14: renaming master to main?
On 2020-06-23 02:12, Colin Watson wrote: > On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote: >> On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote: >>> [1] >>> https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html >> >> You might be interested in [2] as well. Speculation is often wrong. >> >> [2]: >> https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html > > Good to know, but I think it doesn't really change my conclusions. Could you expand on that? I interpreted your conclusions to be necessitated by what was written in the first mail. If it's not, then it's just about utility, and then honestly I don't see enough of it to merit the head-ache of breaking with the conventional name.
Re: DEP-14: renaming master to main?
On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote: > On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote: > > For a while I'd thought that it was relatively harmless in comparison > > to > > full-blown uses of master/slave metaphors, but I saw some analysis of > > the history recently that pointed out that git got it from BitKeeper > > which did in fact use a master/slave metaphor [1]. > > > [1] > > https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html > > You might be interested in [2] as well. Speculation is often wrong. > > [2]: > https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html Good to know, but I think it doesn't really change my conclusions. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DEP-14: renaming master to main?
Am Mo., 22. Juni 2020 um 23:30 Uhr schrieb Colin Watson : > > On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote: > > there has been a lot of talk recently about how master is a loaded term > > that should be avoided. > > If I read the news correctly, github and others are going to change the > > default master branch to main. > > I don't really have any strong opinion on that matter myself. > > For a while I'd thought that it was relatively harmless in comparison to > full-blown uses of master/slave metaphors, but I saw some analysis of > the history recently that pointed out that git got it from BitKeeper > which did in fact use a master/slave metaphor [1]. > [...] This is actually untrue and has been clarified by Bastien: https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html Even though the "Git master" originates from "master recording" / "master copy" though, I don't think it's worth the fight or complaining a lot about people wanting to change it, as long as there is another metaphor which is equally valid. I think "main" would kind of fit that original intent best, but let's see what the other stakeholders in the Git community decide (the guy who originally came up with the name suggesting a change is certainly influential!). Personally, I do wonder how the "Git master branch" separates from other stuff with "master" (but no "slave") in it, like "mastering a subject" or "Master of science", but I am also not a native speaker, and lots of people seem to be bothered by it, so changing the name does make sense to me (definitely for new projects where there is no risk of breaking something). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: DEP-14: renaming master to main?
On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote: > For a while I'd thought that it was relatively harmless in comparison > to > full-blown uses of master/slave metaphors, but I saw some analysis of > the history recently that pointed out that git got it from BitKeeper > which did in fact use a master/slave metaphor [1]. > [1] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html You might be interested in [2] as well. Speculation is often wrong. [2]: https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html Ansgar
Re: DEP-14: renaming master to main?
On Mon, Jun 22, 2020 at 10:13:31PM +0100, Colin Watson wrote:
> On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote:
> > there has been a lot of talk recently about how master is a loaded term
> > that should be avoided.
> > If I read the news correctly, github and others are going to change the
> > default master branch to main.
> > I don't really have any strong opinion on that matter myself.
>
> For a while I'd thought that it was relatively harmless in comparison to
> full-blown uses of master/slave metaphors, but I saw some analysis of
> the history recently that pointed out that git got it from BitKeeper
> which did in fact use a master/slave metaphor [1].
>
Calling that email an analysis is rather charitable. It is really just
a bunch of nonsense. In fact, it is rather impossible to say with any
degree of certainty what thought (or lack thereof) went into the choice
by Linus adopt the "master" terminology in Git. That makes the whole
discussion rather pointless, or a distraction. Rather than focusing on
"why", would it not be better to just take the opportunity to make an
improvement?
> > That said, what I care about is consistency and predictability across
> > the archive.
> > If we deem that "main" is a better term, should we change the defaults
> > in salsa/gitlab and maybe update DEP-14?
>
> I think my ranked preferences are:
>
> 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a
> nice allusion to this list)
> 2. trunk (historical familiarity from other VCSes)
> 3. main or maybe mainline (some tab-completion similarity to master,
> though the confusion with components in a Debian context is
> unfortunate)
> 4. further discussion / something else / etc.
> 5. stick with master
>
If we are going to make a change then the motivation should be technical
in nature, which should inform the choice and which should cause us to
ensure that any change made is an improvement. Regardless of whether
the term "master" is harmless, causing imagined harm, or causing real
harm, at present there is a rather fortunate opportunity to make an
objective usability improvement in what has perhaps become the most
common and universal tool used by software developres the world over.
Thinking about the way in which Git is used (regardless of chosen
workflow, paradigm, etc.) names likes "main" and "default" are just as
unclear as "master" in terms of conveying a purpose for the branch.
Sort of like the old dialogs ("Save & exit? Yes/No" and "Discard & exit?
yes/No") that essentially forced you to think about the meaning of each
available choice. Nowadays we use button labels like "Save/Discard"
instead of "Yes/No" because it just works better by reducing the
cognitive burden on the user and making it more likely that the result
of the action will match the user's expectation.
The prevalence of tools that previously used "trunk" makes that not a
terrible choice. However, there are clearly better options.
That said, being that Git as a tool is designed and targeted for
software developers to work on source code (an activity universally
called "development"), renaming "master" to "devel" would mark a
usability improvement. In particular, for any given project I don't
have to figure out, "is 'master' the branch where active development
takes place or does development take place elsewhere and 'master' is the
branch from which releases are made?" A branch called "devel" would
unquestionably be where active development is taking place.
Other branch names could then be chosen based on the needs of the
project, like "test", "stage", & "prod", or "rc" & "release", or
whatever.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: DEP-14: renaming master to main?
On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote: > there has been a lot of talk recently about how master is a loaded term > that should be avoided. > If I read the news correctly, github and others are going to change the > default master branch to main. > I don't really have any strong opinion on that matter myself. For a while I'd thought that it was relatively harmless in comparison to full-blown uses of master/slave metaphors, but I saw some analysis of the history recently that pointed out that git got it from BitKeeper which did in fact use a master/slave metaphor [1]. > That said, what I care about is consistency and predictability across > the archive. > If we deem that "main" is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? I think my ranked preferences are: 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a nice allusion to this list) 2. trunk (historical familiarity from other VCSes) 3. main or maybe mainline (some tab-completion similarity to master, though the confusion with components in a Debian context is unfortunate) 4. further discussion / something else / etc. 5. stick with master I'm not that fussed about the relative ranking of 1-3, though, and I agree it would be good to end up with something consistent if we can. [1] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DEP-14: renaming master to main?
Den mån 22 juni 2020 kl 20:03 skrev Simon McVittie : > > > On Mon, 2020-06-22 at 17:50 +0200, Michael Biebl wrote: > > > there has been a lot of talk recently about how master is a loaded term > > > that should be avoided. > > > If I read the news correctly, github and others are going to change the > > > default master branch to main. > > > I don't really have any strong opinion on that matter myself. > > Is there consensus that, in projects that want to rename away from > 'master', 'main' is the best replacement name? (I've also seen 'default' > or 'devel' suggested, for example.) Archive-wide changes in Debian tend > to take a very long time, so we might want to wait until there's one > choice that has obviously "won", to be consistent with other git users. My half cent, as a bystander with regards to Debian, but a git user elsewhere, is that "main" corresponds nicely with "mainline" which is a common term in software projects. "default" seems a bit dubious IMHO - it sort of seems to suggest "commit here if you don't know any better". Which is maybe true for a personal repo, but not a good suggestion if you are a new contributor to some project, and new to git, since you should create a topic branch. "devel" or "develop" I've seen in some workflows that aims to keep "master" super-stable, by performing integration of changes first to "devel" and then after system testing and some sort of release, "master" is updated in one go with a merge from "devel". /Oskar
Re: DEP-14: renaming master to main?
> On Mon, 2020-06-22 at 17:50 +0200, Michael Biebl wrote: > > there has been a lot of talk recently about how master is a loaded term > > that should be avoided. > > If I read the news correctly, github and others are going to change the > > default master branch to main. > > I don't really have any strong opinion on that matter myself. Is there consensus that, in projects that want to rename away from 'master', 'main' is the best replacement name? (I've also seen 'default' or 'devel' suggested, for example.) Archive-wide changes in Debian tend to take a very long time, so we might want to wait until there's one choice that has obviously "won", to be consistent with other git users. 'main' does already mean something in both Debian and Ubuntu (the main archive area), although if 'main' becomes as widespread in git branch names as the current use of 'master', it might be less surprising to use it anyway. 'devel' also has a meaning in Ubuntu (it's an informal alias[1] for whatever is the newest under-development suite, currently 20.10 'groovy') although it doesn't have that meaning in Debian. ubuntu/devel would be consistent with that and DEP-14. On Mon, 22 Jun 2020 at 18:24:54 +0200, Markus Frosch wrote: > I would prefer debian/unstable as a default suggestion, since it reflects > the repository logic of Debian itself. On Mon, 22 Jun 2020 at 18:43:43 +0200, Gard Spreemann wrote: > Since DEP-14 already accepts naming according to release codenames, > perhaps recommending debian/sid for the main development branch would be > a better course of action? Whether you can use debian/unstable (or equivalently debian/sid) as HEAD depends on your workflow. Specifically, imagine your upstream releases a version that is not ready for testing/unstable, like a Linux -rc version or a GNOME x.odd.z version; and you want to put that version in experimental for people to try. What do you do? One workflow is that you would use the HEAD branch for the experimental version, and split off a separate (perhaps short-lived) branch for the older version in unstable if you need to update it. If this is what you do, then you should use a suite-neutral name for your "latest versions" branch, and neither debian/unstable nor debian/sid is suitable - you need either the debian/master from current DEP-14, or a direct replacement. Most GNOME-team packages do this, because some members of the GNOME team strongly prefer this way round. Another workflow is that you would use the HEAD branch for the *unstable* version, and split off a separate (perhaps short-lived) branch for the *newer* version in *experimental*. If this is what you do, then you can use either a suite-neutral name or debian/unstable (or debian/sid) for the version in unstable, and debian/experimental for the version in experimental. This is what I do for dbus. In this workflow, you are correct to say that a direct replacement for debian/master is not necessary. smcv [1] a symlink, but not mentioned in the Release file - this is the same as rc-buggy -> experimental in Debian
Re: DEP-14: renaming master to main?
Michael Biebl writes: > there has been a lot of talk recently about how master is a loaded term > that should be avoided. > If I read the news correctly, github and others are going to change the > default master branch to main. > I don't really have any strong opinion on that matter myself. > > That said, what I care about is consistency and predictability across > the archive. > If we deem that "main" is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? Since DEP-14 already accepts naming according to release codenames, perhaps recommending debian/sid for the main development branch would be a better course of action? Best, Gard
Re: DEP-14: renaming master to main?
On Mon, 2020-06-22 at 17:50 +0200, Michael Biebl wrote: > there has been a lot of talk recently about how master is a loaded term > that should be avoided. > If I read the news correctly, github and others are going to change the > default master branch to main. > I don't really have any strong opinion on that matter myself. > > That said, what I care about is consistency and predictability across > the archive. > If we deem that "main" is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? We certainly could, just for the sake of picking a neutral option. I would prefer debian/unstable as a default suggestion, since it reflects the repository logic of Debian itself. AFAIK there is not yet an option for configuring the default branch in GitLab. When you create a repo locally, GitLab will deem the first branch pushed to be default. Regards Markus -- lazyfro...@debian.org https://lazyfrosch.de
DEP-14: renaming master to main?
Hi, there has been a lot of talk recently about how master is a loaded term that should be avoided. If I read the news correctly, github and others are going to change the default master branch to main. I don't really have any strong opinion on that matter myself. That said, what I care about is consistency and predictability across the archive. If we deem that "main" is a better term, should we change the defaults in salsa/gitlab and maybe update DEP-14? Regards, Michael signature.asc Description: OpenPGP digital signature
