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
On Nov 23, 2015, at 4:20 AM, Victor Stinner <victor.stinner@gmail.com> 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@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
2015-11-23 13:42 GMT+01:00 Donald Stufft <donald@stufft.io>:
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
On Nov 23, 2015, at 7:50 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2015-11-23 13:42 GMT+01:00 Donald Stufft <donald@stufft.io>:
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
On 23 November 2015 at 23:01, Donald Stufft <donald@stufft.io> wrote:
On Nov 23, 2015, at 7:50 AM, Victor Stinner <victor.stinner@gmail.com> 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@gmail.com | Brisbane, Australia
On Mon, Nov 23, 2015 at 7:01 AM, Donald Stufft <donald@stufft.io> 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.
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_sb... , 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 <brian@python.org> wrote:
Openstack is a bit different because almost every contributor is being
On Mon, Nov 23, 2015 at 7:01 AM, Donald Stufft <donald@stufft.io> wrote: 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@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
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 <brett@snarky.ca> 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_sb... , 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 <brian@python.org> wrote:
On Mon, Nov 23, 2015 at 7:01 AM, Donald Stufft <donald@stufft.io> 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@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@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)
On 25 November 2015 at 04:30, Guido van Rossum <guido@python.org> wrote:
Both seem to have commercial interest into locking users in;
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
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. 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@gmail.com | Brisbane, Australia
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
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 <barry@python.org> 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@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
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
On 24 November 2015 at 03:22, Barry Warsaw <barry@python.org> 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@gmail.com | Brisbane, Australia
On Nov 23, 2015, at 4:20 AM, Victor Stinner <victor.stinner@gmail.com> 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
participants (7)
-
Barry Warsaw -
Brett Cannon -
Brian Curtin -
Donald Stufft -
Guido van Rossum -
Nick Coghlan -
Victor Stinner