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

Thu Mar 2 12:14:57 PST 2023

Hi Fernando,

On Thu, Mar 02, 2023 at 03:52:13PM -0300, Fernando Frediani wrote:
> Hello
> 
> Some comments inline
> 
> On 02/03/2023 14:01, Paul Spooren wrote:
> > - SFC, which we joined some time ago actively “supports and encourages projects to switch to branch names that are meaningful and inclusive”. Since they are somewhat our link society (money, trademark, more) I’d trust them on that matter, too.
> > 
> > https://sfconservancy.org/news/2020/jun/23/gitbranchname/
> 
> Support and encourages doesn't mean they enforce it. While this is not
> mandatory in order to keep the link with them that is just a detail that may
> or may not be followed and if not then nothing else will change.
> It could well be that some people suggesting it there were convinced by some
> political correctness line that wishes to spread this way of thinking.

Absolutely. And I don't think there would be anything wrong about that.
Political correctness is generally a good thing. Of course, sometimes
there can be a conflict of interests and I've seen this going wrong as
well. Using purely academic language codes, for example, can exclude
people from less priviledged classes who don't have access or time or
money to be part of the academic world. And yes, sometimes we may need to
weight different *isms against each others, case-by-case. If communicated
well and calmly nobody should get hurt, and intollerance should only be
practised against intollerant behaviors.

That being said, it's clear to me that nobody should ever be punished or
excluded for not following political correct language conventions,
unless it is done on purpose to hurt others (and that will have to be
proven).

> 
> > - Other project we rely on switched away from master branch, too. They seem to be doing just fine so I’m not concerned that the OpenWrt project would handle it differently. Implementation examples (incomplete list):
> > 
> >    - LLVM abandoned master branch entirely https://github.com/llvm/llvm-project
> >    - Git mirrors main/master https://github.com/git/git/branches
> 
> I don't see much reasons why they would not keep doing fine, but also don't
> see any (actually zero) benefit from this change.
> The fact that there are other projects doing it doesn't mean much unless
> there is a technical merit and in this case I see none. It is not because
> other projects choose to do that many others should feel the pushed to do.
> Each has to analyze the merits according to their own reality and of the
> people who make it happen, not simply according due to what other projects
> have chosen.

That's true and as I would love to see a more diverse demography of
users and contributors, I'm all for changes which could facilitate that.
And yes, language use and the perceived openness towards contributors of
all backgrounds is a factor which will influence the attractiveness of
the project.

Consider for example students who can choose to do their thesis to be
based on OpenWrt or rather work with other projects where they perceive to
be in a more friendly community. Many of todays developers, including
myself, started with OpenWrt in this way; and yes, my decission was
certainly also based on political factors (such as the project not being
directly associated with any industry players, and many developers being
active in community mesh projects giving away Internet access for free
also to those who otherwise couldn't afford it).

Of course, you may now argue that by following this line of political
correctness (no negative connotation intended) we may also drive away
some people who are in a personal war against all traces of "wokeness",
smelling a global conspiracy against them personally behind every attempt
to give access to the same privileges they already got also to others.
However, I don't think that not dealing with this kind of people would
be a big loss.

> 
> > I fully understand that people don’t want to do extra work within open source projects which they don’t find themselves necessary. However, when voting here I’d like people to consider that other people are fine putting in the “work” for using more inclusive language.
> 
> I don't think that issue is restricted only to the work that has to be done
> as a result of it, but consider also that some people don't wish to move
> this forward in order to not comply this political view and because in the
> view of some that it may bring zero benefits.
> Example is important and when you let a change happen that doesn't have
> enough merit to happen other doors may be opened for other similar and
> unnecessary changes.

The doors for all changes are already open. We are a democratically
organized project. Administrative changes such as the one suggested
here are decided by a simple majority vote.
See https://openwrt.org/rules

Changes in code are decided by review and up to now we haven't seen
any edit wars -- despite the different political and ideological views
present among the project members.

When it comes to high-level language changes (let's say: in LuCI) they
could even exists peacefully next to each other. We could have several
verions of English translations and it's a matter of adding some
translation files, e.g.
English (old-school)
English (woke)
English (pirates)
English (simple language)
...

So as a user you may decide to install the language package you like the
most, or even make your own.
I'm not saying that I'll now sit down and implement this, but it's meant
more as an example that most of such changes **won't even need voting**
and can already be done, indenpendenly of how we call our main
development branch.

> 
> > If Felix doesn’t have the time to work on that, I’m happy to jump in and do the step(s) in case this vote passes.
> > 
> > tl;dr I see valid political reasons reasons to switch and trivial technical issues.
> 
> I agree that some political aspects may be able drive the direction of a
> project, but only when they can cause some harm or lack of something to it.
> In this case I see zero harm caused by not changing what is proposed and
> mainly that technical merits should always prevail and in this case or at
> least be strong, as mentioned I am unable to see any.
> 
> To finish with I don't believe it is lack of empathy but I fail to see cases
> in the recent years or even decades where developers feel bad with using the
> "master" word in day to day development context.

Just because you don't see them it doesn't mean they don't exist.
I do see them. And this discussion is probably also not contributing
to make them feel welcome in our project.

Best regards

Daniel

> 
> Best regards
> 
> > 
> > Sunshine,
> > Paul
> > 
> > 
> > > On 27. Feb 2023, at 08:05, 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
> > > 
> > > _______________________________________________
> > > openwrt-adm mailing list
> > > openwrt-adm at lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-adm
> > 
> > _______________________________________________
> > openwrt-adm mailing list
> > openwrt-adm at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-adm
> 
> 
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm