On Mon, 11 Jan 2016 at 12:42 francismb <[email protected]> wrote: > 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.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 > 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 > [email protected] > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct >
_______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
