On Fri, Nov 21, 2014, at 11:00, Donald Stufft wrote: > > > On Nov 21, 2014, at 10:26 AM, Barry Warsaw <ba...@python.org> wrote: > > > > On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote: > > > >> I'd been taking "must be hosted in PSF infrastructure" as a hard > >> requirement, but MAL pointed out earlier this evening that in the age > >> of DVCS's, that requirement may not make sense: if you avoid tightly > >> coupling your automation to a particular DVCS host's infrastructure, > >> then reverting back to self-hosting (if that becomes necessary for > >> some reason) is mostly just a matter of "hg push". > >> > >> If that "must be self-hosted" constraint is removed, then the obvious > >> candidate for Mercurial hosting that supports online editing + pull > >> requests is the PSF's BitBucket account. > > > > For the record, I object to moving *official* PSF resources to proprietary, > > closed-source infrastructure that we do not control or have access to[*]. > > > > As nice and friendly as BitBucket or any other code hosting source is today, > > there are many reasons why I think this is a bad idea for *official* > > branches. We are beholden to their policies and operations, which may not > > align with PSF policies or principles today or in the future. We will not > > be > > able to customize the experience for our own needs. We will not have access > > to the underlying resources should we need them for any purpose. We cannot > > take action ourselves if some problem occurs, e.g. banning an offensive > > user. > > > > You're right that in a world of dvcs, branches can be mirrored anywhere. > > For > > that reason, I have no problem allowing developers to use non-PSF controlled > > resources *unofficially* if it makes their work easier and doesn't conflict > > with their own principles. However, in such cases, I still believe that the > > official, master, blessed repositories remain on PSF controlled > > infrastructure. Surely that too is possible in the world of dvcs, right? > > > > Cheers, > > -Barry > > > > [*] Please note that I am not objecting to our use of lower-level resources > > donated by our generous sponsors. It's a fine line perhaps, but I have no > > problem with a wiki running on a VM hosted on some donated hardware, since > > we > > still have full access to the machine, the OS, and the application software. > > Personally I care less about proprietary and closed-source and care a lot > more > about lock-in. Thus my big problem using Bitbucket for these things is > that if > we ever want to *leave* bitbucket it becomes a lot harder because you > have a > bunch of links and such pointing at bitbucket instead of a python.org > domain. > They do offer a redirect feature but that is dependent on them not taking > that > away in the future. (They also offer a CNAME feature but if you use it > you lose > the ability to use TLS, which is also a non starter for me). Sadly this > also > leaves out my favorite host site of Github :/. Something like Github > Enterprise > or Atlassian stash which are able to be migrated away from are better in > this > regards. > > Ironically we do use a propetiary/closed-source/hosted solution for > https://status.python.org/ but it’s not terribly difficult to migrate > away from > that if we ever wanted to.
The more significant one is probably Fastly. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
