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

Mon Mar 6 02:15:11 PST 2023

Hi Fernando,

I've once again converted top-postin to bottom-posting, in a way that
I felt will make it easier for readers to understand what is being
talked about.

On Mon, Mar 06, 2023 at 01:03:44AM -0300, Fernando Frediani wrote:
> Hi Daniel
> 
> 
> On 06/03/2023 00:47, Daniel Golle wrote:
> > 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.

> I have took note of your points and will not respond to any of them since
> you choose to start your message trying to measure with your ruler that
> amount of contribution someone gave to the project, in a tentative maybe to
> make it less relevant to the discussion.

I'm sorry if you understood it in this way. I did not mean to discredit
you. The point I wanted to make here is that we are *not* discussing
this behind closed doors and that everybody can not just read what is
being said, but even people most of us have ever heard off can
participate in the debate. Hence I have a difficult time following
arguments claiming that free speech is being limited in any way.

> Let the discussion continue, those who decide to do their job and whatever
> the decision may be all will follow.
> 
> Be nice to each other !
> > 
> > > 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
> > 
> 
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm