<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 5 Jan 2016 at 10:11 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jan 5, 2016, at 1:03 PM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 4 Jan 2016 at 21:54 Ezio Melotti <<a href="mailto:ezio.melotti@gmail.com" target="_blank">ezio.melotti@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Tue, Jan 5, 2016 at 2:42 AM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>> So consider this the starting discussion of the PEP that will be the<br>><span> </span><a href="http://hg.python.org/" rel="noreferrer" target="_blank">hg.python.org</a><span> </span>-> GitHub transition PEP that I will be in charge of. Once we<br>> have general agreement on the steps necessary I will start the actual PEP<br>> and check it in, but I figure there's no point in have a skeleton PEP if we<br>> can't agree on the skeleton. :) While I list steps influencing all the<br>> repos, I want to focus on the ones stopping any repo from moving over for<br>> now, expanding what we worry about to the cpython repo as we knock blockers<br>> down until we move everything over and start adding GitHub perks.<br>><br>> The way I see it, we have 4 repos to move: devinabox, benchmarks, peps,<br>> devguide, and cpython.<br><br>On top of this, there is also the test repo<br>(<a href="https://hg.python.org/test" rel="noreferrer" target="_blank">https://hg.python.org/test</a>) and all the tracker repos<br>(<a href="https://hg.python.org/tracker/" rel="noreferrer" target="_blank">https://hg.python.org/tracker/</a>).<br>I think it would be useful to port the former since it will provide a<br>place for devs to try things out and experiment (a new test repo could<br>also be created though).<br>It would be nice to port the tracker repos too and be consistent with<br>the others, but it's not a priority.  When we switched to HG they kept<br>being on SVN until I ported them, so I guess the same thing can be<br>done (unless R. David or Martin prefer to stick to HG).<br><br>> I also think that's essentially the order we should<br>> migrate them over. Some things will need to be universally handled before we<br>> transition a single repo, while other things are only a blocker for some of<br>> the repos.<br>><br>> Universal blockers<br>> ==============<br>> There are four blockers that must be resolved before we even consider moving<br>> a repo over. They can be solved in parallel, but they all need to have a<br>> selected solution before we can move even the devinabox repo.<br>><br>> First, we need to decide how we are going to handle adding all the core devs<br>> to GitHub. Are we simply going to add all of them to the python<br>> organization, or do we want something like a specific python-dev gteamroup<br>> that gets added to all of the relevant repos? Basically I'm not sure how<br>> picky we want to be about the people who already have organization access on<br>> GitHub about them implicitly getting access to the cpython repo at the end<br>> of the day (and the same goes for any of the other repos in the python<br>> organization). For tracking names, I figure we will create a file in the<br>> devguide where people can check in their GitHub usernames and I can manually<br>> add people as people add themselves to the file.<br>><br><br>I think the current list of core-devs should be converted to a group<br>and given access to the same repos they have access to now (i.e.<br>cpython/devguide/peps and possibly others).  Then additional<br>repo-specific groups can be created in case we want to let specific<br>contributors work on peps or the devguide.<br></blockquote><div><br></div><div>This seems to be the general consensus, so we will create a python-dev team under the python org and add the core devs there.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Just to expand on this more, GitHub has recently updated their permission model more to also allow “outside contributors” to be added to a single repository without adding them to a group (Not sure if this would be useful for us or not).</div></div></div></blockquote><div><br></div><div>It will be on the ancillary repos like peps and devguide where we may want to be more liberal in letting people commit (e.g., maybe we want to add all PEP authors as outside contributors so that they can maintain their own PEP).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>I imagine the python-dev team would have “Write Access” (See <a href="https://help.github.com/articles/repository-permission-levels-for-an-organization/" target="_blank">https://help.github.com/articles/repository-permission-levels-for-an-organization/</a>) unless we think it needs admin access.</div></div></div></blockquote><div><br></div><div>I think write access is perfect for the vast majority of people. The question becomes if we want to add anyone specifically with admin access to help manage repo stuff like web hooks, or if we just bug someone on the infrastructure team to set it for us.</div><div><br></div><div>I do think that some of us -- probably those of us on hgaccounts -- should be team owners.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> Second, CLA enforcement. As of right now people go to<br>><span> </span><a href="https://www.python.org/psf/contrib/contrib-form/" rel="noreferrer" target="_blank">https://www.python.org/psf/contrib/contrib-form/</a>, fill in the form, and then<br>> Ewa gets an email where she manually flips a flag in Roundup. If we want to<br>> use a web hook to verify someone has signed a CLA then we need to decide<br>> where the ground truth for CLAs are. Do we want to keep using Roundup to<br>> manage CLA agreements and thus add a GitHub field in<span> </span><a href="http://bugs.python.org/" rel="noreferrer" target="_blank">bugs.python.org</a><span> </span>for<br>> people's profile and a web hook or bot that will signal if someone has the<br>> flag flipped on<span> </span><a href="http://bugs.python.org/" rel="noreferrer" target="_blank">bugs.python.org</a>?<br><br>This can be done.  We can add a "GitHub" username field to Roundup<br>users so that we can link the two.<br></blockquote><div><br></div><div>OK, so it sounds like we will stick with our current CLA signing flow and write our own CLA bot that will query Roundup as to whether someone has signed the CLA or not and then throw up a banner signalling if someone has (not) signed and an appropriate link to the CLA. That will require some Roundup work and the creation of the bot.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>We can set a commit status that will show red if the user hasn’t signed the CLA (just like if Travis tests failed or so). No need to use a banner or anything.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><br></div><div>I should also mention, any bot creations we do should abstract out the code review tool so that when we change providers again in the future it will be more straight-forward to just update some select APIs rather than rewrite every bot we create.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br>> Or is there some prepackaged service that<br>> we can use that will keep track of this which would cause us to not use<br>> Roundup (which might be easier, but depending on the service require<br>> everyone to re-sign)? There's also the issue of supporting people who want<br>> to submit code by uploading a patch to<span> </span><a href="http://bugs.python.org/" rel="noreferrer" target="_blank">bugs.python.org</a><span> </span>but not use GitHub.<br>> Either way I don't want to have to ask everyone who submits a PR what their<br>><span> </span><a href="http://bugs.python.org/" rel="noreferrer" target="_blank">bugs.python.org</a><span> </span>username is and then go check that manually.<br>><br><br>This also brings up another problem.<br>Since the discussion about an issue happens on b.p.o and the PRs are<br>submitted on GitHub, this means that:<br>1) users with only a GitHub account have to create a b.p.o account if<br>they want to comment on the issue (exclusing review comments);<br>2) users with only a b.p.o account have to create a GitHub account if<br>they want to review a PR;<br>3) users with both can comment on b.p.o and review on GitHub, but they<br>might need to login twice.<br><br>It would be better if users didn't need to create and use two separate accounts.<br></blockquote><div><br></div><div>If we can add GitHub as a login/creation option for b.p.o accounts then that solves that. But I'm willing to bet a majority of people will already have a GitHub account and we have always required the b.p.o account so #1 is the going to be the common case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> Third, how do we want to do the repo conversions? We need to choose the<br>> tool(s) and command(s) that we want to use. There was mention of wanting a<br>> mapping from hg commit ID to git commit ID. If we have that we could have a<br>> static<span> </span><a href="http://bugs.python.org/commit/" rel="noreferrer" target="_blank">bugs.python.org/commit/</a><ID> page that had the mapping embedded in<br>> some JavaScript and if <ID> matched then we just forward them to the<br>> corresponding GitHub commit page, otherwise just blindly forward to GitHub<br>> and assume the ID is git-only, giving us a stable URL for commit web views.<br>><br><br>As I mentioned on python-committers, we already have<br><a href="https://hg.python.org/lookup/" rel="noreferrer" target="_blank">https://hg.python.org/lookup/</a><span> </span>.<br>This is currently used to map SVN->HG (e.g.<br><a href="https://hg.python.org/lookup/r12345" rel="noreferrer" target="_blank">https://hg.python.org/lookup/r12345</a><span> </span>), and should be extended to<br>handle cs ids too.<br>The b.p.o linkifier can just convert all revision numbers and cs ids<br>to a<span> </span><a href="https://hg.python.org/lookup/" rel="noreferrer" target="_blank">https://hg.python.org/lookup/</a><span> </span>link and let the lookup page figure<br>out where to redirect the user.<br><br>> Fourth, for the ancillary repos of devinabox, peps, benchmarks, and<br>> devguide, do we care if we use the GitHub merge button for PRs or do we want<br>> to enforce a linear history with all repos? We just need to decide if care<br>> about linear histories and then we can move forward since any bot we create<br>> won't block us from using GitHub.<br>><br>> Those four things are enough to move devinabox over. It probably is enough<br>> for the benchmarks suite, but I have an email to speed@ asking if people<br>> want to use this opportunity to re-evaluate the benchmark suite and make any<br>> changes that will affect repo size (e.g., use pip to pull in the libraries<br>> and frameworks used by a benchmark rather than vendoring their code, making<br>> the repo much smaller).<br>><br>> Website-related stuff<br>> ================<br>> This also almost gets us the peps repo, but we do need to figure out how to<br>> change the website to build from the git checkout rather than an hg one.<br>> Same goes for the devguide. It would be great if we can set up web hooks to<br>> immediately trigger rebuilds of those portions of the sites instead of<br>> having to wait until a cronjob triggers.<br>><br><br>I think we should make<span> </span><a href="http://hg.python.org/" rel="noreferrer" target="_blank">hg.python.org</a><span> </span>read-only but keep it around and<br>in sync with the GitHub repo (either via cronjobs or hooks).  This<br>will allow people to contribute using HG in the same way that the<br>current GitHub clone allows people to contribute using git.  It will<br>also avoid breaking all the tools that currently use<span> </span><a href="http://hg.python.org/" rel="noreferrer" target="_blank">hg.python.org</a><br>(and buys us more time to port them if/when needed).<br></blockquote><div><br></div><div>That's easy to say, but someone also has to maintain<span> </span><a href="http://hg.python.org/" target="_blank">hg.python.org</a><span> </span>then and we are doing this move partially to try and cut down on the amount of custom infrastructure that we maintain. If people are that worried about others being so adverse to using GitHub that they won't even do an anonymous clone from their servers then we can get a Bitbucket or GitLab clone set up, but I would rather try and cut out our repo hosting services if possible (who knows, maybe we can even finally retire<span> </span><a href="http://svn.python.org/" target="_blank">svn.python.org</a><span> </span>thanks to shallow clones or something).</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I think a mirror is a different level of involvement than running the main repository. We won’t have to worry about backups, if the server goes down people can still contribute, etc. Most likely it will also be able to be resized to a smaller server as well (but maybe not). I don’t think any of the infra team would be upset at one less server to manage though, so I’m more than happy either way.</div></div></div></blockquote><div><br></div><div>Then I leave it to the infrastructure team to discuss amongst themselves to tell me if they think keeping <a href="http://hg.python.org">hg.python.org</a> up as a mirror is no big deal or if they simply want to set up some mirror at another host like Bitbucket or GitLab. Since it's your burden in the end it should be your decision as to whether you want to shoulder it to give people a purely open source way to contribute to Python (I also leave it in your hands whether making it a git or hg mirror is easier).</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> CPython requirements<br>> =================<br>> There are six things to work out before we move over cpython. First, do we<br>> want to split out Python 2 branches into their own repo? There might be a<br>> clone size benefit which obviously is nice for people on slow Internet<br>> connections. It also clearly separates out Python 2 from 3 and lets those<br>> who prefer to focus on one compared to the other do that more easily. It<br>> does potentially make any single fix that spans 2 and 3 require a bit more<br>> work since it won't be an intra-clone change. We could also contemplate<br>> sub-repos for things like the Doc/ or Tools/ directories (although I doubt<br>> it's worth it).<br>><br><br>I think we should keep 2/3 together.  We could split the stdlib from<br>the rest, but that's a separate issue.<br></blockquote><div><br></div><div>This seems to be the general consensus, so we will plan to keep cpython as a single repo.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> Second, do we want all fixes to go into master and then cherry-pick into<br>> other branches, or do we want to follow our current practice of going into<br>> the active feature branch and then merge into master? I personally prefer<br>> the former and I think most everyone else does as well, but I thought it<br>> should be at least thought about.<br>><br><br>Master first and cherry-picking for older branches sounds good to me,<br>but I don't know if switching model will have any implications,<br>especially while going through the history or using tools like bisect.<br></blockquote><div><br></div><div>This seems to be the general consensus, so we will plan to cherry pick commits into older branches.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> Third, how to handle Misc/NEWS? We can add a NEWS field to<span> </span><a href="http://bugs.python.org/" rel="noreferrer" target="_blank">bugs.python.org</a><br>> and then generate the NEWS file by what issues are tied to what version and<br>> when they were closed. The other approach is to create a file per NEWS entry<br>> in a version-specific directory (Larry created code for hg already for this<br>> to give people an idea:<span> </span><a href="http://bugs.python.org/issue18967" rel="noreferrer" target="_blank">http://bugs.python.org/issue18967</a>). Then when we cut<br>> a release we run a tool the slurps up all of the relevant files -- which<br>> includes files in the directory for the next feature release which represent<br>> fixes which were cherry picked -- and generates the NEWS file for the final<br>> release. The per-file approach is bot-friendly and also CLI-friendly, but<br>> potentially requires more tooling and I don't know if people feel news<br>> entries should be tied to the issue or in the repo (although that assumes<br>> people find tweaking Roundup easy :).<br>><br>> Fourth, we need to decide exactly what commands we expect core devs to run<br>> initially for committing code. Since we agreed to a linear history we need<br>> to document exactly what we expect people to do for a PR to get it into<br>> their git repo. This will go into the devguide -- probably will want to<br>> start a github branch at some point -- and will act as the commands the bot<br>> will want to work off of.<br>><br><br>I would like to see a complete list of steps from starting to work on<br>an issue to having it in the repo, at least to understand the new<br>workflow.  This doesn't have to include all the specific commands, but<br>at least the basic steps (e.g. after I made a patch to I commit it and<br>send a pull request to the main repo, or do I push it to my GitHub<br>clone and push a button to send the PR?  Do I need to create a branch<br>before I start working on an issue?<br></blockquote><div><br></div><div>There will be a step-by-step guide in the devguide to answer all of this before we make any switch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> Fifth, what to do about Misc/ACKS? Since we are using PRs, even if we<br>> flatten them, I believe the PR creators will get credit in the commit as the<br>> author while the core dev committing will be flagged as the person doing the<br>> merge (someone correct me if I'm wrong because if I am this whole point is<br>> silly). With the commits containing credit directly, we can either<br>> automatically generate Misc/ACKS like the NEWS file or simply drop it for<br>> future contributors and just leave the file for past contributors since git<br>> will have kept track for us.<br>><br><br>We could keep updating for regular patches with no related PR and add<br>a note about all the other GIT contributors (possibly with a git<br>command that lists all authors).<br>Later on we might decide to have a script that automatically adds all<br>the GIT contributors automatically.<br></blockquote><div><br></div><div>This seems to be the general consensus, so we will keep Misc/ACKS around and have a tool that updates it based on git PR commits at release-time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>> Six, we will need to update our Buildbot fleet.<br>><br><br>If we keep hg.p.o around and updated, we might not have to do this now<br>(even though now is better than never).<br><br>> This gets us to the bare minimum needed to function.<br>><br>> Parity with<span> </span><a href="http://hg.python.org/" rel="noreferrer" target="_blank">hg.python.org</a><br>> ----------------------------------<br>> For parity, there are some Roundup integrations that will be necessary, like<br>> auto-generating links, posting commits to #python-dev on IRC, etc. I'm not<br>> sure if people want to block until that is all in place or not. I do think<br>> we should make sure there is some web hook that can take an issue # from the<br>> title of a PR and automatically posts to the corresponding issue on<br>><span> </span><a href="http://bugs.python.org/" rel="noreferrer" target="_blank">bugs.python.org</a><span> </span>that the PR exists. If people disagree then feel free to say<br>> so.<br>><br><br>FWIW I started adding notes to<br><a href="https://wiki.python.org/moin/TrackerDevelopmentPlanning" rel="noreferrer" target="_blank">https://wiki.python.org/moin/TrackerDevelopmentPlanning</a><span> </span>to track<br>everything that needs to be done on the Roundup side.<br>If you prefer I can later move this to the new PEP, but for now I'm<br>using it to keep track of all the things that come up in the various<br>threads.<br></blockquote><div><br></div><div>Nope, the wiki is fine for that sort of thing.</div><div><br></div><div>-Brett</div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">core-workflow mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:core-workflow@python.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">core-workflow@python.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://mail.python.org/mailman/listinfo/core-workflow" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://mail.python.org/mailman/listinfo/core-workflow</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">This list is governed by the PSF Code of Conduct:<span> </span></span><a href="https://www.python.org/psf/codeofconduct" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://www.python.org/psf/codeofconduct</a></div></blockquote></div></div><div style="word-wrap:break-word"><div>
<br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

</div>
<br></div></blockquote></div></div>