[Python-Dev] Move selected documentation repos to PSF BitBucket account?

Brett Cannon brett at python.org
Fri Nov 21 14:29:11 CET 2014


On Fri Nov 21 2014 at 7:37:13 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> For those that aren't aware, PEP 474 is a PEP I wrote a while back
> suggesting we set up a "forge.python.org" service that provides easier
> management of Mercurial repos that don't have the complex branching
> requirements of the main CPython repo. Think repos like the PEPs repo,
> or the developer guide repo.
>
> The primary objective of the PEP is to enable an online editing + pull
> request style workflow for these pure documentation projects that only
> have a single active branch.
>
> 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".
>

I don't view self-hosting as ever being a requirement. We hosted ourselves
mainly to fully control commit messages (we do like to be very explicit
after all =). Because we didn't want to pollute our message log with
people's own messages which didn't follow our commit log guidelines or were
of high enough caliber, we chose to fully control the hosting so as to not
give people a false hope that we would accept a pull request.


>
> 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.
>

There's also CodePlex and (ironically) SourceForge for open-source hg
hosting.


>
> There'd still be some work in such a change to make sure we didn't
> break automated regeneration of associated site elements, but that's
> still a lot simpler than adding an entirely new piece of
> infrastructure.
>
> If folks are amenable to that variant of the idea, I'll undefer PEP
> 474 and revise it accordingly, with the developer guide and the PEP's
> repo as the initially proposed candidates for transfer.
>

I think showing us how to ignore PR comments and only show those from
merges and direct commits on a branch (e.g. blame, reading log output,
etc.) would help, i.e. how to work with Mercurial so I only see commit
messages from core developers or ones they directly could edit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141121/841fa53e/attachment.html>


More information about the Python-Dev mailing list