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

[Daniel Golle]

Hi Fernando,

I took the freedom to change the top-posting into a more readable
bottom-posting style which is prefered here.

On Sun, Mar 05, 2023 at 11:02:07PM -0300, Fernando Frediani wrote:
> On 05/03/2023 22:13, Yousong Zhou wrote:
> > On Mon, 27 Feb 2023 at 15:06, Felix Fietkau <nbd at nbd.name> wrote:
> > > Hi all,
> > > 
> > > 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'
> > > 
> > > Once this change is well established, we can look into removing
> > > 'master', but we should definitely take our time with that.
> > > 
> > > - Felix
> > Hi,
> > 
> > I vote no on this.
> > 
> > One thing is that like others I see no technical gain in doing this.
> > They are doing a good job but for this cvs branch renaming thing I
> > think time can be better spent on other matters than purging existing
> > non-evil, no-bad-intentioned use of the word "master".
> > 
> > The other thing is that I am worried that this may be going too far
> > and the world getting too sensitive to such added rules to a point
> > that will hurt expression.
> > 
> > Regards,
> >                  yousong
>
> Well put.
> It may seem a little thing now but it may have the potential do open doors
> to other bad things in terms of expression. As mentioned example is
> important, even in the smaller things.

The fact that somebody who has never contributed to this project can
freely and repeatedly express their opinions about an ongoing
decission-making process actually shows the opposite to me.

We are a democracy, all administrative changes require voting.

So, which doors to which bad things are you talking about? And why
would they be opened by a singular change like this?
Really, just name an example please instead of projecting a mystical
bad omen.

> 
> Interesting that fewer that are in favor of it tried to elaborate something
> and unfortunately without any technical merit so far.

Technical merrit is not the point here. A project run by 38 humans and
hundreds of collaborators, thousands of (conscious) users, ... needs
more than just "technical merit". We also changed our logo (to name a
less controversal change with literally no technical merrit), organize
developer meetings and implemented a set of rules governing our
collaboration which states "12. Be nice to each other."[1].

In order to achieve what you call "technical merrit" it is necessary to
be welcoming to all current and future contributors and users, as of
now code still doesn't write or review itself, but it's people having
ideas and putting in all the work. This may, of course, change in the
future, but for now it's still humans writing, modifying, reviewing,
documenting, distributing and using this pile of codes we call OpenWrt,
and at least to me it's clear that the primary purpose of this project
is to serve *humans* rather than us developers being subject to a purely
technocratic rule.

Apart from that, diverting from what has become the default without
a good reason hardly has any "technical merit" either, at least in the
long run. On the other hand, in order to minimize potential negative
impacts the proposal suggests a long transition period before the old
branch name is going to be removed. We were all able to observe several
examples of the exact change being done by other projects in the past
years and they all seem to be doing just fine.

> Instead those against have put several examples of the issues this may
> bring.

An explaination of the goal of this change has already been part of the
proposal, so for those agreeing there might not be much to add to this.

And while I agree that the technical impact of this change has be part
of the picture, there are already project members who stepped up to
volunteer taking care of the necessary changes [2].

The argument that "this time would be better used for X" is not valid
in an Open Source project run by volunteers, as everyone is free to do
with their time what they like to. Not doing Y hence doesn't necessarily
imply that the same time resources would then be available for X.
This is exactly the strength and sometimes also the biggest problem of
an everybody-does-what-they-like-to-do project.

> I wanted to ask those who voted to remain neutral to re-evaluate their view
> and change their vote to No. Neutrality is not the best for a topic like
> this.

I think the general understanding of voting is that once you put your vote
in the virtual ballot box in some way, once it's there you can't fish it
out again to change it because you changed your mind.

Not voting anonymously certainly has an impact on a decission like this,
and in this sense I do share your concern regarding those who simply
abstain from voting. However, being transparent has the major advantage
of nobody needing to put much trust into a voting system and we thereby
we avoid having people screaming "stop the steal" or even more ugly
things.

Imho it is likely that the near future may improve this situation by
establishing in theory already existing cryptographic systems uniting
both advantages. We might then opt to use such systems case-by-case by
yet another vote.


Best regards


Daniel


[1]: https://openwrt.org/rules
[2]: http://lists.openwrt.org/pipermail/openwrt-adm/2023-March/002367.html