From victor.stinner at gmail.com Mon Nov 23 03:58:07 2015 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 23 Nov 2015 09:58:07 +0100 Subject: [core-workflow] My feedback on the Python workflow Message-ID: Hi, Brett contacted me to ask me to try the new workflow to develop Python. I'm sorry, I completly missed the whole discussiong. I would like to share my feedback on the Python workflow and the OpenStack worklow. I will start by listing random issues with the current Python workflow, even if you all probably know them (I hope). I'm contributing to CPython since more than 5 years. Since I started to work on OpenStack, I realized that how the CPython workflow is outdated. Attached .patch files to a bug tracker was cool 10 years ago, but today using merges is preferred. Issues with .patch files: * it's hard to "rebase" a patch: even if the patch contains the base revision, it's not convenient to rebase a patch (it's hard to rebasing a branch) * it's very hard to work on a patch serie, so nobody does that. As a consequence, patches can be very long and hard to review The integration between Round up (bug tracker) and Rietveld (review) is good, but incomplete. Adding comments to Rietveld doesn't copy them to the bug tracker. Unsubscribe from a bug doesn't unsubscribe from the the review, which can be very annoying for review staying a month or much longer (lot of spam). Because of the Misc/NEWS file, it's never possible to simply apply bindly a patch. It's common that I modify a patch after a review, to fix minor nits, like coding style. I don't want to annoy contributors with such minor details at the *end* of the review (when I missed them before). Tests are only run after the commit, it's common to break *all* buildbots because of a stupid mistake in a patch. The common issue is that modifying the module xxx requires to run test_xxx, but test_yyy fails and the review and the commiter forgot to run all tests. Another common issue is that a change breaks all Windows buildbots because of an obvious compilation isssue, but too few core reviewers test and work on Windows. I don't think that it would be possible to run the *full* test suite on pre-commit, but it would be a nice enhancement to start with a small subset of tests on buildbots known to be very stable (ex: only one Linux buildbot). And later slowly add more and more tests, and more and more buildbots. It's also annoying that Mercurial has no committer field, and so that the original author is not tracked in commit metadata. All core developers try to put the author in the commit message, but it's not counted in statistics. It would motivate to give more credits to contributors to "show" their name in commits. The commiter is also a very important information, it's the responsible of regressions, he/she has to break regressions and all side effects of the change. (Even if it's common and totally ok if someone else fixes these issues.) Victor From victor.stinner at gmail.com Mon Nov 23 04:13:32 2015 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 23 Nov 2015 10:13:32 +0100 Subject: [core-workflow] I love OpenStack workflow Message-ID: Hi, I'm working on the huge OpenStack project since 2 years. I really like its development workflow, even if it can be seen as complex at the beginning. The core of the workflow are reviews using Gerrit at review.openstack.org. In fact, I probably spend 80% of my time on review.openstack.org when I work on OpenStack. I probably spend the remaining 20% on IRC, the mailing and meetings to discuss. OpenStack uses Git and has a cool "git review" tool. It's very easy to send a review: commit something locally, type "git review", that's all! Your change will not be modified by others, you are reponsible to fix all issues, including all annoying coding style issues. But it's easy to modify a change. You can use local Git branches. But it's also very easy to retrieve a change into a new local branch: git review -d . Since a change is a branch, retrieving a change does conflict. To rebase a change, use the common "git rebase master" command. Rebase is a common command in the OpenStack workflow. It's very easy to work on a patch serie: commit multiple changes locally, then type "git review". This common will create N reviews linked all together. For me, it's a real enhancement compared to the Python workflow. For example, it's common to start with a "cleanup/refactor" change and then a second change which does the "real" work (fix bug, add new feature, etc.). It's *much* easier to review a serie of small changes. On Gerrit, *anyone* can vote on a change. It's not used to ask for a bugfix. A vote means that the reviewer read the change and understand it. Votes: * +2: a core reviewer consider that the patch is good enough to be merged * +1: "looks good to me". A core reviewer may vote +1 to say "ok, but ..." with a comment * no vote: used to ask questions * -1: the patch must be updated to fix reported issues * -2: major design issue, you must rewrite your change differently, or the whole proposed change is rejected It's convenient to see a quick summary of votes. On Round Up, its requires to read individual comments, and almost nobody explicitly write "+1" or "-1" in comments on bugs.python.org. It's also possible to make a change depends on another. For example patch B depends on patch A. Even if the patch B is accepted, it will not be merged until the patch A is merged. Tests are run in pre-commit. There are 3 major kinds of tests: * coding style: basically, the flake8 command. Some projects use other tests (ex: pylint) * unit tests * functional tests It's very rare that coding style and unit tests produce "false positive". The functional tests are different. It's *common* to get random failures, it's almost "part of the process", even if it's very annoying. But it ensures that when a change is merged, it doesn't break anything. If it's no obvious: I would love to use the same workflow on CPython :-) Victor From victor.stinner at gmail.com Mon Nov 23 04:20:47 2015 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 23 Nov 2015 10:20:47 +0100 Subject: [core-workflow] Software Factory Message-ID: Hi, As I wrote in my previous "I love OpenStack workflow" email, I really like the Gerrit tool. I have colleagues at Red Hat working on an integration of Gerrit, Zuul, Jenkins, Etherpad, etc. to easily deploy such setup (install but also update). The project is called "Software Factory" and it's a libre software: http://softwarefactory-project.io/docs/intro.html It would allow us (Python) to own our data (reviews), rather than relying on a private provider like Gitlab (I don't know if Gitlab can be used completly freely on our own server). I'm sure that my colleagues would love to help us to deploy a test setup for Python! I don't know if we need all Software Factory tools: Gerrit, Redmine, Zuul, Jenkins, Nodepool, Etherpad, Pastebin. If we keep Round Up, we will have to write code to integrate Round Up with Gerrit. IMHO it's worth it :-) By the way, I used Jenkins for different projects and different companies, and I prefer Jenkins over Buildbot. Its output (test result) is *much* better than Buildbot. It understands that some tests are unstable and identify them. I would also be a nice enhancement to modify our test suite to produce JUnit compatible output and get Jenkins reports. What do you think? Ok, I sent 3 emails. It's maybe time for me to read all the backlog (archives of the mailing list, PEP 507, etc.) :-D Victor From donald at stufft.io Mon Nov 23 07:42:20 2015 From: donald at stufft.io (Donald Stufft) Date: Mon, 23 Nov 2015 07:42:20 -0500 Subject: [core-workflow] Software Factory In-Reply-To: References: Message-ID: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> > On Nov 23, 2015, at 4:20 AM, Victor Stinner wrote: > > Hi, > > As I wrote in my previous "I love OpenStack workflow" email, I really > like the Gerrit tool. > > I have colleagues at Red Hat working on an integration of Gerrit, > Zuul, Jenkins, Etherpad, etc. to easily deploy such setup (install but > also update). The project is called "Software Factory" and it's a > libre software: > http://softwarefactory-project.io/docs/intro.html > > It would allow us (Python) to own our data (reviews), rather than > relying on a private provider like Gitlab (I don't know if Gitlab can > be used completly freely on our own server). > > I'm sure that my colleagues would love to help us to deploy a test > setup for Python! > > I don't know if we need all Software Factory tools: Gerrit, Redmine, > Zuul, Jenkins, Nodepool, Etherpad, Pastebin. If we keep Round Up, we > will have to write code to integrate Round Up with Gerrit. IMHO it's > worth it :-) > > By the way, I used Jenkins for different projects and different > companies, and I prefer Jenkins over Buildbot. Its output (test > result) is *much* better than Buildbot. It understands that some tests > are unstable and identify them. I would also be a nice enhancement to > modify our test suite to produce JUnit compatible output and get > Jenkins reports. What do you think? > > Ok, I sent 3 emails. It's maybe time for me to read all the backlog > (archives of the mailing list, PEP 507, etc.) :-D > > Victor > _______________________________________________ > 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 TBH I really really hate Gerrit. The workflow it enables is fine, but Gerrit itself is horrible. ----------------- 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 victor.stinner at gmail.com Mon Nov 23 07:50:01 2015 From: victor.stinner at gmail.com (Victor Stinner) Date: Mon, 23 Nov 2015 13:50:01 +0100 Subject: [core-workflow] Software Factory In-Reply-To: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: 2015-11-23 13:42 GMT+01:00 Donald Stufft : > TBH I really really hate Gerrit. The workflow it enables is fine, but Gerrit itself is horrible. This kind of feedback is not really helpful :-/ Can you please elaborate? What's wrong with Gerrit? Gerrit is used on OpenStack which is a very large project: 4,689 developers, 200 commits per day, etc. Some statistics at: http://activity.openstack.org/dash/browser/ Victor From donald at stufft.io Mon Nov 23 08:01:56 2015 From: donald at stufft.io (Donald Stufft) Date: Mon, 23 Nov 2015 08:01:56 -0500 Subject: [core-workflow] Software Factory In-Reply-To: References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: > On Nov 23, 2015, at 7:50 AM, Victor Stinner wrote: > > 2015-11-23 13:42 GMT+01:00 Donald Stufft : >> TBH I really really hate Gerrit. The workflow it enables is fine, but Gerrit itself is horrible. > > This kind of feedback is not really helpful :-/ Can you please > elaborate? What's wrong with Gerrit? > > Gerrit is used on OpenStack which is a very large project: 4,689 > developers, 200 commits per day, etc. Some statistics at: > http://activity.openstack.org/dash/browser/ > > Victor I know, I was at one point, core on at least one Openstack project (I might have been on others, I forget) and I?ve been interacting with Openstack and their Gerrit since ~2011 or so. The UI of Gerrit is atrocious. It?s confusing and ugly. Once you spend the time to grok how it works it can be effective, but that requires sitting down and figuring out how it actually works first and one of the goals of the new workflows is lowering barriers to contributors, not shifting the learning curve from uploading patches to fighting with Gerrit. Often times when Openstack asks me to comment on something, I read it on Gerrit and then communicate my review via IRC because I find that massively less painful than fighting with Gerrit. I also rarely ever make changes via Gerrit anymore (ever since I stopped being paid for it) and I just tell someone else what change they should make and let them deal with Gerrit.[1] Openstack is a bit different because almost every contributor is being paid to work on it. That means that they don?t have to worry (as much) about on boarding pain because those people are being paid to sit there and learn how to use the tooling. CPython on the other hand is almost entirely worked on by volunteers so on boarding pain is very likely to just have people drop off instead of trying to learn the toolchain. It wouldn?t be hard to get most of the benefit of the Gerrit workflow in either Gitlab or Github. For Github there?s an external project called Reviewable which gives you a review interface similar to Gerrit (which I hate but some people like it I guess). Both of them support running CI on a branch (Though neither have the ?press merge button, but don?t merge until tests run again thing). I don?t know specifics of Gitlab very well, but for Github it?s trivial to get access to the changes of a PR as well. You just add a single line to your .git/config and then you can check PRs out as their own branches. [1] This works largely because I rarely need to make changes myself. They come to me with a packaging problem and I tell them what they need to change to fix it. ----------------- 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 ncoghlan at gmail.com Mon Nov 23 08:57:59 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 23 Nov 2015 23:57:59 +1000 Subject: [core-workflow] Software Factory In-Reply-To: References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: On 23 November 2015 at 23:01, Donald Stufft wrote: >> On Nov 23, 2015, at 7:50 AM, Victor Stinner wrote: > The UI of Gerrit is atrocious. It?s confusing and ugly. Once you spend the time to grok how it works it can be effective, but that requires sitting down and figuring out how it actually works first and one of the goals of the new workflows is lowering barriers to contributors, not shifting the learning curve from uploading patches to fighting with Gerrit. I unfortunately have to agree with this - while I *really* like several aspects of the Gerrit workflow (having used it while working on beaker-project.org, rather than OpenStack), to the point of finding pull request based workflows frustratingly clunky and unhelpful for anything that touches more than a few lines of code, Gerrit itself is really designed for cases where you have a highly engaged team using the review system as a combined discussion tool and task tracker, and less towards lowering barriers to review for simple cases. Pull requests in either GitHub or GitLab will already be an improvement over what we have today with Roundup+Rietveld, and they leave the door open to enabling a more complex *opt-in* review workflow in the future. While there's no counterpart to Reviewable for GitLab that I'm aware of, the merge request API is rich enough to enable one: http://doc.gitlab.com/ce/api/merge_requests.html (or, of course, GitLab themselves may decide to implement it). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brian at python.org Mon Nov 23 10:28:37 2015 From: brian at python.org (Brian Curtin) Date: Mon, 23 Nov 2015 09:28:37 -0600 Subject: [core-workflow] Software Factory In-Reply-To: References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: On Mon, Nov 23, 2015 at 7:01 AM, Donald Stufft wrote: > Openstack is a bit different because almost every contributor is being paid to work on it. That means that they don?t have to worry (as much) about on boarding pain because those people are being paid to sit there and learn how to use the tooling. CPython on the other hand is almost entirely worked on by volunteers so on boarding pain is very likely to just have people drop off instead of trying to learn the toolchain. There is close to zero chance I would have gotten into CPython while sitting on my couch in the evenings if it used Gerrit. This is actually a pretty big worry I have with a Gerrit-using project I work on, in that we're only ever going to attract insiders instead of having users get involved. From barry at python.org Mon Nov 23 12:22:45 2015 From: barry at python.org (Barry Warsaw) Date: Mon, 23 Nov 2015 12:22:45 -0500 Subject: [core-workflow] Software Factory References: Message-ID: <20151123122245.6751045b@anarchist.wooz.org> On Nov 23, 2015, at 10:20 AM, Victor Stinner wrote: >It would allow us (Python) to own our data (reviews), rather than >relying on a private provider like Gitlab (I don't know if Gitlab can >be used completly freely on our own server). It can. The community edition is completely open source and the enterprise edition probably doesn't have features we'd miss. >I don't know if we need all Software Factory tools: Gerrit, Redmine, >Zuul, Jenkins, Nodepool, Etherpad, Pastebin. If we keep Round Up, we >will have to write code to integrate Round Up with Gerrit. IMHO it's >worth it :-) I'm not a huge fan of Jenkins, although it serves its purpose. I don't think it's an either-or with Buildbot though. They compliment each other well since as you point out, you just can't test everything on every platform before every landing. We currently use Jenkins in the Ubuntu touch build system, and I find its u/i dreadful, especially when trying to track down where build failure artifacts live. GitLab does have its own open source runner which integrates nicely with that service so even merge requests can be sanity checked, and I can see those results immediately when reviewing a branch. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ncoghlan at gmail.com Mon Nov 23 22:00:38 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 24 Nov 2015 13:00:38 +1000 Subject: [core-workflow] Software Factory In-Reply-To: <20151123122245.6751045b@anarchist.wooz.org> References: <20151123122245.6751045b@anarchist.wooz.org> Message-ID: On 24 November 2015 at 03:22, Barry Warsaw wrote: > On Nov 23, 2015, at 10:20 AM, Victor Stinner wrote: > >>It would allow us (Python) to own our data (reviews), rather than >>relying on a private provider like Gitlab (I don't know if Gitlab can >>be used completly freely on our own server). > > It can. The community edition is completely open source and the enterprise > edition probably doesn't have features we'd miss. The feature comparison chart is at https://about.gitlab.com/features/#compare Some of the richer review workflow features are only in the Enterprise edition (including the ones that let you make GitLab a bit more like Gerrit, by requiring multiple sign-offs, rebasing merge requests through the web UI, etc), but I agree we could ask GitLab to offer us a Community Edition instance without missing anything critical. That said, one we should get clarified is the "git hooks" feature. Since hook processing is handled by git rather than GitLab, I *think* that feature just refers to the web UI [1] linked from the features page for defining certain hooks without having to write the relevant scripts yourself, but we should get that clarified explicitly (since we're still going to want to run pre-receive hooks like the indentation checking one and the whitespace one, even if we also have those checks automated in pre-merge CI). Cheers, Nick. [1] http://doc.gitlab.com/ee/git_hooks/git_hooks.html -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at snarky.ca Mon Nov 23 11:50:41 2015 From: brett at snarky.ca (Brett Cannon) Date: Mon, 23 Nov 2015 16:50:41 +0000 Subject: [core-workflow] Software Factory In-Reply-To: References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: Two things. One, I will add to the chorus of people who don't like Gerrit, and this is from using the project. There is no chance we are switching to Gerrit based on our other options. Two, it's too late to propose another workflow option anyway as we already spent this year getting proposals together. As outlined in my personal notes at https://docs.google.com/document/d/1VewK3MpkT4Qv2SildCKp8crbs-1S6RgPcsUzt_sbJOw/edit , I am only considering GitHub and GitLab at this point; all other options are too late to be considered. If you have comments to make you can leave them on the doc, although since this is geared towards improving the workflow for core devs that means comments from people in that capacity will be valued the most. I'm collecting feedback on the workflows from people until Dec 1. I'm going to take the feedback and questions people have back to the people who have made the proposals for answers by Dec 15 so I can make a decision by Jan 1. On Mon, 23 Nov 2015 at 07:28 Brian Curtin wrote: > On Mon, Nov 23, 2015 at 7:01 AM, Donald Stufft wrote: > > Openstack is a bit different because almost every contributor is being > paid to work on it. That means that they don?t have to worry (as much) > about on boarding pain because those people are being paid to sit there and > learn how to use the tooling. CPython on the other hand is almost entirely > worked on by volunteers so on boarding pain is very likely to just have > people drop off instead of trying to learn the toolchain. > > There is close to zero chance I would have gotten into CPython while > sitting on my couch in the evenings if it used Gerrit. This is > actually a pretty big worry I have with a Gerrit-using project I work > on, in that we're only ever going to attract insiders instead of > having users get involved. > _______________________________________________ > 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 guido at python.org Tue Nov 24 13:30:36 2015 From: guido at python.org (Guido van Rossum) Date: Tue, 24 Nov 2015 10:30:36 -0800 Subject: [core-workflow] Software Factory In-Reply-To: References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: I didn't do a thorough feature-by-feature eval, but I did play with both test repos. While I'm sure I could learn to use GitLab, it was slow, and what I saw didn't sway me -- my preference remains GitHub. It feels to me as if GitLab is just trying to be an open-source reimplementation of GitHub, and it's not (yet) a very good one. It's not going to succeed in getting a lot of users this way. Almost every recently-started project I interact with is on GitHub, and many old ones have also moved there. GitHub's popularity feels like an overwhelming argument to just move there, and its feature set is fine. Both seem to have commercial interest into locking users in; but in the end we will have many clones of the repo so I'm not worried about that. (We managed to move away from SourceForge in time too, with no real damage. :-) On Mon, Nov 23, 2015 at 8:50 AM, Brett Cannon wrote: > Two things. > > One, I will add to the chorus of people who don't like Gerrit, and this is > from using the project. There is no chance we are switching to Gerrit based > on our other options. > > Two, it's too late to propose another workflow option anyway as we already > spent this year getting proposals together. As outlined in my personal notes > at > https://docs.google.com/document/d/1VewK3MpkT4Qv2SildCKp8crbs-1S6RgPcsUzt_sbJOw/edit > , I am only considering GitHub and GitLab at this point; all other options > are too late to be considered. If you have comments to make you can leave > them on the doc, although since this is geared towards improving the > workflow for core devs that means comments from people in that capacity will > be valued the most. > > I'm collecting feedback on the workflows from people until Dec 1. I'm going > to take the feedback and questions people have back to the people who have > made the proposals for answers by Dec 15 so I can make a decision by Jan 1. > > On Mon, 23 Nov 2015 at 07:28 Brian Curtin wrote: >> >> On Mon, Nov 23, 2015 at 7:01 AM, Donald Stufft wrote: >> > Openstack is a bit different because almost every contributor is being >> > paid to work on it. That means that they don?t have to worry (as much) about >> > on boarding pain because those people are being paid to sit there and learn >> > how to use the tooling. CPython on the other hand is almost entirely worked >> > on by volunteers so on boarding pain is very likely to just have people drop >> > off instead of trying to learn the toolchain. >> >> There is close to zero chance I would have gotten into CPython while >> sitting on my couch in the evenings if it used Gerrit. This is >> actually a pretty big worry I have with a Gerrit-using project I work >> on, in that we're only ever going to attract insiders instead of >> having users get involved. >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 -- --Guido van Rossum (python.org/~guido) From ncoghlan at gmail.com Wed Nov 25 01:17:09 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 25 Nov 2015 16:17:09 +1000 Subject: [core-workflow] Software Factory In-Reply-To: References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: On 25 November 2015 at 04:30, Guido van Rossum wrote: > Both seem to have commercial interest into locking users in; Since the commercial side of things has come up, it's worth noting that they're operating on a couple of orders of magnitude difference in scale on that front - GitHub need to generate a return sufficient to justify around $350m in capital investment, while GitLab's capital investment base is a more modest $1.5 million. The upside of GitHub's larger capital base is greater funding for the "free" side of their freemium business model, the downside is greater demands on their revenue side in order to generate a suitable return for investors in a crowded enterprise development tools market. The benefit of GitLab's lower capital base is that it means their revenue targets can be lower, which means they can be more aggressive in which features they make available entirely for free in the Community Edition. >From a purely pragmatic perspective though, "Import from GitHub" is already one of the features offered by GitLab, and will no doubt be a standard feature of any other open source repository management systems that gains widespread popularity in the future. Donald also noted a while back that this is a reasonable lesson to take away from the Linux kernel Bitkeeper experiment - they used the proprietary service for as long as the vendor was playing nice, and when the relationship soured, they migrated away again. This means that while I still favour retaining a welcoming environment for strict free software advocates over going with a fully proprietary SaaS option for our workflow, I also think the available export options from GitHub are already good enough to ensure we're covered from an infrastructure risk management perspective. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From barry at python.org Wed Nov 25 11:25:28 2015 From: barry at python.org (Barry Warsaw) Date: Wed, 25 Nov 2015 11:25:28 -0500 Subject: [core-workflow] Software Factory References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> Message-ID: <20151125112528.6e1cfe02@anarchist.wooz.org> On Nov 25, 2015, at 04:17 PM, Nick Coghlan wrote: >This means that while I still favour retaining a welcoming environment >for strict free software advocates over going with a fully proprietary >SaaS option for our workflow, I also think the available export >options from GitHub are already good enough to ensure we're covered >from an infrastructure risk management perspective. Agreed that the risk of proprietary lock-in is fairly low, especially because we aren't moving our tracker, we're really just looking for git hosting and a nicer review/merge u/i. Of course, I still favor a free software solution that we can have some influence over, rather than a closed solution we're just a client of. However, I think Donald still intends to update PEP 481 to remove the recommendation of Phabricator, right? Also, PEP 481 doesn't mention how hosting is going to work. Under this PEP would Python be Just Another Project at github.com or would we have a branded git.python.org host? Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From donald at stufft.io Wed Nov 25 11:40:20 2015 From: donald at stufft.io (Donald Stufft) Date: Wed, 25 Nov 2015 11:40:20 -0500 Subject: [core-workflow] Software Factory In-Reply-To: <20151125112528.6e1cfe02@anarchist.wooz.org> References: <84F54A7B-82F0-4390-A66F-6F35E881EC1A@stufft.io> <20151125112528.6e1cfe02@anarchist.wooz.org> Message-ID: I forgot to do that update. Yes I am going to remove the Phabricator bits. We would also be yet another project on GitHub though it would be trivial to mirror it to git.p.o if we wanted it. Sent from my iPhone > On Nov 25, 2015, at 11:25 AM, Barry Warsaw wrote: > >> On Nov 25, 2015, at 04:17 PM, Nick Coghlan wrote: >> >> This means that while I still favour retaining a welcoming environment >> for strict free software advocates over going with a fully proprietary >> SaaS option for our workflow, I also think the available export >> options from GitHub are already good enough to ensure we're covered >> from an infrastructure risk management perspective. > > Agreed that the risk of proprietary lock-in is fairly low, especially because > we aren't moving our tracker, we're really just looking for git hosting and a > nicer review/merge u/i. Of course, I still favor a free software solution > that we can have some influence over, rather than a closed solution we're just > a client of. > > However, I think Donald still intends to update PEP 481 to remove the > recommendation of Phabricator, right? > > Also, PEP 481 doesn't mention how hosting is going to work. Under this PEP > would Python be Just Another Project at github.com or would we have a branded > git.python.org host? > > Cheers, > -Barry > _______________________________________________ > 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 donald at stufft.io Wed Nov 25 14:06:38 2015 From: donald at stufft.io (Donald Stufft) Date: Wed, 25 Nov 2015 14:06:38 -0500 Subject: [core-workflow] Software Factory In-Reply-To: References: Message-ID: <7045110C-D50C-44BF-91C4-DA40F329059D@stufft.io> > On Nov 23, 2015, at 4:20 AM, Victor Stinner wrote: > > As I wrote in my previous "I love OpenStack workflow" email, I really > like the Gerrit tool. Just thought I'd share, today I heard through the grapevine that Github is planning some improvements to the PR workflow to pull in some of the functionality that systems like Gerrit have. Things like marking comments as resolved, sending multiple inline comments at once, seeing changes since last review, etc. I don't know the timeline or how accurate it is, but just figured I'd share that I've heard some rumblings that improvements may be coming. ----------------- 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 skrah.temporarily at gmail.com Thu Nov 26 16:05:03 2015 From: skrah.temporarily at gmail.com (Stefan Krah) Date: Thu, 26 Nov 2015 21:05:03 +0000 (UTC) Subject: [core-workflow] Software Factory Message-ID: [Posting via gmane, followup seems to be broken.] [Nick] > From a purely pragmatic perspective though, "Import from GitHub" is > already one of the features offered by GitLab, and will no doubt be a > standard feature of any other open source repository management > systems that gains widespread popularity in the future. Donald also > noted a while back that this is a reasonable lesson to take away from > the Linux kernel Bitkeeper experiment - they used the proprietary > service for as long as the vendor was playing nice, and when the > relationship soured, they migrated away again. I think this is different from BitKeeper: GitHub has a dossier on every participating OSS developer, including contribution statistics, political correctness on the tracker, age estimate from pictures and so forth. Before GitHub, all this information *could* have been gathered on any individual, but at a far greater cost in time and effort. If GitHub turns evil, it will be most likely by selling this nicely packaged information to recruiters. It's too late to move away then, the statistics will have been collected already. Quite honestly, I'd feel like working for Andreessen & Horowitz for free if we move there. Stefan Krah From brett at snarky.ca Fri Nov 27 12:13:49 2015 From: brett at snarky.ca (Brett Cannon) Date: Fri, 27 Nov 2015 17:13:49 +0000 Subject: [core-workflow] Software Factory In-Reply-To: References: Message-ID: On Thu, 26 Nov 2015 at 14:12 Stefan Krah wrote: > > [Posting via gmane, followup seems to be broken.] > > > [Nick] > > From a purely pragmatic perspective though, "Import from GitHub" is > > already one of the features offered by GitLab, and will no doubt be a > > standard feature of any other open source repository management > > systems that gains widespread popularity in the future. Donald also > > noted a while back that this is a reasonable lesson to take away from > > the Linux kernel Bitkeeper experiment - they used the proprietary > > service for as long as the vendor was playing nice, and when the > > relationship soured, they migrated away again. > > I think this is different from BitKeeper: GitHub has a dossier on every > participating OSS developer, including contribution statistics, political > correctness on the tracker, age estimate from pictures and so forth. > > Before GitHub, all this information *could* have been gathered on > any individual, but at a far greater cost in time and effort. > > If GitHub turns evil, it will be most likely by selling this > nicely packaged information to recruiters. It's too late to move > away then, the statistics will have been collected already. > Do their terms of service even allow for that, or is this just speculation on your part? -Brett > > > Quite honestly, I'd feel like working for Andreessen & Horowitz for free > if we move there. > > > > Stefan Krah > > > _______________________________________________ > 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 skrah.temporarily at gmail.com Sat Nov 28 13:34:49 2015 From: skrah.temporarily at gmail.com (Stefan Krah) Date: Sat, 28 Nov 2015 18:34:49 +0000 (UTC) Subject: [core-workflow] Software Factory Message-ID: [Brett] >> If GitHub turns evil, it will be most likely by selling this >> nicely packaged information to recruiters. It's too late to move >> away then, the statistics will have been collected already. > Do their terms of service even allow for that, or is this just speculation on your part? When exploring a worst case scenario, some level of speculation is probably inevitable. The guideline "if a service is free, you are the product" is pretty well established -- I cannot think of an example where it has actually been refuted. I do not know whether explicit permission to resell data that is technically public is required in the U.S. Note that while the data is "public", data mining GitHub by third parties seems to be forbidden. GitHub's TOS appear to be entirely silent on the subject, but they are already publishing aggregate data like https://github.com/torvalds , which by my (European) privacy point of view is already stretching and exceeding the limits of good taste. Stefan Krah From skrah.temporarily at gmail.com Sat Nov 28 14:22:30 2015 From: skrah.temporarily at gmail.com (Stefan Krah) Date: Sat, 28 Nov 2015 19:22:30 +0000 (UTC) Subject: [core-workflow] Other thoughts on the workflow Message-ID: Brett has asked for feedback until Dec 1st, so here are my quick random thoughts: 1) GitHub's UI is more polished than GitLab's. 2) GitHub pull requests are not universally liked (see famous Torvalds rant "... pull requests and the online commit editing, are just pure ..."). 3) Attracting contributors? This was also an argument for the svn -> hg change, but it did not happen IMO. On the contrary, patches like https://bugs.python.org/issue3526 seem to be more rare. 4) Personally, I probably would not have contributed to Python if a GitHub account had been required back in 2012. But the time may come when one is excluded entirely from any Open Source contributions without a GitHub account... 5) The "do-nothing" option hasn't been mentioned: The current setup is actually quite nice compared to almost 99% of other projects. I like it better than both GitHub/GitLab. Stefan Krah From brett at python.org Sun Nov 29 12:05:52 2015 From: brett at python.org (Brett Cannon) Date: Sun, 29 Nov 2015 17:05:52 +0000 Subject: [core-workflow] Software Factory In-Reply-To: References: Message-ID: On Sat, 28 Nov 2015 at 11:35 Stefan Krah wrote: > > [Brett] > > >> If GitHub turns evil, it will be most likely by selling this > >> nicely packaged information to recruiters. It's too late to move > >> away then, the statistics will have been collected already. > > > Do their terms of service even allow for that, or is this just > speculation > on your part? > > > When exploring a worst case scenario, some level of speculation is > probably inevitable. The guideline "if a service is free, you are > the product" is pretty well established -- I cannot think of an > example where it has actually been refuted. > But the service is free to open source only. GitHub makes all of their money from private hosting services to large companies. So it's a freemium model of "try our service out for free as long as you make your code public, and if you like it and want to use it at work then pay us". So I don't view this as the same model that Google et. al. uses where you are the product to advertisers, but more like mobile games where people are trying to entice you to buy "upgrades". > > I do not know whether explicit permission to resell data that is > technically public is required in the U.S. Note that while the > data is "public", data mining GitHub by third parties seems to > be forbidden. > > > GitHub's TOS appear to be entirely silent on the subject, but they > are already publishing aggregate data like > > https://github.com/torvalds , > I believe you have to make your profile public for that to be viewable. -Brett > > > which by my (European) privacy point of view is already stretching > and exceeding the limits of good taste. > > > > Stefan Krah > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > 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 brett at python.org Sun Nov 29 12:12:45 2015 From: brett at python.org (Brett Cannon) Date: Sun, 29 Nov 2015 17:12:45 +0000 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: Thanks for the feedback. And the "do nothing" option is there, although it's so disliked by so many people that the chances of us not changing our workflow is pretty slim. On Sat, 28 Nov 2015 at 12:22 Stefan Krah wrote: > > Brett has asked for feedback until Dec 1st, so here are my > quick random thoughts: > > 1) GitHub's UI is more polished than GitLab's. > > 2) GitHub pull requests are not universally liked (see famous Torvalds > rant "... pull requests and the online commit editing, are just > pure ..."). > > 3) Attracting contributors? This was also an argument for the > svn -> hg change, but it did not happen IMO. On the contrary, > patches like https://bugs.python.org/issue3526 seem to be more > rare. > > 4) Personally, I probably would not have contributed to Python > if a GitHub account had been required back in 2012. But the > time may come when one is excluded entirely from any Open Source > contributions without a GitHub account... > > 5) The "do-nothing" option hasn't been mentioned: The current setup > is actually quite nice compared to almost 99% of other projects. > I like it better than both GitHub/GitLab. > > > > Stefan Krah > > > > > > _______________________________________________ > 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 ncoghlan at gmail.com Sun Nov 29 22:54:45 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 30 Nov 2015 13:54:45 +1000 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: On 30 November 2015 at 03:12, Brett Cannon wrote: > Thanks for the feedback. And the "do nothing" option is there, although it's > so disliked by so many people that the chances of us not changing our > workflow is pretty slim. The interests of folks that prefer the terminal focused "commit-locally-and-push" workflow can still be taken into account in the evaluation though - while it appears likely either GitHub or GitLab will be adopted as the repository management service, whether or not the maintenance branches and the default branch are marked as protected so even core developers *have* to go through the web based merge process is a separate question. There are also tools like git-pulls (Ruby: https://github.com/schacon/git-pulls) and hub (Go: https://hub.github.com/) that let folks review and merge GitHub PRs from the terminal. (I had a quick look through some of the command line clients listed at https://about.gitlab.com/applications/, but didn't see anything as workflow focused as git-pulls or hub, so "good support for terminal based usage" may count as a concrete technical differentiator here) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From guido at python.org Sun Nov 29 23:08:02 2015 From: guido at python.org (Guido van Rossum) Date: Sun, 29 Nov 2015 20:08:02 -0800 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan wrote: > On 30 November 2015 at 03:12, Brett Cannon wrote: > > Thanks for the feedback. And the "do nothing" option is there, although > it's > > so disliked by so many people that the chances of us not changing our > > workflow is pretty slim. > > The interests of folks that prefer the terminal focused > "commit-locally-and-push" workflow can still be taken into account in > the evaluation though - while it appears likely either GitHub or > GitLab will be adopted as the repository management service, whether > or not the maintenance branches and the default branch are marked as > protected so even core developers *have* to go through the web based > merge process is a separate question. > What?! I've never worked with a GitHub-based project where you *had* to use the web-based merge process. Hopefully that's not really on the table. In fact I'm not a big fan of GitHub's web-based merge process at all -- I much prefer seeing a simple linear history in the master (and I don't like preserving intermediate commits made during the PR review process). > There are also tools like git-pulls (Ruby: > https://github.com/schacon/git-pulls) and hub (Go: > https://hub.github.com/) that let folks review and merge GitHub PRs > from the terminal. (I had a quick look through some of the command > line clients listed at https://about.gitlab.com/applications/, but > didn't see anything as workflow focused as git-pulls or hub, so "good > support for terminal based usage" may count as a concrete technical > differentiator here) > Review and merge process should be separable. After 10+ years of using web-based review tools I personally wouldn't dream of using a terminal-based *review* (as opposed to merge) process. Though of course if that's your preference you should be able to do it. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Sun Nov 29 23:31:27 2015 From: donald at stufft.io (Donald Stufft) Date: Sun, 29 Nov 2015 23:31:27 -0500 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: > On Nov 29, 2015, at 11:08 PM, Guido van Rossum wrote: > > On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan > wrote: > On 30 November 2015 at 03:12, Brett Cannon > wrote: > > Thanks for the feedback. And the "do nothing" option is there, although it's > > so disliked by so many people that the chances of us not changing our > > workflow is pretty slim. > > The interests of folks that prefer the terminal focused > "commit-locally-and-push" workflow can still be taken into account in > the evaluation though - while it appears likely either GitHub or > GitLab will be adopted as the repository management service, whether > or not the maintenance branches and the default branch are marked as > protected so even core developers *have* to go through the web based > merge process is a separate question. > > What?! I've never worked with a GitHub-based project where you *had* to use the web-based merge process. Hopefully that's not really on the table. In fact I'm not a big fan of GitHub's web-based merge process at all -- I much prefer seeing a simple linear history in the master (and I don't like preserving intermediate commits made during the PR review process). I don?t believe Github even has an option where you *have* to use the web-based merge process. The closest thing they have is protected branches (disables force pushes, but not regular pushes) and required status checks (PRs have to pass certain pre merge tests before the merge button lights up). Maybe the required status checks disables pushes all together but I don?t think it does and even if it did that feature (as currently implemented anyways) doesn?t make sense for us because it essentially requires all PRs to get rebased or have master merged into them before they can be merged via the merge button which is a massive pain for OSS teams of any size or velocity. > > There are also tools like git-pulls (Ruby: > https://github.com/schacon/git-pulls ) and hub (Go: > https://hub.github.com/ ) that let folks review and merge GitHub PRs > from the terminal. (I had a quick look through some of the command > line clients listed at https://about.gitlab.com/applications/ , but > didn't see anything as workflow focused as git-pulls or hub, so "good > support for terminal based usage" may count as a concrete technical > differentiator here) > > Review and merge process should be separable. After 10+ years of using web-based review tools I personally wouldn't dream of using a terminal-based *review* (as opposed to merge) process. Though of course if that's your preference you should be able to do it. > I don?t know about Gitlab, but GitHub exposes PRs as heads in the remote repository. You have to add a single line to your .git/config in that repository, but once you do they are available to use any regular git command against (check them out, diff them, whatever). Doing that won?t get the comments on the PR and the pre merge test status and such of course, but someone can merge a PR just by doing (if configured): $ git merge upstream/pr/XXXX Here?s my configuration for the pip repository on GitHub that is configured in this way: https://bpaste.net/show/77b17a2571f0 Line #14 is the important part. This also makes my local master and develop branch track the upstream repository, while my own branches get pushed to my fork which is the origin remote. ----------------- 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 Sun Nov 29 23:54:06 2015 From: brett at python.org (Brett Cannon) Date: Mon, 30 Nov 2015 04:54:06 +0000 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: On Sun, 29 Nov 2015 at 21:08 Guido van Rossum wrote: > On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan wrote: > >> On 30 November 2015 at 03:12, Brett Cannon wrote: >> > Thanks for the feedback. And the "do nothing" option is there, although >> it's >> > so disliked by so many people that the chances of us not changing our >> > workflow is pretty slim. >> >> The interests of folks that prefer the terminal focused >> "commit-locally-and-push" workflow can still be taken into account in >> the evaluation though - while it appears likely either GitHub or >> GitLab will be adopted as the repository management service, whether >> or not the maintenance branches and the default branch are marked as >> protected so even core developers *have* to go through the web based >> merge process is a separate question. >> > > What?! I've never worked with a GitHub-based project where you *had* to > use the web-based merge process. Hopefully that's not really on the table. > In fact I'm not a big fan of GitHub's web-based merge process at all -- I > much prefer seeing a simple linear history in the master (and I don't like > preserving intermediate commits made during the PR review process). > Donald addressed the protected branch bits, but the web-based PR merging will be discussed as a possible allowed workflow. It doesn't have to be settled now but just so you know my position, I like the web-based merging as it means I don't have to worry about being on a machine with a repo and SSH keys in order to do a merge (e.g., I could do a merge from my Chromebook while on vacation or at work on my lunch break without issue). I also don't mind the intermediate merges as it gives contributors proper attribution for their work (you can use I believe `git log --merges` to only see git merge logs which would be written by core devs). -Brett > > >> There are also tools like git-pulls (Ruby: >> https://github.com/schacon/git-pulls) and hub (Go: >> https://hub.github.com/) that let folks review and merge GitHub PRs >> from the terminal. (I had a quick look through some of the command >> line clients listed at https://about.gitlab.com/applications/, but >> didn't see anything as workflow focused as git-pulls or hub, so "good >> support for terminal based usage" may count as a concrete technical >> differentiator here) >> > > Review and merge process should be separable. After 10+ years of using > web-based review tools I personally wouldn't dream of using a > terminal-based *review* (as opposed to merge) process. Though of course if > that's your preference you should be able to do it. > > > -- > --Guido van Rossum (python.org/~guido) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Mon Nov 30 00:19:27 2015 From: guido at python.org (Guido van Rossum) Date: Sun, 29 Nov 2015 21:19:27 -0800 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: When I said intermediate merges, I meant additional detail like "fix typos and remove dead code" in this PR to asyncio: https://github.com/python/asyncio/pull/290/commits . And I don't like to see merge turds like these in my history (we've experimented with this a bunch in the asyncio repo): * b516e80 Merge pull request #231 from haypo/issue_222 |\ | * b08ee40 Fix @coroutine for functions without __name__ * | cd10ff2 Merge pull request #237 from ajdavis/update-queue-join-tests |\ \ | * | 70d8856 Fix queue join tests for CPython's test runner. |/ / * | bcb7ec4 Merge pull request #236 from ajdavis/queue-join-fix |\ \ | * | e496c7c Fix LifoQueue's and PriorityQueue's put() and task_done(). | * | a943b49 Test LifoQueue's and PriorityQueue's put() and task_done(). |/ / * | 7718675 #230: Change official URL from tulip to asyncio in README.rst |/ * 173ff86 Update README.rst * 4f9099e Merge pull request #225 from Eyepea/add_pycharm_in_gitignore |\ | * 30f4788 add in .gitignore pyvenv and Pycharm files |/ * 3582e11 Merge pull request #224 from Eyepea/readme_improvement |\ | * bf4b2ce Rename README file to have rst render on Github * | 1888b1d Switch hgignore and hgeol to git equivalents |/ But of course I would love a web-based merge flow that doesn't create such turds! (It must be possible, since I can do it manually. :-) Also, AFAIK git keeps separate track of who authored a change and who committed it, so credit to contributors should still be maintainable. On Sun, Nov 29, 2015 at 8:54 PM, Brett Cannon wrote: > > > On Sun, 29 Nov 2015 at 21:08 Guido van Rossum wrote: > >> On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan wrote: >> >>> On 30 November 2015 at 03:12, Brett Cannon wrote: >>> > Thanks for the feedback. And the "do nothing" option is there, >>> although it's >>> > so disliked by so many people that the chances of us not changing our >>> > workflow is pretty slim. >>> >>> The interests of folks that prefer the terminal focused >>> "commit-locally-and-push" workflow can still be taken into account in >>> the evaluation though - while it appears likely either GitHub or >>> GitLab will be adopted as the repository management service, whether >>> or not the maintenance branches and the default branch are marked as >>> protected so even core developers *have* to go through the web based >>> merge process is a separate question. >>> >> >> What?! I've never worked with a GitHub-based project where you *had* to >> use the web-based merge process. Hopefully that's not really on the table. >> In fact I'm not a big fan of GitHub's web-based merge process at all -- I >> much prefer seeing a simple linear history in the master (and I don't like >> preserving intermediate commits made during the PR review process). >> > > Donald addressed the protected branch bits, but the web-based PR merging > will be discussed as a possible allowed workflow. It doesn't have to be > settled now but just so you know my position, I like the web-based merging > as it means I don't have to worry about being on a machine with a repo and > SSH keys in order to do a merge (e.g., I could do a merge from my > Chromebook while on vacation or at work on my lunch break without issue). I > also don't mind the intermediate merges as it gives contributors proper > attribution for their work (you can use I believe `git log --merges` to > only see git merge logs which would be written by core devs). > > -Brett > > >> >> >>> There are also tools like git-pulls (Ruby: >>> https://github.com/schacon/git-pulls) and hub (Go: >>> https://hub.github.com/) that let folks review and merge GitHub PRs >>> from the terminal. (I had a quick look through some of the command >>> line clients listed at https://about.gitlab.com/applications/, but >>> didn't see anything as workflow focused as git-pulls or hub, so "good >>> support for terminal based usage" may count as a concrete technical >>> differentiator here) >>> >> >> Review and merge process should be separable. After 10+ years of using >> web-based review tools I personally wouldn't dream of using a >> terminal-based *review* (as opposed to merge) process. Though of course if >> that's your preference you should be able to do it. >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Mon Nov 30 01:02:38 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 30 Nov 2015 16:02:38 +1000 Subject: [core-workflow] Other thoughts on the workflow In-Reply-To: References: Message-ID: On 30 November 2015 at 14:31, Donald Stufft wrote: > I don?t believe Github even has an option where you *have* to use the > web-based merge process. The closest thing they have is protected branches > (disables force pushes, but not regular pushes) and required status checks > (PRs have to pass certain pre merge tests before the merge button lights > up). You're right, I was thinking of the GitLab variant of protected branches, where you can turn off pushing entirely for folks with Developer permissions in order to require that all changes go through the review process: http://doc.gitlab.com/ce/workflow/protected_branches.html Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From barry at python.org Mon Nov 30 21:44:31 2015 From: barry at python.org (Barry Warsaw) Date: Mon, 30 Nov 2015 21:44:31 -0500 Subject: [core-workflow] Other thoughts on the workflow References: Message-ID: <20151130214431.15f98083@anarchist.wooz.org> On Nov 29, 2015, at 08:08 PM, Guido van Rossum wrote: >What?! I've never worked with a GitHub-based project where you *had* to use >the web-based merge process. All GitLab merge requests have a button that pops up the commands you can copy and paste into your terminal to do a local, manual merge. There are several reasons why I'll do it that way: * I might want to clean up the branch a little bit and not bog the submitter down with style nits or whitespace issues. * I might have to add a NEWS entry. * I might want want run the test suite with a fix not applied, just to prove that the test actually exposes the problem. * I might want to manually rebase all those commits for cleaner history or easier cherry-picking to stable branches. OTOH, when something looks pretty clean, I'll just hit the auto-merge button, perhaps telling it to rebase first. I don't think there's anything special about GitLab here. Either GitHub has something similar, or it's just as easy to do via command line git if you can remember the incantations. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From barry at python.org Mon Nov 30 21:48:55 2015 From: barry at python.org (Barry Warsaw) Date: Mon, 30 Nov 2015 21:48:55 -0500 Subject: [core-workflow] Other thoughts on the workflow References: Message-ID: <20151130214855.534f30e8@anarchist.wooz.org> On Nov 29, 2015, at 11:31 PM, Donald Stufft wrote: >I don?t know about Gitlab, but GitHub exposes PRs as heads in the remote >repository. Yes, GitLab has essentially the same thing. I personally recommend fetching the merge request branch, and then switching to it locally via some name, e.g. $ git fetch https://gitlab.com/person/mailman.git branch-to-merge $ git checkout -b person/27 FETCH_HEAD Now I clean up the person/27 branch, maybe make more comments, rebase, etc. Once I'm happy with the branch, it's simple to $ git co master $ git merge person/27 $ git push I generally let it fast-forward merge if possible (which it usually is if I rebase). Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From barry at python.org Mon Nov 30 21:51:54 2015 From: barry at python.org (Barry Warsaw) Date: Mon, 30 Nov 2015 21:51:54 -0500 Subject: [core-workflow] Other thoughts on the workflow References: Message-ID: <20151130215154.1a13df42@anarchist.wooz.org> On Nov 29, 2015, at 09:19 PM, Guido van Rossum wrote: >But of course I would love a web-based merge flow that doesn't create such >turds! (It must be possible, since I can do it manually. :-) `git rebase -i` is a great tool (especially nice with Emacs :) so I usually fixup or squash those little clean ups I do to someone else's merge proposal. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: