Absolutely +1. Clearly the most pragmatic choice.
On Thursday, 7 August 2014 13:43:45 UTC+1, Josh Smeaton wrote: > > I don't think "vendor lock in" is a good enough reason to avoid it. If > GitHub were to go away, the move to a new code platform would be the > greater problem. Also, nothing will be "lost". The old usernames will still > be there, they just won't be properly linked to your github username. I > don't think that's really a major concern either. > > > Finally, to be honest, I’d rather adjust Django’s tools to enthusiastic > > beginners than grumpy freedom extremists who refuse to use GitHub. > > +1 > > On Thursday, 7 August 2014 16:49:00 UTC+10, Christian Schmitt wrote: >> >> I'm a little bit concerned about that. >> First I'm using a different user on Trac than on Github, so everything I >> wrote so far will getting lost (not that bad problem for me), but I think >> there are many users who are in the same situation. >> >> The next thing is vendor lock-in. What will happen if Github don't have >> enough money? Then all usernames would need to migrate back or to another >> OAuth provider, then everything could be lost a second time. >> Or that Github gets bad / mad. >> >> Currently we already live in a world were everything gets connected. And >> that is really awful. One must consider that Github is definitely a target >> for intelligence agencies. And I don't mean the NSA only. >> Maybe I'm a little bit too paranoid but at the current state of the >> internet we shouldn't try to connect everything, just it is easier to login. >> >> >> >> >> 2014-08-07 8:46 GMT+02:00 Aymeric Augustin <[email protected] >> >: >> >>> To be clear, I have a working implementation of GitHub OAuth that I can >>> activate as soon as we reach a consensus. >>> >>> >>> >>> On 7 août 2014, at 02:43, Ben Finney <[email protected]> wrote: >>> >>> > −1. I am happy to agree to Django's BTS terms of use, not GitHub's. >>> > Please don't make the former depend on the latter. >>> >>> I didn’t know our Trac installation had terms of use. So, are you >>> volunteering to jump in and delete spam as it comes in? Or do you >>> have an alternative proposal? >>> >>> >>> >>> On 7 août 2014, at 02:47, Shai Berger <[email protected]> wrote: >>> >>> > Today, it is possible to contribute to the Django project without a >>> > Github account. I would like this to remain the case. >>> >>> This is possible but in a limited capacity. To be honest, I think that >>> ship sailed when we moved to GitHub. We would have also moved >>> issues there if GitHub’s tools were usable. >>> >>> >>> >>> On 7 août 2014, at 02:58, Andre Terra <[email protected]> wrote: >>> >>> > Most importantly, how would Django as a project benefit from this >>> > choice other than reducing minimal spam? >>> >>> Did you just ask “how would Django as a project benefit from having >>> core devs work on committing patches rather than fighting spam”? >>> >>> If you don’t already have a djangoproject.com account, you’re likely to >>> give up on reporting a small bug just because it’s too complicated to >>> log in. Considering our target demographic, GitHub OAuth would >>> eliminate this problem. >>> >>> Also, if you’re trying to report a bug anonymously, you’re likely to be >>> unable to pass the CAPTCHA, and also be unable to report it, because >>> you’re still getting blocked by the CAPTCHA. See complaints: >>> https://code.djangoproject.com/search?q=captcha&noquickjump=1&ticket=on >>> >>> Finally, to be honest, I’d rather adjust Django’s tools to enthusiastic >>> beginners than grumpy freedom extremists who refuse to use GitHub. >>> >>> > A better solution would be to strengthen what it means to have an >>> identity >>> > on djangoproject.com. Rather than restricting user actions to Trac, we >>> > could motivate users to create something like a Django profile which >>> would >>> > be used for Trac (among may other uses) >>> >>> We already have that: https://www.djangoproject.com/~aaugustin/ >>> >>> > and could later be linked to any OAuth providers, including but not >>> limited >>> > to GitHub. >>> >>> We don’t have that. >>> >>> > TL;DR Identity on djangoproject.com, Authentication linked to >>> multiple OAuth, >>> > Authorization in Trac. >>> >>> Are you volunteering to do this work, and if so, when will it be done? >>> >>> > I hope that idea makes sense. I may be just babbling nonsense. >>> >>> >>> I’m sorry, but ideas don’t matter nearly as much as execution here. >>> We just need working tools — nothing fancy. >>> >>> >>> >>> On 7 août 2014, at 02:59, Josh Smeaton <[email protected]> wrote: >>> >>> > is it easy enough to support github oauth + the current trac auth >>> concurrently? >>> > If a user chooses to go through the harder path, that's fine. >>> >>> It may be doable to provide two authentications endpoints, like /login >>> and >>> /login/github. Trac just looks at REMOTE_USER and creates a session that >>> lasts until you logout. I’ll look into it. >>> >>> That solves the “GitHub is evil, I don’t want to touch their bytes with >>> a six >>> foot pole” problem, but only half of the username mismatch problem. You >>> can keep using your djangoproject.com username is you wish, but if >>> someone else owns the same username on GitHub, they can impersonate >>> you e.g. https://github.com/shai / https://www.djangoproject.com/~shai/. >>> >>> That said, if you aren’t logged in, you can type anything you want in >>> Trac's >>> “Your username or email” field. It provides identification, not >>> authentication. >>> This has never been a problem in the past. So I don’t think we’ll run >>> into >>> too much trouble with usernames in general. >>> >>> The only part where Trac usernames are used for authentication is access >>> control, which only applies to people who have special permissions. >>> >>> -- >>> Aymeric. >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/53B41C22-FAB6-49A9-9284-5BCCFC4D28BD%40polytechnique.org >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/12cf6ba6-68a0-4ae1-91c2-9da0cdd3b1ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
