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

Imre Kaloz kaloz at dune.hu
Mon Feb 27 06:44:38 PST 2023



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.

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

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

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

War is not peace, freedom is not slavery and ignorance is not strenght, 
gentlemen.


Imre


More information about the openwrt-adm mailing list