On Mon, 11 Jan 2016 at 12:42 francismb
Hi,
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.rs... .
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 branch?).
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. -Brett
Regards, francis
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct