renaming the default branch to main

[gireeshpunathil]

rationale: align with several world-wide initiatives on avoiding oppressive metaphors in open source projects

github has already made main as the default for new repositories.

I would like to propose the default branch name change in eclipse projects, starting from PDE. In a similar request[1] to foundation earlier, the response was that they don't want to enforce this change, while supporting it.

I did a search in this repo to see if there are any hard-coded references to branches and found none. There may be few links that need updates, plus some code changes in the CI. I can have a look and see what is the effort required, but thought I would pitch it here as a first step.

Please share your thoughts. I will wait for a week or so before start putting some effort on this.

[1] https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/535

[merks]

I don’t think this should done independent of the other Platform projects. Certainly the Oomph setup is affected, though easily addressed. It’s “just my opinion” that this is political correctness gone astray.

[akurtakov]

I don't mind such change but I don't plan spending any of my time on such a thing either. AKA I expect whoever starts such a change to get it done fully.
The fact that you don't see any reference to master in PDE git is that PDE project itself does zero releng work but relies on Platform project to do it for the project so you should look for references in eclipse.platform.releng.aggregator repo.

[iloveeclipse]

I personally believe software development (or any other serious engineering or science work) shouldn't be involved in politics and doesn't need to change anything to be "political correct".

If we start renaming branches we will continue with "cleaning up" code from SWT.COLOR_BLACK to SWT.COLOR_THAT_CANT_BE_NAMED, rename "disabled" states to "differently abled" states and so on.

We will have people that don't do anything else as checking how "woke" our projects are and if we should be part of the next "woke" wave and what level of wokeness we should achieve next year.

This will never end, it will cost time and it will bring nothing useful, not even to people that were supposed to be "offended" by "not political correct" code, because instead of spending our time on next feature or bug fix we will spend time discussing what next should be made "politically correct" and how. We already waste our time now discussing this proposal, but I hope this will one and only discussion we would need on such topic.

I work since ~15 years in a company where every second employee is coming from a different country. Half of my (small) team and majority of our colleagues in the company are not white. I've never ever heard any of my colleagues complaining about being offended by the "master" branch name or "black" color constants or whatever else that is supposed to be not woke enough today.

So please, let us continue doing what we can do best - developing software that serves everyone independently on color or wokeness level, and leave the politic discussions out of this area.

[laeubi]

Thanks to the recent merges I think this produces much less problems now but in the end I (personally) don't care much how the default branch is named, e.g jetty project uses the name of the current development line (what is 10.0.x):
https://github.com/eclipse/jetty.project/

[HannesWell]

Personally I also don't care about the name of our most important branch and think that we should not feel obligated to fulfill expectations from others not involved in Eclipse (PDE) development.
That being said, if it is important for you and you want to work that out, I'm fine with changing it.
I also agree that it would be good to use the same name for all Eclipse SDK repos (i.e. equinox, platform, pde, jdt), so maybe it would be good to have agreement on all four organizations for that.

[vogella]

+1 for using "main". I also personally do not care about the branch name, but I think it is important to respect that others do as an OS community which embrases diversity and respects all cultures.

[merks]

This is why politics are best left in a parliament. Next thing you know someone is telling me (or implying) that I don’t embrace diversity and don’t respect other cultures nearly as well as they do. And then we have a vote to see who values diversity and respects other cultures. Which is no longer the same topic as voting to change the branch name. Let’s not characterize differences of opinion on the proposed technical change in this particular way. This is more about political correctness which we way may choose to address or may choose not to address without being good or bad. In the end, main is actually a better name for the primary branch and is the default name for it on GitHub. Those are technical arguments rather than political ones.

I have a Masters degree in computing science. I hope that hasn’t become politically incorrect too.

[mickaelistria]

+1 to move to "main". I don't think it would hurt much and it is the current recommendation from GitHub, used across all its documentation such as https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch . Following the standards from the chosen code hosting Platform makes it easier for new people to contribute.

[merks]

