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

[Fernando Frediani]

Hi Daniel

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

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