[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