Mailman 3 December 2015 - core-workflow

Longer term idea: consider Rust's homu for CPython merge gating
by Nick Coghlan 04 Jan '16

04 Jan '16

(Note: near term, this probably isn't a useful idea, as the current GitHub & GitLab proposals aren't proposing the introduction of merge gating, merely advisory testing of PRs, so folks will remain free to merge patches locally and push them up to the master repository. However, I think pre-merge testing is a good idea long term, with approving our own PRs taking the place of pushing directly to the development and maintenance branches) I recently came across an old article [1] by Rust's Graydon Hoare regarding their approach to pre-merge testing of commits using GitHub PRs and Buildbot. Following up on that brought me to a more up to date explanation of their current bot setup [2], and the http://homu.io/ service for running it against a project without hosting your own instance (in our case, if we did run a service like Homu, we'd likely still want to host our own instance, as Mozilla do for Rust and Servo). Similar to OpenStack's Zuul, Homu serialises commits, ensuring that the test suite is passing *before* code lands on the target branch. The relevant differences are that Homu is designed to use GitHub PRs rather than Gerrit reviews as the event source, and Travis CI and Buildbot rather than Jenkins as the CI backends for actually running the integration tests. (Homu is also currently missing Zuul's "speculative test pipeline" feature, which allows it to test multiple commits in parallel on the assumption that most of them will pass due to prior testing in isolation, but has a separate feature that allows PRs to be tagged for inclusion in "rollup" commits that land several changes at once after testing them as a group) The current merge queue for Rust itself can be seen at http://buildbot.rust-lang.org/homu/queue/rust Regards, Nick. [1] http://graydon2.dreamwidth.org/1597.html [2] http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrast… -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 7

Software Factory
by Stefan Krah 31 Dec '15

31 Dec '15

[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

4 7

workflow proposal update: Xmas week edition
by Brett Cannon 21 Dec '15

21 Dec '15

Just wanted to sum up where I think everything stands as we approach January 1. First, everyone seems to like the bot idea for managing pull requests. It should buy us easier cherry-picking across branches as well as fast-forward/rebasing PRs so we get a linear history. And all of this done through the browser. It can also help automate things such as Misc/NEWS and Misc/ACKS. Plus it buys us workflow independence from our hosting platform since the bot will be what needs changing if we change hosts in the future and not how our overall workflow works. Wins for everyone! It also won't be a blocker on switching since everything being proposed can be done manually. And I will be pushing for a Monty Python and the Holy Grail black knight reference for the bot's name and trigger command (black-knight or none-shall-pass are tied in my head). Second, my email asking if anyone would walk away from contributing to Python if we switched to GitHub resulted in *no one* stepping forward. I actually got an equal number of "I'd prefer not to use GitHub, but I won't stop contributing" compared to "please choose GitHub" emails. And in the end there were more emails wanting clarification on the intended tone of the email than on the topic itself. So switching to GitHub won't impede development due to its closed source nature. Third, Guido asked what GitLab offers over GitHub to win over the network and familiarity effect that GitHub offers. I don't remember a direct reply to that email yet so if there is something to be pointed out beyond GitLab's open source nature or ability for us to host our own instance if something were to happen to GitLab then please let it be known. I think that's everything up to this point. I'm still hoping we can figure out all the hosting issues before January 1 so I can make a decision by then.

1 0

PEP 481 repo URL branding
by Barry Warsaw 16 Dec '15

16 Dec '15

This isn't described in PEP 481. I think this was briefly mentioned in a previous message, but I can't find it so I'm starting a new thread. If PEP 481 is accepted, will we be getting a GitHub enterprise instance that we can run on git{,hub}.python.org, or will we just use github.com/python/cpython? (FTR, the intent of PEP 507 is that we would be getting a GitLab EE or CE instance running on git{,lab}.python.org). Cheers, -Barry

5 6

Questions about the proposed workflows
by Brett Cannon 16 Dec '15

16 Dec '15

It's Dec 1, which means it's time for any questions people have about the proposed workflows so we can get answers by Dec 15. I have one question that applies to both proposals and one specific to GitLab. The general one is whether both Guido and me can both be happy. :) Guido doesn't want intermediate commits nor what he calls "merge turds" to show up in the history. I want to be able to do merges from the browser. Do either GitHub or GitLab provide a way through the web UI to give Guido what he wants, or will it always require having a checkout and SSH keys set up in order to do a PR merge? If only Guido can be made happy then that means either proposal becomes an easy way for people to get code hosting for their forks and a review tool but not a PR management platform since merges would occur outside the website and merges would simply be a `git push` which is basically what we do now to do the final merge for a patch. The GitLab-specific question is what, if anything, is GitLab prepared to offer us? Both Nick and Barry have hinted that GitLab would host us, listen to our needs, etc., but it has always seemed to be speculation. Do we have concrete information as to what GitLab is willing to do for us?

