I've definitely in favour of fixing all of the problematic word usage - after all, we eliminated master/slave from the database documentation years ago, we've just been a bit negligent at fixing the others.
Agreed with Adam, though, about seeing what GitHub builds - they announced they're working on something, and if it allows seamless migration, that'd be great. That said, if they take more than a month or two, we should just change it and get it over with. Andrew On Tue, Jun 16, 2020, at 12:59 PM, Adam Johnson wrote: > On the branch rename, right now I'd rather wait to see what GitHub builds > that could help with this. It might allow aliasing master->main so that > existing PR's don't need targeting, local clones don't need updating, etc. It > also seems Git will make a change and it might be worth waiting to see what > that looks like. > > On the blacklist/whitelist rename, I've reopened the ticket and Tim Graham > already reopened the PR. > > On Tue, 16 Jun 2020 at 19:46, Tom Carrick <t...@carrick.eu> wrote: >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZ9P4ONPbGegRwTnuebyMT5PjbEjHN-38rG18K20u6gTQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > Adam > > -- > 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/CAMyDDM3mu_bUh3%2Bc-uJv8Nq6vWLMPrk%2B9Yno8-%3Dq60-xQGrxow%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAMyDDM3mu_bUh3%2Bc-uJv8Nq6vWLMPrk%2B9Yno8-%3Dq60-xQGrxow%40mail.gmail.com?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/0f5b457f-f19f-4cdd-87d9-871fda30b68d%40www.fastmail.com.