In terms of pain, I wonder if anyone has an estimate of the number of person days of work this will be? Is there a pain threshold or shall we do this regardless of that?

I wonder, for example, how many of these will need attention:

I also I wonder how much of this pain will be for people like @akurtakov and the folks from IBM to absorb versus by the people who think it's a good idea.

Note that I also I think it wouldn't be a "bad thing," but I also think folks might think differently if they are stuck holding the flaming bag and must personally spend person days of effort to get the builds working again...

[HannesWell]

Besides the workflows one has to consider also Jenkinsfiles, maybe the verification builds of the repos are not affected, but I'm relatively sure that the I-build (and P oder other releng builds are).
Cannot tell if the .gitmodules of the aggregator has to be adjusted or if git already has main build-in as alternative to master.
In general I suggest to search the whole platform.releng.aggregator repo and also check the builds configured in https://ci.eclipse.org/releng/.

[akurtakov]

From my POV - this could be a go only when all projects part of releng.aggregator decide to the switch at once AND there are people with time and permissions to do the change for all projects at once so I-builds are not broken for extended period. Having to do "if (main|master)" in releng scripts is an adventure I don't plan to spend time on.
Btw, there are a number of other git repos that are not part or releng.aggregator and still under Eclipse TLP and many more for projects in Simrel so I would recommend changes like that to start from places where it would not affect so many places.

[mpalat]

Late to comment, I believe that the time can be spent better at fixing a bug or two rather than going behind this political correctness. That said, I am fine if someone wants to change as long its a seamless transition including script migrations.

[Btw, in some cultures, including from where I am from, "Master" is a very revered and respected word - a Guru who guides you.]

[gireeshpunathil]

thanks everyone for the comments - all valuable, much appreciated!

the intent is not to mix politics with open source, nor to influence the community members to feel in a certain way. the intent is to gauge how strongly / weakly people think about this topic and get a feel of the effort required to make this change.

I see one or two strong sentiments against it but otherwise neutral views on it, with some +1's for the change.

Rationale for me to think this as a good idea are:

• eclipse foundation supports such a change
• the hosting platform, github supports such a change

AKA I expect whoever starts such a change to get it done fully.

fair! I intent to own this fully, if we are implementing this. My ability to complete this could only be limited by lack of knowledge
in the scripts, but not by bandwidth.

In terms of pain, I wonder if anyone has an estimate of the number of person days of work this will be? Is there a pain threshold or shall we do this regardless of that?

@sravanlakkimsetti pointed me to https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/2927e1227b7df9a3d072812aee7861a47e8d6b23/cje-production/streams/repositories_master.txt which, as per him, is an elegant way for switching default branches of component repos - either together, or as and when repos are ready.

In general I suggest to search the whole platform.releng.aggregator repo and also check the builds configured in https://ci.eclipse.org/releng/.

will dig into this, thanks!

[gireeshpunathil]

In general I suggest to search the whole platform.releng.aggregator repo and also check the builds configured in https://ci.eclipse.org/releng/.

we looked into this, and found these:

• the repo cloning of relent-aggregator itself uses hard-coded master - in one place
• the repo cloning of sub modules (pde, platform, jdt etc. uses configurable variables, as mentioned here: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/2927e1227b7df9a3d072812aee7861a47e8d6b23/cje-production/streams/repositories_master.txt

so in short, this is doable with minimum interruption. A rough sketch would be:

• gather consensus from the involved projects on the change
• identify, list and assign owner for the change(s) required
• agree on a date for the switch over
• get a sign off from the foundation for the branch name change (if need be)
• switch over

what do people think?

[merks]

I wonder how many things were not yet found, e.g., from this sampling?

Also how many job configurations will need attention, e.g.,

https://ci.eclipse.org/releng/view/Publish%20to%20Maven/job/CBIaggregator/configure

I think you need to get agreement across Equinox, PDE, JDT, and Platform, recruit the required committers who are both in favor and are willing to do all the work, and then do the work at the start of a release cycle, long before M1.