In article <20141121102647.46e97...@limelight.wooz.org>, 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? I agree with Barry's arguments. Another issue, so to speak, is what to do about issues? Bitbucket, Github, et al provide integrated issue trackers - like we do with the current hg.python.org / bugs.python.org integration. If we were to move the official repos to another site, then what about the official site for issues? If we don't move the issues as well, some of the power and advantages of using the third-party site are lost (no one-click moving between issues and source, etc.). If we do move the issues, then we have a new source of confusion as to where people should open bugs (adding to the bug janitors workload), the problem of issue history (older and open issues in one tracker, newer ones in another), and a different workflow for tracking the issues. bugs.python.org already supports a kind of pull request with the "Remote hg repo" field. If the goal is to make it easier for newcomers to contribute via pull requests, perhaps that field could be better documented (like adding specific instructions to a readme on the Bitbucket read-only mirror) or improved, if necessary. https://docs.python.org/devguide/triaging.html#mercurial-repository -- Ned Deily, n...@acm.org _______________________________________________ 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
