[core-workflow] Migration PEP started

Brett Cannon brett at python.org
Mon Jan 11 15:57:35 EST 2016


On Mon, 11 Jan 2016 at 12:42 francismb <francismb at email.de> 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
> core-workflow at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160111/855e88a3/attachment.html>


More information about the core-workflow mailing list