Hi Michael, Je mer, 2019-05-01 je 21:52 +1000, Michael Gratton skribis:
On Wed, May 1, 2019 at 12:48, Richard Hughes <hughsient gmail com> wrote:On Wed, 1 May 2019 at 12:38, Michael Gratton <mike vee net> wrote:They have also been successful in getting other projects to use more inclusive language. For example, MongoDB initially refused to stop using the term "master", but then relented after Python did so.That's misrepresenting it *AGAIN*. Both stopped using master along with slave. The main developer branch is still called master in both projects.I'm not sure how you can argue that someone *not* having done something demonstrates it would have no effect?
I think the problem is that, when prompted why we should make this change, you said that we need only look at Python to see why this change is good. But Python did NOT change the name of their master branch, so it's a disingenuous example. I agree that Python's change was good, and I agree that we should adapt to be more inclusive (and we already do a lot!), but I do not see that the name of the master branch stops us from being more inclusive, EVEN IF I personally think that the name "master" is a bit sucky. Do you have testimonies from people who are (potentially) affected by the name of the master branch? I think that that would be a lot more interesting than hypothetics. You keep asserting that the term master—in isolation—is problematic. But you don't actually back that up with anything other than guilt by association, or the feminist argument against gendered terminology. Maybe I'm asking something very difficult (it's not easy to find affected would-have-been contributors), but I find that this would be immensely valuable for this conversation. Maybe you can contact organisations that fight for the rights of former slaves, and the descendants of slaves? And while I agree with the argument against gendered terminology, and think that the word "master" is the suckiest possible word they could have chosen among many options (trunk, main, mainline, etc), I do not feel strongly enough about this to make such a huge, breaking change. We would be breaking with all available documentation, and would (ironically, perhaps) make it HARDER to get started on contributing because we break with defaults. That's why, if this change is very important, I would much much much rather see this happen upstream. Have you contacted upstream Git?
Since there are no technical barriers and since we have a way of seamlessly handling backwards compatibility, why don't we try this and see how well it works?
Do we really? I'm not entirely convinced that this change is seamless. I say this as a GNOME translator for Esperanto, which is the only locale that does not have a territory (e.g., "eo.UTF-8" instead of "eo_ZZ.UTF-8"). It breaks so much that I keep having to patch over such a tiny, stupid difference. And when I approach upstream about this, they say that it is fully supported in glibc, and that downstream should just deal with it. It's maybe not the perfect analogy, but breaking with defaults can be really, really painful. With kindness, Carmen
Attachment:
signature.asc
Description: This is a digitally signed message part