On Sun, 17 Jan 2016 at 17:37 Martin Panter <[email protected]> wrote:
> On 17 January 2016 at 20:48, Brett Cannon <[email protected]> wrote: > > Rationale > > ========= > > . . . > > The overarching goal of this migration is to improve the development > > process to the extent that a core developer can go from external > > contribution submission through all the steps leading to committing > > said contribution all from within a browser on a tablet with WiFi. > > Later on, at least for the main “cpython” repository, you mention > maintaining a linear history, avoiding the automatic Git Hub merge > button, and cherry-picking between branches. I guess you would need > the commit bot to help do all this from a browser. Yes. > If so, mention > that, otherwise this gives the impression that people will Git Hub’s > merge button, which seems to contradict later sections. > Well, you get it for some of the repositories, just not cpython. And I don't entirely agree that the sentence suggests GitHub's built-in browser workflow is the answer, just that *some* in-browser workflow is desired. > > > Document steps to commit a pull request > > ''''''''''''''''''''''''''''''''''''''' > > During the process of choosing a new development workflow, it was > > decided that a linear history is desired. This means that the > > convenient "Merge" button in GitHub pull requests is undesireable, as > > it creates a merge commit along with all of the contributor's > > individual commits (this does not affect the other repositories where > > the desire for a linear history doesn't exist). > > Please clarify whether this linear history is just avoiding the > suprious merge commits that Git Hub can add for each pull request > (merging a pull request with its parent commit), or whether we are > going to stop merging maintainence branches into master, and do > cherry-picks instead. Both is the current plan. > > > Linking a pull request to an issue > > ++++++++++++++++++++++++++++++++++ > > . . . > > (technically it should be a many-to-many association for when a > > single fix solves multiple issues, but this is fairly rare and issues > > can be merged into one using the ``Superceder`` field on the issue > > tracker). > > Spelling: ``Super[s]eder`` > > > Status > > ====== > > . . . > > Repositories whose build steps need updating: > > There is some stray indentation starting here which seems to be > messing with the markup. > > > The fate of hg.python.org > > ------------------------- > > With the code repositories moving over to Git [#git]_, there is no > > technical need to keep hg.python.org [#h.p.o]_ running. > > I presume this means other repositories will be migrated somewhere > else too? For instance, I recently had to update the > “pythontestdotnet” repository. > The assumption is everything will move long-term instead of fragmenting between GitHub and hg.python.org. > > > Tools and commands to move from Mercurial to Git > > ------------------------------------------------ > > A decision needs to be made on exactly what tooling and what commands > > involving those tools will be used to convert a Mercurial repository > > to Git. Currently a suggestion has been made to use > > https://github.com/frej/fast-export. Another suggestion is to use > > https://github.com/felipec/git-remote-hg. Finally, > > http://hg-git.github.io/ has been suggested. > > The migration to Git might be a good opportunity to clean up some of > the older Subversion history. I would like to investigate this. In > particular, rewriting svnmerge commits as proper Git merges, and > restoring the missing history for merges and imports from feature > branches. > > On the other hand, there is already a Git mirror > <https://github.com/python/cpython> which many seem to be already > using. Perhaps it would be good to ensure the commit hashes used there > are kept current. I'm not going to worry about that if the mirror was not done accurately. > Which tool is used to update that mirror? Are there > any deficiencies that would mean we need to use a different tool, > possibly affecting the commit hashes? > I don't know. Eli Bendersky set up that mirror and he has said previously that he just did the bare minimum to get it working and didn't worry too much about correctness, etc. -Brett > > > Separate Python 2 and Python 3 repositories > > ------------------------------------------- > > It was discussed whether separate repositories for Python 2 and > > Python 3 were desired. The thinking was that this would shrink the > > overall repository size which benefits people with slow Internet > > connections or small bandwidth caps. > > > > In the end it was decided that it was easier logistically to simply > > keep all of CPython's history in a single repository. > > Agreed. If people really only want one of the branches, they can set > Git to only download from that branch. And Git supports shallow clones > (only download the most recent commit, or N commits deep), although > some functions may not work in this mode (but apparently things have > improved since I learnt about it). >
_______________________________________________ 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