9 49

Questions for GitHub's Director of Community
by Barry Warsaw 15 Dec '15

15 Dec '15

Over on the committers mailing list, I mentioned that Jono Bacon, a former colleague of mine and former Ubuntu Community Manager is now Director of Community at GitHub. If you have specific questions about GitHub that you think Jono can answer in his official capacity, please send them to me directly, off-list in the next few days. I'll compile them and forward them on. Cheers, -Barry

1 0

Questions about the core workflow
by Stefan Krah 14 Dec '15

14 Dec '15

[Nick] > I honestly don't know how the different areas of concern break down across the core contributor base, and I've seen enough demands for free software and privacy advocates to "stop being unreasonable" in various contexts to suspect that an anonymous survey (that is still somehow restricted to core developers) would be the only way to get an even halfway accurate assessment. I fully agree. Since 5 years or so stating any kind of opinion that remotely resembles the original free software principles (by that I don't mean necessarily Stallman's views, just a basic desire for decency, privacy, and a free and open atmosphere) is shouted down vigorously. Here, we are still fortunate enough to have people like you who at least tried the open Kallithea approach! [For the record, I'll need a work related GitHub account from next year on. I'll probably give up and move my private projects there, too, because honestly I'm tired of constantly defending minority opinions.] Stefan Krah

3 2

Re: [core-workflow] Questions about the proposed workflows
by Barry Warsaw 13 Dec '15

13 Dec '15

On Dec 12, 2015, at 09:52 AM, Guido van Rossum wrote: >Honestly, to cut things short, I think we should go with GitHub and pay >them for enterprise support, if they'll take our money. This sounds like a pronouncement. I really don't mean this to sound snarky, but let's not waste Brett's time, my time, and the GitLab CEO's time if PEP 507 doesn't have a realistic chance of being accepted. Cheers, -Barry

3 3

Questions about the proposed workflow
by Stefan Krah 13 Dec '15

13 Dec '15

[D. Stufft] > It seems pretty hypocritical to be against GitHub because it's proprietary and hosted by a company that can sell your data (both things I've seen people say against GitHub) and be pro GitLab EE [...] Only in the abstract. GitHub has an reported investment of 350.000.000, while GitLab only has a very small fraction of that. If selling private repos doesn't justify that kind of money, it's pretty clear what will happen! To be fair, GitLab also has a rudimentary version of the annoying per-developer statistics. I'm also not claiming that GitHub already has a secret business plan to turn evil -- development there seems to be a bit ad hoc, meandering and informal. The point is that they may *have* to turn evil, because the private repo market simply isn't big enough. Lastly, GitHub is to my knowledge the only one of RhodeCode, GitLab, etc. that had at least one absolutely glaring own-the-world (write access to all repos) security hole. Stefan Krah

3 2

Questions about the core workflow
by Stefan Krah 13 Dec '15

13 Dec '15

[Guido] > On Sat, Dec 12, 2015 at 10:36 AM, Stefan Krah <skrah.temporarily <at> gmail.com> wrote: >> Since 5 years or so stating any kind of opinion that >> remotely resembles the original free software principles (by that I >> don't mean necessarily Stallman's views, just a basic desire for >> decency, privacy, and a free and open atmosphere) is shouted down >> vigorously. > Who is shouting you down here? Sorry if I wasn't clear: I thought that Nick's paragraph was about *general* tendencies in open-source land that might necessitate an anonymous survey in order to get an accurate assessment of developer's opinions. I fully agree that *here* there was no shouting-down. > We listen, but AFAICT few agree. Are you sure? I got the impression that at least Nick, Barry and myself would favor GitLab. And there seem to be six active people in this discussion. Stefan Krah

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

core-workflow December 2015