From donald.stufft at gmail.com Fri Apr 1 15:27:23 2016 From: donald.stufft at gmail.com (Donald Stufft) Date: Fri, 1 Apr 2016 15:27:23 -0400 Subject: [core-workflow] New Github Features Message-ID: Just wanted to point out a few new features from GitHub that may (or may not!) be useful for Python?s use of Github: * Required status checks no longer requiring a branch to be up to date. Previously turning on required status checks meant that to merge a branch into a protected branch, you the target branch could not contain any commits that didn?t exist in the PR. This effectively made the feature useless for OSS projects, but it could be useful now. Of course this would also mean that all changes need to happen via PR instead of directly pushing to a protected branch, so it may not still be useful for Python. * Squash Merges, Regular Merges, or Both. Previously the GitHub "Merge" button would always do a regular, no fast forward merge which kept all of the commits that the original author made intact. However GitHub now allows a repository to decide what kind of merges it allows, either that or sqaush merges (or it can allow both). If it allows both then the person doing the merge gets to pick what kind of merge I think. A Squash merge will be most similar to how patches used to land on Python and would prevent history from getting clogged up with needless commits from people who don't edit history to keep their PRs clean, however it might lose history from people who do. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brett at python.org Fri Apr 1 16:59:52 2016 From: brett at python.org (Brett Cannon) Date: Fri, 01 Apr 2016 20:59:52 +0000 Subject: [core-workflow] New Github Features In-Reply-To: References: Message-ID: On Fri, 1 Apr 2016 at 12:34 Donald Stufft wrote: > Just wanted to point out a few new features from GitHub that may (or may > not!) > be useful for Python?s use of Github: > > * Required status checks no longer requiring a branch to be up to date. > > Previously turning on required status checks meant that to merge a branch > into a protected branch, you the target branch could not contain any > commits > that didn?t exist in the PR. This effectively made the feature useless > for > OSS projects, but it could be useful now. Of course this would also mean > that > all changes need to happen via PR instead of directly pushing to a > protected > branch, so it may not still be useful for Python. > We have actually talked about trying to encourage all core devs to go through code review. Obviously that still only matters, though, if you merge through the GitHub UI, which leads to your next point ... > > * Squash Merges, Regular Merges, or Both. > > Previously the GitHub "Merge" button would always do a regular, no fast > forward merge which kept all of the commits that the original author made > intact. However GitHub now allows a repository to decide what kind of > merges > it allows, either that or sqaush merges (or it can allow both). If it > allows > both then the person doing the merge gets to pick what kind of merge I > think. > > A Squash merge will be most similar to how patches used to land on Python > and would prevent history from getting clogged up with needless commits > from > people who don't edit history to keep their PRs clean, however it might > lose > history from people who do. > Wow! For those of you who, like me, didn't know about this, it was posted to the GitHub blog earlier today: https://github.com/blog/2141-squash-your-commits (I hope this isn't an elaborate April Fools prank). I have already tried this out on the CLA bot to see how it operates and it works as expected; you can see a PR with multiple commits and the resulting single commit on the repo. This looks to give Guido that linear commit history he really wants for CPython! The trick, though, is that this doesn't handle merges into other branches and it doesn't cover Misc/NEWS. The question then becomes how to handle those situations. For the merge bit, if we switched from our idea of cherrypicking to sticking with our merge forward solution like we do in hg then you can manually create the merge-forward PR in GitHub's web UI which is no worse than how it operates now. And if there is a merge conflict then you can manually check out the PR, patch it up, and then be on your merry way. The issue with that is if your merge fails and you're not on a computer where you can fix up the merge as that could fall on someone else's shoulders who wants to do a merge while you wait to get home on a computer to do the fixing. I'm not sure how often that would really happen, though, as most merges are fairly clean. As for Misc/NEWS, we could stick with the plan of moving to a file-based solution but have external contributors actually write the NEWS entry. Core devs could then request any rewrite they have for the entry which wouldn't be a huge burden thanks to GitHub's in-browser editor. We could even go as far as having a Misc/NEWS status check that flags when there is no Misc/NEWS entry (that may be an issue, though, if in the future we choose to have commits be blocked by failing status checks; won't happen until our test suite is not flaky, though). So this support of squash merging *may* be useful. It really depends on how we try and support porting changes between versions and Misc/NEWS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald.stufft at gmail.com Fri Apr 1 17:02:54 2016 From: donald.stufft at gmail.com (Donald Stufft) Date: Fri, 1 Apr 2016 17:02:54 -0400 Subject: [core-workflow] New Github Features In-Reply-To: References: Message-ID: <551A4CB5-4219-4C0D-B5CC-CDFE068C7D55@gmail.com> > On Apr 1, 2016, at 4:59 PM, Brett Cannon wrote: > > As for Misc/NEWS, we could stick with the plan of moving to a file-based solution but have external contributors actually write the NEWS entry. Core devs could then request any rewrite they have for the entry which wouldn't be a huge burden thanks to GitHub's in-browser editor. We could even go as far as having a Misc/NEWS status check that flags when there is no Misc/NEWS entry (that may be an issue, though, if in the future we choose to have commits be blocked by failing status checks; won't happen until our test suite is not flaky, though). https://warehouse.python.org/project/towncrier/ Might be useful. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brett at python.org Fri Apr 1 17:05:25 2016 From: brett at python.org (Brett Cannon) Date: Fri, 01 Apr 2016 21:05:25 +0000 Subject: [core-workflow] New Github Features In-Reply-To: <551A4CB5-4219-4C0D-B5CC-CDFE068C7D55@gmail.com> References: <551A4CB5-4219-4C0D-B5CC-CDFE068C7D55@gmail.com> Message-ID: On Fri, 1 Apr 2016 at 14:03 Donald Stufft wrote: > > On Apr 1, 2016, at 4:59 PM, Brett Cannon wrote: > > As for Misc/NEWS, we could stick with the plan of moving to a file-based > solution but have external contributors actually write the NEWS entry. Core > devs could then request any rewrite they have for the entry which wouldn't > be a huge burden thanks to GitHub's in-browser editor. We could even go as > far as having a Misc/NEWS status check that flags when there is no > Misc/NEWS entry (that may be an issue, though, if in the future we choose > to have commits be blocked by failing status checks; won't happen until our > test suite is not flaky, though). > > > https://warehouse.python.org/project/towncrier/ Might be useful. > It's mentioned in the PEP: https://www.python.org/dev/peps/pep-0512/#how-to-handle-the-misc-news-file . -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Apr 2 01:07:21 2016 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 2 Apr 2016 15:07:21 +1000 Subject: [core-workflow] New Github Features In-Reply-To: References: Message-ID: On 2 April 2016 at 06:59, Brett Cannon wrote: > So this support of squash merging may be useful. It really depends on how we > try and support porting changes between versions and Misc/NEWS. Having the bot handle squashing is likely still desirable, since the flow you really want is: - squash & rebase the PR - run the test suite/build the docs (depending on modified files) - commit if successful Having what-you-commit and what-you-tested be different always loses some of the benefits of pre-commit CI (regardless of whether the differences arise from merging, rebasing, squashing, or some combination thereof) There's still value in a "check" CI run to see whether a patch is even worth trying to commit, but it's a separate activity from actually gating commits on the test suite passing. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From bussonniermatthias at gmail.com Sat Apr 2 13:48:46 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Sat, 2 Apr 2016 10:48:46 -0700 Subject: [core-workflow] New Github Features In-Reply-To: References: Message-ID: > On Apr 1, 2016, at 22:07, Nick Coghlan wrote: > > On 2 April 2016 at 06:59, Brett Cannon wrote: >> So this support of squash merging may be useful. It really depends on how we >> try and support porting changes between versions and Misc/NEWS. > > Having the bot handle squashing is likely still desirable, since the > flow you really want is: > > - squash & rebase the PR > - run the test suite/build the docs (depending on modified files) > - commit if successful > > Having what-you-commit and what-you-tested be different always loses > some of the benefits of pre-commit CI (regardless of whether the > differences arise from merging, rebasing, squashing, or some > combination thereof) Note that GitHub exposes the "future" merge commit as refs/pull//merge and Travis CI, for example, does test the merge commit and not the head of the PR. $ git fetch origin +refs/pull/1293/merge: ... * branch refs/pull/1293/merge -> FETCH_HEAD ... $ git checkout -qf FETCH_HEAD ... # run test suite. Thus you are technically testing the "future" state of master, and clicking the merge button will just move the master ref to this new commit ? and this is why merge is often instantaneous, as the merge was already done. Just to contradict myself, I don't know if CI is re-triggered on PR X if PR Y get merged. And this is partially irrelevant if you want to get rid of merge commits. I don't know how other CI works though, and I don't know if GitHub expose the (future) squashed commit, but that seem possible. -- M > There's still value in a "check" CI run to see whether a patch is even > worth trying to commit, but it's a separate activity from actually > gating commits on the test suite passing. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > 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 From bussonniermatthias at gmail.com Sat Apr 2 13:50:39 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Sat, 2 Apr 2016 10:50:39 -0700 Subject: [core-workflow] New Github Features In-Reply-To: References: Message-ID: <046D7DE2-2A49-4DE2-80FB-78470469EEB6@gmail.com> > On Apr 1, 2016, at 22:07, Nick Coghlan wrote: > > On 2 April 2016 at 06:59, Brett Cannon wrote: >> So this support of squash merging may be useful. It really depends on how we >> try and support porting changes between versions and Misc/NEWS. > > Having the bot handle squashing is likely still desirable, since the > flow you really want is: > > - squash & rebase the PR > - run the test suite/build the docs (depending on modified files) > - commit if successful > > Having what-you-commit and what-you-tested be different always loses > some of the benefits of pre-commit CI (regardless of whether the > differences arise from merging, rebasing, squashing, or some > combination thereof) Note that GitHub exposes the "future" merge commit as refs/pull//merge and Travis CI, for example, does test the merge commit and not the head of the PR. $ git fetch origin +refs/pull/1293/merge: ... * branch refs/pull/1293/merge -> FETCH_HEAD ... $ git checkout -qf FETCH_HEAD ... # run test suite. Thus you are technically testing the "future" state of master, and clicking the merge button will just move the master ref to this new commit ? and this is why merge is often instantaneous, as the merge was already done. Just to contradict myself, I don't know if CI is re-triggered on PR X if PR Y get merged. And this is partially irrelevant if you want to get rid of merge commits. I don't know how other CI works though, and I don't know if GitHub expose the (future) squashed commit, but that seem possible. -- M > There's still value in a "check" CI run to see whether a patch is even > worth trying to commit, but it's a separate activity from actually > gating commits on the test suite passing. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > 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 From solipsis at pitrou.net Thu Apr 14 05:14:50 2016 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 14 Apr 2016 11:14:50 +0200 Subject: [core-workflow] New Github Features References: Message-ID: <20160414111450.38503b12@fsol> On Sat, 2 Apr 2016 15:07:21 +1000 Nick Coghlan wrote: > On 2 April 2016 at 06:59, Brett Cannon wrote: > > So this support of squash merging may be useful. It really depends on how we > > try and support porting changes between versions and Misc/NEWS. > > Having the bot handle squashing is likely still desirable, since the > flow you really want is: > > - squash & rebase the PR > - run the test suite/build the docs (depending on modified files) > - commit if successful What happens if there's a PR based on another PR? When the latter is squash-merged, the former will likely end up with many conflicts since git won't be able to reconcile the histories anymore. Regards Antoine. From rymg19 at gmail.com Thu Apr 14 10:39:55 2016 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Thu, 14 Apr 2016 09:39:55 -0500 Subject: [core-workflow] New Github Features In-Reply-To: <20160414111450.38503b12@fsol> References: <20160414111450.38503b12@fsol> Message-ID: Generally, if you also squash the second PR, it won't be hard to merge it, since you're resolving a small set of conflicts. If the second one consists of 10 commits, then the world will likely explode. -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something?s wrong. http://kirbyfan64.github.io/ On Apr 14, 2016 4:15 AM, "Antoine Pitrou" wrote: > On Sat, 2 Apr 2016 15:07:21 +1000 > Nick Coghlan wrote: > > On 2 April 2016 at 06:59, Brett Cannon wrote: > > > So this support of squash merging may be useful. It really depends on > how we > > > try and support porting changes between versions and Misc/NEWS. > > > > Having the bot handle squashing is likely still desirable, since the > > flow you really want is: > > > > - squash & rebase the PR > > - run the test suite/build the docs (depending on modified files) > > - commit if successful > > What happens if there's a PR based on another PR? When the latter is > squash-merged, the former will likely end up with many conflicts since > git won't be able to reconcile the histories anymore. > > Regards > > Antoine. > > > _______________________________________________ > 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: From solipsis at pitrou.net Thu Apr 14 10:47:32 2016 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 14 Apr 2016 16:47:32 +0200 Subject: [core-workflow] New Github Features References: <20160414111450.38503b12@fsol> Message-ID: <20160414164732.42636c6c@fsol> On Thu, 14 Apr 2016 09:39:55 -0500 Ryan Gonzalez wrote: > Generally, if you also squash the second PR, it won't be hard to merge it, > since you're resolving a small set of conflicts. If the second one consists > of 10 commits, then the world will likely explode. So, basically, don't squash a PR unless you know nobody else based their work on it. That matches my experience :-) Regards Antoine. From brett at python.org Fri Apr 22 19:27:06 2016 From: brett at python.org (Brett Cannon) Date: Fri, 22 Apr 2016 23:27:06 +0000 Subject: [core-workflow] Time to decide how to convert hg repos to git Message-ID: Now that I'm comfortable declaring the code for the CLA bot finished ( https://github.com/python/the-knights-who-say-ni), the next step is to finalize the command(s) we are going to use to convert hg repositories to git for migration to GitHub. Senthil, are you ready to make a final decision? Once I have the conversion command(s) documented in PEP 512 and I have created the "Python core" team on GitHub for all of the current Python core developers, I will migrate https://hg.python.org/devinabox to make sure that everything works. After that has been verified as working I will then look at migrating https://hg.python.org/devguide/ and https://hg.python.org/peps/ (will take a little bit more effort for both to get the web builds updated, and peps requires getting the PEP editors on-board). The benchmarks repo might actually not get migrated as there is talk of starting that repo from scratch. It's looking like we will stay on track to get at least one repository migrated by PyCon US! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Fri Apr 22 19:35:15 2016 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 22 Apr 2016 18:35:15 -0500 Subject: [core-workflow] Time to decide how to convert hg repos to git In-Reply-To: References: Message-ID: I had initially suggested hg-git, but after my (mostly negative) experience in trying to convert the CPython repo, my vote goes towards fast-export. Partly because it's the only once *specifically* designed for exporting, not trying to be a bridge like hg-git and the other tool. -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something?s wrong. http://kirbyfan64.github.io/ On Apr 22, 2016 6:27 PM, "Brett Cannon" wrote: > Now that I'm comfortable declaring the code for the CLA bot finished ( > https://github.com/python/the-knights-who-say-ni), the next step is to > finalize the command(s) we are going to use to convert hg repositories to > git for migration to GitHub. Senthil, are you ready to make a final > decision? > > Once I have the conversion command(s) documented in PEP 512 and I have > created the "Python core" team on GitHub for all of the current Python core > developers, I will migrate https://hg.python.org/devinabox to make sure > that everything works. After that has been verified as working I will then > look at migrating https://hg.python.org/devguide/ and > https://hg.python.org/peps/ (will take a little bit more effort for both > to get the web builds updated, and peps requires getting the PEP editors > on-board). The benchmarks repo might actually not get migrated as there is > talk of starting that repo from scratch. > > It's looking like we will stay on track to get at least one repository > migrated by PyCon US! > > _______________________________________________ > 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: From senthil at uthcode.com Fri Apr 22 21:45:11 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 22 Apr 2016 18:45:11 -0700 Subject: [core-workflow] Time to decide how to convert hg repos to git In-Reply-To: References: Message-ID: Hi Brett, On Fri, Apr 22, 2016 at 4:27 PM, Brett Cannon wrote: > Now that I'm comfortable declaring the code for the CLA bot finished ( > https://github.com/python/the-knights-who-say-ni), the next step is to > finalize the command(s) we are going to use to convert hg repositories to > git for migration to GitHub. Senthil, are you ready to make a final > decision? > Yes. I did experiments while collating points from others with multiple tools and I found that hg-git could be suitable for our export. It won't be a single command due to the size of our repo. It will be a multi-step process. 1. Initialize local a bare git repo 2. Use hg-git to migrate from local hg to local git repo. (Ensure the migration was complete. With branches as desired). 3. And finally, push the local git repo, 1000s of commits at a time to remote repo. I had tried it myself and was successful with this approach. https://github.com/orsenthil/cpython-hg-to-git The other tools and approaches I tried had failed for me. Here's my plan and a to do: 1. Even though it is a one-time operation, I plan to convert above steps into a trivial tool that we can use and verify independently. 2. Once we are satisfied with our local trials, you could use this tool once to convert the hg repo and push to canonical git repo. todo * I haven't talked to the maintainer of https://github.com/python/cpython repo yet. I should do that and see what differences will be between the semi-official mirror and repo created by the importing tool. It will help us make a more informed decision. I will follow up an update on this and the tool. Thanks, Senthil -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Apr 22 23:00:19 2016 From: brett at python.org (Brett Cannon) Date: Sat, 23 Apr 2016 03:00:19 +0000 Subject: [core-workflow] Time to decide how to convert hg repos to git In-Reply-To: References: Message-ID: On Fri, Apr 22, 2016, 18:45 Senthil Kumaran wrote: > Hi Brett, > > On Fri, Apr 22, 2016 at 4:27 PM, Brett Cannon wrote: > >> Now that I'm comfortable declaring the code for the CLA bot finished ( >> https://github.com/python/the-knights-who-say-ni), the next step is to >> finalize the command(s) we are going to use to convert hg repositories to >> git for migration to GitHub. Senthil, are you ready to make a final >> decision? >> > > Yes. I did experiments while collating points from others with multiple > tools and I found that hg-git could be suitable for our export. > It won't be a single command due to the size of our repo. It will be a > multi-step process. > > 1. Initialize local a bare git repo > 2. Use hg-git to migrate from local hg to local git repo. > (Ensure the migration was complete. With branches as desired). > 3. And finally, push the local git repo, 1000s of commits at a time to > remote repo. > > I had tried it myself and was successful with this approach. > https://github.com/orsenthil/cpython-hg-to-git > > The other tools and approaches I tried had failed for me. > > Here's my plan and a to do: > > 1. Even though it is a one-time operation, I plan to convert above steps > into a trivial tool that we can use and verify independently. > 2. Once we are satisfied with our local trials, you could use this tool > once to convert the hg repo and push to canonical git repo. > > todo > > * I haven't talked to the maintainer of https://github.com/python/cpython > repo yet. I should do that and see what differences will be between the > semi-official mirror and repo created by the importing tool. It will help > us make a more informed decision. > > I will follow up an update on this and the tool. > Great! Obviously the tool is more important as that is a blocker for devinabox while talking to Eli Bendersky about the mirror isn't. -Brett > Thanks, > Senthil > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Fri Apr 22 23:39:58 2016 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 23 Apr 2016 13:39:58 +1000 Subject: [core-workflow] Reviewing/updating the README for GitHub migration? Message-ID: By way of Twitter, I came across https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md today, and it made me realise something: we should probably add reviewing and potentially updating the README as part of the GitHub migration. The reason I suggest that is that with the way code hosting services like GitHub work, the README changes from something people may read for local development after they've already cloned the repo to instead being the main landing page for the repo. That means it becomes a good place to point out things like: - the location of the main dev guide - the issue tracker - the communications channels - the PSF CLA (and the need to sign it for non-trivial contributions) That's not a blocker task, I mainly wanted to bring up the link to Nadia's guide and the rest of the email is explaining why I think that's relevant to us even though we already have the developer guide :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.alvarez at gmail.com Fri Apr 22 23:47:05 2016 From: nicolas.alvarez at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Alvarez?=) Date: Sat, 23 Apr 2016 00:47:05 -0300 Subject: [core-workflow] Time to decide how to convert hg repos to git In-Reply-To: References: Message-ID: 2016-04-22 22:45 GMT-03:00 Senthil Kumaran : > Hi Brett, > > On Fri, Apr 22, 2016 at 4:27 PM, Brett Cannon wrote: >> >> Now that I'm comfortable declaring the code for the CLA bot finished >> (https://github.com/python/the-knights-who-say-ni), the next step is to >> finalize the command(s) we are going to use to convert hg repositories to >> git for migration to GitHub. Senthil, are you ready to make a final >> decision? > > > Yes. I did experiments while collating points from others with multiple > tools and I found that hg-git could be suitable for our export. > It won't be a single command due to the size of our repo. It will be a > multi-step process. > > 1. Initialize local a bare git repo > 2. Use hg-git to migrate from local hg to local git repo. > (Ensure the migration was complete. With branches as desired). > 3. And finally, push the local git repo, 1000s of commits at a time to > remote repo. Note that git-fast-import produces extremely suboptimal git packs. You should run "git gc --aggressive" after converting. In KDE I have seen post-svn2git repos shrink by two or three orders of magnitude by repacking them with git-gc. Maybe if you do that, there is no need to push in batches of 1000 commits. -- Nicol?s From nicholas.chammas at gmail.com Sat Apr 23 00:15:32 2016 From: nicholas.chammas at gmail.com (Nicholas Chammas) Date: Sat, 23 Apr 2016 04:15:32 +0000 Subject: [core-workflow] Reviewing/updating the README for GitHub migration? In-Reply-To: References: Message-ID: On Fri, Apr 22, 2016 at 11:40 PM Nick Coghlan wrote: > The reason I suggest that is that with the way code hosting services like > GitHub work, the README changes from something people may read for local > development after they've already cloned the repo to instead being the main > landing page for the repo. > > That means it becomes a good place to point out things like: > > - the location of the main dev guide > - the issue tracker > - the communications channels > - the PSF CLA (and the need to sign it for non-trivial contributions) > I wonder if some of these bits of information could go in a GitHub pull request template: https://github.com/blog/2111-issue-and-pull-request-templates That way they get presented to the contributor as soon as they hit the "new pull request" button. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From motoom at xs4all.nl Sat Apr 23 08:40:56 2016 From: motoom at xs4all.nl (Michiel Overtoom) Date: Sat, 23 Apr 2016 14:40:56 +0200 Subject: [core-workflow] Time to decide how to convert hg repos to git In-Reply-To: References: Message-ID: <59B3A0C0-261D-48EA-848E-C16F44F25708@xs4all.nl> Hi, Are you aware the work ESR did for liberating source code repositories and moving them between version control systems? It also supports editing version-control repository history. http://www.catb.org/esr/reposurgeon/ He used it to port the Emacs repository to git, not an easy feat, and blogged about it: http://esr.ibiblio.org/?p=5634 and http://esr.ibiblio.org/?p=5211 Greetings, From brett at python.org Sat Apr 23 11:11:54 2016 From: brett at python.org (Brett Cannon) Date: Sat, 23 Apr 2016 15:11:54 +0000 Subject: [core-workflow] Reviewing/updating the README for GitHub migration? In-Reply-To: References: Message-ID: On Fri, 22 Apr 2016 at 21:16 Nicholas Chammas wrote: > On Fri, Apr 22, 2016 at 11:40 PM Nick Coghlan wrote: > >> The reason I suggest that is that with the way code hosting services like >> GitHub work, the README changes from something people may read for local >> development after they've already cloned the repo to instead being the main >> landing page for the repo. >> >> That means it becomes a good place to point out things like: >> >> - the location of the main dev guide >> - the issue tracker >> - the communications channels >> - the PSF CLA (and the need to sign it for non-trivial contributions) >> > > I wonder if some of these bits of information could go in a GitHub pull > request template: > > https://github.com/blog/2111-issue-and-pull-request-templates > > That way they get presented to the contributor as soon as they hit the > "new pull request" button. > My expectation is that the README will get tweaked and we will add a CONTRIBUTING file. As for PR templates, that's going to depend on what kind of workflow we end up with in terms of reviewing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at python.org Sat Apr 23 17:12:28 2016 From: brian at python.org (Brian Curtin) Date: Sat, 23 Apr 2016 17:12:28 -0400 Subject: [core-workflow] Time to decide how to convert hg repos to git In-Reply-To: <59B3A0C0-261D-48EA-848E-C16F44F25708@xs4all.nl> References: <59B3A0C0-261D-48EA-848E-C16F44F25708@xs4all.nl> Message-ID: On Sat, Apr 23, 2016 at 8:40 AM, Michiel Overtoom wrote: > > Hi, > > Are you aware the work ESR did for liberating source code repositories and moving them between version control systems? It also supports editing version-control repository history. > > http://www.catb.org/esr/reposurgeon/ > > He used it to port the Emacs repository to git, not an easy feat, and blogged about it: http://esr.ibiblio.org/?p=5634 and http://esr.ibiblio.org/?p=5211 There was talk about this on python-committers (and on this list, I think) but there seem to be more than enough other tools that can do the job and aren't associated with ESR.