LWN: Comments on "New CPython workflow issues"

New CPython workflow issues

mathstuf — Thu, 06 Jul 2017 03:24:53 +0000

What's wrong with GitHub's review in your view? I prefer parts from each (I wish GitHub had resolvable subthreads and Gitlab had batch code comments), but prefer Gitlab overall. I do review much more code with Gitlab though, so maybe it's just a difference in scale.

New CPython workflow issues

dag- — Mon, 29 May 2017 19:29:52 +0000

This may all be true, and once GitHub had no real competition in this area. But GitLab is now feature-complete and exceeds GitHub in many aspects. My remark related to convenience was more about what people already know (mindshare) rather than real convenience, as in "efficiency".

And having used both extensively, GitHub in the community and GitLab at various companies. There is a clear benefit to work with an Open Source project (to which one can troubleshoot and contribute) over a hosted service offering (with weird incomplete workflows and suboptimal implementations).

I am not saying GitLab is perfect, but at least everything that's bothering you that much, you can dive in and fix it yourself. (Which I also did a few times) I would even say that some of the stuff that people now do in bots should move back into GitLab workflows when the time is right and there's general consensus. With GitHub we have been waiting for years for something to be fixed, or some feature to appear (like issue/PR templates). GitHub's review workflow is completely broken by design...

New CPython workflow issues

darwish — Mon, 29 May 2017 19:15:01 +0000

Entire businesses are earning billions because they are more friendly and streamlined than their competitors (iOS and iPhones come to mind).

I understand the argument from a code freedom perspective, but if sacrificing some freedom will make the submission experience frictionless for contributions, I'm all for it.

This is even more important in a community like Python, where ease of use, and contributors outside of the traditional FOSS/Linux culture are included. It's ironic that github, the proprietary service, has democratized open source contributions beyond the isolated culture of submitting patches by clear-text mail or as attachments in bugzilla.

These "contributor experience" things may be small for us, engineers experienced in contributing to classical projects like the kernel or the rest of the plumbing layer (minus systemd, which also uses github in full). Nonetheless I've witnessed it with my own eyes how github significantly eases the contribution barrier for the younger generation.

New CPython workflow issues

dag- — Mon, 29 May 2017 08:08:38 +0000

Reading back on the decision to use GitHub over GitLab, I am surprised that convenience (familiarity) was considered more important than Open Source tooling. The advantage to using Open Source tooling is that specific functionality/requirements in the tooling can be contributed by the larger community (including the Python community), whereas with GitHub you depend for new functionality or integration on an external party with different objectives.

New CPython workflow issues

pdmccormick — Fri, 26 May 2017 00:24:24 +0000

I love that Brett frequently wears a PyCon Canada T-shirt for public events. Thanks Brett!

New CPython workflow issues

mathstuf — Thu, 25 May 2017 17:55:49 +0000

While that works if you use a built-in merge driver, an external one means that you need some kind of setup script to initialize the configuration and driver itself before you can actually resolve conflicts in the file. Plus, doing the split release note files makes it easier to backport since it just drops a file rather than having to disentangle the surrounding notes from the master branch.

New CPython workflow issues

jnareb — Thu, 25 May 2017 15:22:55 +0000

> As for the maintenance of the `NEWS` file, collecting from a lot of files has been way better than trying to keep a single file out of numerous conflicts (CMake and Gitlab use this for their release notes).

Another way of solving the problem if conflicts in NEWS or ChangeLog file is to use special file-level merge driver that knows the structure of the file, which would automatically merge NEWS file entries, without conflicts. There is one for GNU ChangeLog; I think there is one for NEWS file, and if not it would be easy to write.

New CPython workflow issues

mathstuf — Thu, 25 May 2017 10:20:47 +0000

As a maintainer, I don't mind having merge requests open for testing purposes as long as they are clearly marked as such. It makes things coming down the pipe more visible for other contributors to look at, you can catch egregious problems before too much time is spent going down the wrong road, and you typically have zero access on forks to install webhooks or even send a commit status result. Granted, before embarking on large projects, communication should be done, but there's no fundamental reason that WIP or RFC topics should be forced to go elsewhere. Unless you have a dedicated RFC process already (PEP for Python or the RFC repo style used by Rust).

I know Gitlab-CI can be configured to build on pushes to forks, but if your testing doesn't fit into that paradigm, you're kind of stuck.

New CPython workflow issues

smurf — Thu, 25 May 2017 06:05:33 +0000

> code has to be pushed for the automated tests to run

So add a way to tell the checker to run on your feature branch in your forked repository, instead of relying on merge requests.

New CPython workflow issues

mathstuf — Wed, 24 May 2017 19:14:46 +0000

I've been thinking about handling backportable topics for the workflows I'm involved with as well. The easiest way I've been able to think of is to have something in the description of the PR (it's parsed as a Git trailer for those familiar):

Topic-backport: for-3.8

Now, this requires a bot to also handle the merging of PRs (no button!) to do the backport itself. For topics where merge conflicts occur or the fix is slightly different, you make a branch off of each release it is intended to go into and merge them all together into the one headed for master (using `-s ours` for the backport branches) and submit that for a PR. Then your backport can look like:

Topic-backport: for-3.8:HEAD^2

using the `:refname` syntax to indicate which commit from the HEAD of the topic is meant to be backported. This keeps all of the commits for a single change limited to a single PR rather than spread out across numerous ones. Github review doesn't make it easy to see the diff for those backport commits, but posting URLs for viewing the diff should aleviate that (though comments there are sort of out in the aether :/ ).

As for the maintenance of the `NEWS` file, collecting from a lot of files has been way better than trying to keep a single file out of numerous conflicts (CMake and Gitlab use this for their release notes).

For stale PRs, I like having an "expired" label that gets added when closing so that you know it was closed due to inactivity, not rejected. A comment describing that reopening the PR when work continues helps as well.