On Mon, 11 Jan 2016 at 12:42 francismb <francismb@email.de> wrote:

On 01/10/2016 03:54 AM, Brett Cannon wrote:
> I'm developing it at
> https://github.com/brettcannon/github-transition-pep/blob/master/pep-NNNN.rst .
> I'm not posting it here as I'm still actively writing it. The only reason
> I'm mentioning it now is because the migration plan has been very roughly
> outlined, so if it  looks like I'm missing something, please let me know.
my two cents (on changeset 92afd4a90f56a8caa2cf0620cedc2c20b8c0e0d0):

While hg.python.org [1] hosts many repositories, there are onlyfive key
repositories that must move:
Decide what should happen to the rest of the repos? (or ist under
the fait of hg.python.org?)

Part of what happens to hg.python.org since they are all personal repos.
Why is devinabox grey marked, means that something special?

Just that the repo name matches the project name.

Define commands to migrate from Mercurial to Git
Converting a Mercurial repository to Git

Aren't both equivalent (or doesn't you need to define the command
to be able to convert the repos?). Or you mean write the script
for the migration and then do the migration?

Accidental duplication.

Document steps to commit a pull request
Handling Misc/NEWS
Handling Misc/ACKS
Couldn't be also part of "Requirements for Code-Only Repositories"?
Why only Code-Only repos hasn't Misc/NEWS or Miscs/ACKS? (yes, well
those are code only per your definition? :-) )

Only the cpython repos have an ACKS and NEWS file and all the other repos can just use the merge button in a GitHub PR (that will be pointed out in the cpython section).

Linking pull requests to issues
Notify the issue if the pull request is committed
There can be more than a pull request to one issue (e.g. an
alternative patch), should "the not committed ones" be automatically
rejected (?)

No, because sometimes an issue involves multiple patches legitimately.

Splitting out parts of the documentation into their own repositories
If those are split, shouldn't exist a mechanism to deploy
a consistent release (docs <-> code)?

People are talking about things like the HOWTOs, tutorial, etc. And they can be made to be subrepos of the cpython repo if we want.

Bot to deploy a release (tagging, building, ...) or at least the
steps need to be documented (or will exist a potentially releaseable

There's too much specifically for a bot to do, plus the release process is documented in another PEP.

Decide and document how the python services map into python.org
(e.g. git.python.org)

Added a section on creating git.python.org.



core-workflow mailing list
This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct