[VOTE] Switch 'master' to 'main' branch for repositories

[Imre Kaloz]

On Mon, 27 Feb 2023, Daniel Golle wrote:

> On Mon, Feb 27, 2023 at 03:44:38PM +0100, Imre Kaloz wrote:
>>
>>
>> On Mon, 27 Feb 2023, Daniel Golle wrote:
>>
>>> On Mon, Feb 27, 2023 at 01:12:20PM +0100, Rafał Miłecki wrote:
>>>> On 27.02.2023 10:17, Rafał Miłecki wrote:
>>>>> On 27.02.2023 08:05, Felix Fietkau wrote:
>>>>>> More and more projects are switching their repositories to use the 'main' branch instead of the 'master' branch. This also includes many Linux upstream trees as well. Some trees are even removing their 'master' branches already.
>>>>>>>> I think this is becoming more and more mainstream and
>>>> expected of projects, so we should do the same.
>>>>>>>> I would like to propose the following:
>>>>>>>> 1. Change the git server side to automatically update the
>>>> 'master' branch, whenever an update is pushed to 'main'.
>>>>>> It's important to have a long transition period in order to avoid breaking downstream users' workflows.
>>>>>>>> 2. Change the git server side to refuse a push to 'master'
>>>> if 'main' exists. This avoid accidental branch divergence
>>>>>>>> 3. Developers simply change their git configs to always push
>>>> to 'main'
>>>>>> Nack
>>>>>> I don't see why we should complicite stuff just to match some
>>>> projects.
>>>>> Sounds nonsense.
>>>>>>> > Once this change is well established, we can look into
>>>> removing 'master', but we should definitely take our time with that.
>>>>>> Well, this actually sounds stupid.
>>>>> You want to add "main" branch to match some people expectations.
>>>>> You want to delete "master" branch breaking some people expectations.
>>>>
>>>> I believe I missed some important discussion on this due to my absence
>>>> on the last meeting.
>>>>
>>>> Could someone explain me what exactly is going on here?
>>>>
>>>> Sure we can rename "master" to "main" today.
>>>> Then maybe "main" to "primary" tomorrow.
>>>> Why not "primary" to "major" later.
>>>>
>>>> Is that worth it just because projects <foo>, <bar>, <qux> decided to
>>>> go with "main"? Is there some technical problem?
>>>
>>> Surely this is just about habbits, and yes, as we are humans, they
>>> are likely to change as centuries pass by.
>>>
>>> As of today, most of our upstream projects (hostap, linux, ...) are
>>> using 'main' as the default branch name for ongoing development.
>>> So if <foo>, <bar> and <qux> are basically almost everybody, why
>>> should we do anything different unless there is a good reason?
>>
>> A lot of people had this mindset in the last century - we are lucky there
>> were people against those ongoing "developments". It's really troubling to
>> see even the descendants in Europe so quickly forgetting history.
>
> Can you explain where you draw the link to censorship here? In other
> replies you sent today, even "dehumanizing others"? Who is being
> dehumanized? And why? Do they have a choice?

By now we all know your slippery slope is never fallacy but a strategy.

> I've read 1984, btw, I had to read it in school. Nice book, better than
> most other things they made us read in school.

It was meant to be a warning, not a manual.

>>> If you create a new project in git today, it will use 'main' as the
>>> main branch by default unless it is told to do otherwise.
>>> Git documentation and guidelines reflect that. Github also does that.
>>> And basically all major tech companies decided to do the same.
>>
>> As far as I know, OpenWrt will be 20 in less than 8 months and not a single
>> soul prevented anyone from using whatever branch name for the newly created
>> components in their own repositories.
>
> Both, linux and hostap, predate OpenWrt. Just saying...

Non sequitor.

>>> So while this change certainly has a political component, it is also
>>> just about matching what everybody else is doing by now. And as with
>>> every default value, there should be a sound argument if you'd like to
>>> divert from that default.
>>
>> This has _only_ the political component, but given you are pushing for this
>> for over 2 years it's refreshing that you are willing to admit that.
>
> From my point of view this is **of course** political. I never denied
> that. You may read up our past discussion, but I quite clearly remember
> (and will look it up, if needed) that I expressed my believe that all
> of this *is* political. Most things I do outside of a toilet are political
> in some way or another. And what's bad about politics? Isn't politics
> just a social function?
> Now, some time later, it may have evolved from a progressive or
> 'snowflake' opinion (depends on your view) to a mainstream and
> compliancy thing.
>
> Keeping everything the same for the sake of keeping it the same is also
> very political, at least if you ask me.

I hope after sending this mail calling it a "compliancy thing" you 
have realized you just shown the true colors of your motives, right?

>>> And honestly we've adapted to more technically challenging and
>>> inconvenient changes (let's say: UEFI, IPv6, ...) in the past,
>>> eventhough there have always also been good arguments against them.
>>> UEFI introduces more complexity than needed, IPv6 ruins your privacy if
>>> you don't take good care. Using 'main' instead of 'master' seems to
>>> trigger lengthy debates.
>>>
>>
>> Those might have been inconvenient, but they had no political motives - and
>> especially they did not try to use newspeak to convince the masses to adopt
>> them. They have been created to solve actual technical limitations and
>> issues while this on the other hand has nothing to do with technology and
>> creates limitations.
>
> IPv6 has been introduced after years of RFC and a very poltical process
> lead to its (partial) adoption: working groups, committees, assemblies,
> ambitious speaches, interest groups, manipulation, corruption for and
> against, ... all of it.
>
> UEFI and secure boot also create limitations by definition, that's why
> people came up with the GPLv3, among other things. And it's been a very
> political fight resulting in us still being able to choose the codes we
> run on some but not all computing hardware.
>
> Seems to depend on whether I'm wearing my polticical glasses or not, but
> if I do, quite everything has a political component.

The usual game of words, but I let you have fun one last time before I
stop replying to your half-truths. There are quite some differences 
between a process or organization being political versus a political 
ideology. The proposed change has zero technical merits to advance the 
goals of this project.


Imre