On moving away from the master branch, it would be a lot of effort (not just in the repo, but docs, Trac, etc.), but I think it's worth doing regardless. I think there is often some reluctance to do something time-consuming because it takes someone's time away from technical issues. I don't think this is necessarily true. Although we could always use more contributors, this is something that's fairly easy for a newcomer (talking specifically about the changes to docs). There's no requirement to know about ORM internals, async implementation, or anything else. Just some time and thoroughness. I'd be happy to put the time in, and I'm sure there are many other (potential) contributors willing to do so, and It doesn't stop the more technical people working on the issues they want to. I think all that is really required - if/when a decision is made, would be to review the PR, change the branch in Github, migrate Trac. Of course I don't know what else is affected, so maybe I'm being optimistic here.
This does have some precedent also, there was a move from trunk to master when moving from SVN to git. That was part of a bigger change to a new VCS system, admittedly, but I think this is also important. With that said, I do think we should wait and see what naming convention git / GitHub / GitLab etc. decide on. It seems like "main" has the most traction, which seems fine to me, and, as has been mentioned, is less of a misnomer anyway. One argument I've seen against both of these that I don't think has been addressed in this thread is that this will set off a trend of renaming more things, mastery, masters degrees, and so on. In case it needs to be addressed, this strikes me as a slippery slope fallacy. Just because we do one thing, doesn't mean we must necessarily do another vaguely related thing. I don't see (or foresee) any interest in this, and I think as is always the case in these things, we go where the consensus is. For example, trolls aside, I don't see any criticism of e.g. Frontend Masters. Just some further thoughts. Tom On Tue, 16 Jun 2020 at 15:44, Roger Gammans <rgamm...@gammascience.co.uk> wrote: > Funny you should say that but the git developers mailing list in is awash > with patches and shouting about just this at the moment. > > It looks likely the patches will go in too - so that's not much of an > arguement against. > > > On Tue, 2020-06-16 at 16:35 +0300, אורי wrote: > > I think *master* is the default branch name in any Git repository. It's > not about Django and even not GitHub. Do you want to change the default > branch name in Git? > אורי > u...@speedy.net > > > On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick <t...@carrick.eu> wrote: > > This ticket was closed wontfix > <https://code.djangoproject.com/ticket/31670#ticket> as requiring a > discussion here. > > David Smith mentioned this Tox issue > <https://github.com/tox-dev/tox/issues/1491> stating it had been closed, > but to me it seems like it hasn't been closed (maybe there's something I > can't see) and apparently a PR would be accepted to add aliases at the > least (this is more recent than the comment on the Django ticket). > > My impetus to bring this up mostly comes from reading this ZDNet article > <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/> > - it seems like Google have already made moves in this direction and GitHub > is also planning to. Usually Django is somewhere near the front for these > types of changes. > > I'm leaning towards renaming the master branch and wherever else we use > that terminology, but I'm less sure about black/whitelist, though right now > it seems more positive than negative. Most arguments against use some kind > of etymological argument, but I don't think debates about historical terms > are as interesting as how they affect people in the here and now. > > I don't think there is an easy answer here, and I open this can of worms > somewhat reluctantly. I do think Luke is correct that we should be > concerned with our credibility if we wrongly change this, but I'm also > worried about our credibility if we don't. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40gammascience.co.uk > <https://groups.google.com/d/msgid/django-developers/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40gammascience.co.uk?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZ9P4ONPbGegRwTnuebyMT5PjbEjHN-38rG18K20u6gTQ%40mail.gmail.com.
