Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Switching Git branches from master to main

It’s definitely good that someone brought it up 🙂

I agree that it is very unlikely to hurt so maybe we should just go for it.

Cheers,
Abraham 

Sent from my iPhone

On 5 Dec 2022, at 11:18, Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> wrote:


Thanks for the follow up.

As I mentioned, I don't see any harm with it. If it helps inclusion or people to feel better, I don't see why we would not do it. 

I appreciate "master" is quite often used in computer science or IT and sometimes as you mention, it's hard to find alternatives to describe a problem or an architecture design. Once again, I'm ok with it, and I'm equally ok to keep going the way we are. I brought the discussion up. Job done ;-)





On Fri, Dec 2, 2022 at 9:10 PM Abraham Marin-Perez <amarinperez@xxxxxxxxxxxxxxxx> wrote:
Hi,

I recently joined the Spec committee and I must confess that I am a bit reluctant to make my first contribution to this mailing list in such a delicate topic, but I’m going to try my best. Also, I appreciate this question was posted a few weeks ago but I’m still catching up with email and, since it didn’t seem to get a response, I thought I might break the ice.

I’d like to start by saying that I’m not against the change from master to main, if this is something that can help people feel more included, then let’s go for it. My own GitHub repos were changed. However, my personal feeling is that this matter didn’t really settle within the wider community and it merits a bit more discussion. A lot of what I’m going to say next has probably already been said elsewhere, but I feel I cannot present my position without laying it all out so I apologise for the extension and potential redundancy.

The word “master” has several different meanings, and not all of them are related to the dichotomy master/slave. One use of this word has been the idea of “owner” or “controller”, for instance in build tools like Jenkins we find a “master” node that controls overall activity and “slave” nodes that are awaiting orders from the “master” node; when there are jobs to be run, the “master” node picks a “slave” node and instructs that node to do the job. This terminology directly feeds from the idea of master/slave and is definitely problematic; these names should change.

Another meaning of the word “master” is “original”, “principal”, or “main". For instance, in the process of manufacturing DVDs, CDs, Blu-ray discs, or even vinyl discs, you have one “master” copy from which all the other copies are created. Now, here you don’t have one entity “bossing” the other ones, you have simply one from which the other ones are created. There isn’t a master/slave dichotomy, it’s more a master/replica relationship. This meaning is probably closer to what happens in a repository: you have the master (i.e. main) copy of a codebase, and then replicas of it for various purposes. If we understood “master” in this way, then perhaps its use wouldn’t be so problematic and a change might not be needed.

Yet another meaning of the word “master” is “advanced knowledge, skill, or talent”. For instance, a seminal piece of art is a masterpiece, and an advanced educational course is a Master’s degree. Here we don’t find the problematic relationship with the slave trade either, and it’s probably another meaning where the word is safe to use. This use is probably less related to what we do in a repository, although one could still find a relationship: the master (or main) branch is the canonical one, the one we all trust, while the other ones are potential changes to the canonical branch that we may or may not accept.

Of course, we could say that the word “master” has become so problematic than it doesn’t really matter in which way we are using it: it’s just a tainted word and it needs to be avoided. If this is how people feel, then we should definitely change from master to main.

And, finally, there is another potential argument to say that none of the above matters, because perhaps the wider community has moved on and it’s too late now to swim against the tide: if we remain the only ones not to make the move from master to main this could reflect badly on us. If we think that this is the case, then also we should make the transition.

But the big elephant in the room is perhaps the fact that the master/slave issue hasn’t historically affected all sectors of society in the same way: there were victims, and there were perpetrators. Everybody is welcome to a debate but, IMHO, the opinion of victims (or their descendants) should carry more weight. This is why, personally, I’d like to hear the opinion of impacted people: would a change in terminology help? If so, then to me that’s the definite sign that a change must indeed be made. If not, then perhaps we should focus our efforts elsewhere.

Hope that helps,
Abraham



On 10 Nov 2022, at 10:55, Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> wrote:

Hi,

I've pulled the latest changes in the specification repository because I have a long running task in my todo list to update Messaging and Security pages. For some reason, it struck me that we are still using master in most of our projects.

I've seen many Open Source projects and communities moving from Git master to Git main for the naming. Github has done the switch a while back and this is now the default for new projects.

I personally think we should, too, for the same reason of promoting inclusivity (https://sfconservancy.org/news/2020/jun/23/gitbranchname/).

Bringing it here to collect thoughts and see if we should plan the changes for us and all specifications in Jakarta (MicroProfile too if not done but this is out of the scope here).

Thanks
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

Back to the top