Pulling GitHub into the kernel process

Posted Jun 24, 2021 5:54 UTC (Thu) by laf0rge (subscriber, #6469)
In reply to: Pulling GitHub into the kernel process by mathstuf
Parent article: Pulling GitHub into the kernel process

I see a distinct lack of the non-free (as in FOSS) nature of github in this discussion, or at least the coverage here.

Whether or not to integrate a web based platform into the development process is one question, and there are many pro's and con's.

However, whether or not to rely on third-party, non-free SaaS is an entirely different question. I for myself am quite happy that the bitkeeper days are long over, and I wouldn't want to see a return of them.

So, IMHO, if at all one wants related integration with a web based "pull request" type tool, the discussion should be whether or not to integrate with a [potentially self-hosted] FOSS gitlab instance, or gitea, or whatever else might be out there.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 6:55 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

In fairness, I don't see anything in the article suggesting that anyone is going to "rely" on GitHub. It sounds more like it's going to become an additional option for contributing.

If it became *the sole* option for contributing, that would obviously be a problem. But I can see nothing* wrong with adding many integrations for many different forges, and letting developers use what they want to use. If anything, that should reduce the risk** of having a single point of failure.

* True, someone has to maintain the integrations. But presumably, if an integration is not being maintained, then nobody finds it useful enough to bother, and it can be allowed to die in peace. This is a problem that solves itself.
** This risk is somewhat applicable to email, too. It is getting progressively harder and harder to turn up your own private SMTP server, in such a way that the big email providers are willing to exchange messages with it. I don't think email is going to die tomorrow, or in the current decade, but it's something to think about in the long run.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 7:30 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

> If it became *the sole* option for contributing, that would obviously be a problem.

I'd go further than that. Back in the Bitkeeper days, people who were unwilling or unable to accept the Bitkeeper license could still make use of the CVS gateway, so it was never the sole option - but I think it was pretty clear that you were at a significant disadvantage by not relying on proprietary local tooling. I'm enthusiastic about making it more straightforward to use Github as a mechanism to get involved in kernel development, but I think there would need to be pushback against it being the *primary* option, not merely against it being the sole option.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 13:22 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

I'm not seeing anything about "move the Linux contribution workflow to GitHub". It's more "make GitHub a viable onramp to contributing". Everything still ends up on the ML, but maybe there'd be a single place to find out about the entire history of a change. Review comments, change over time, the status of its journey to Linus' tree, etc.

For example, I fixed a bug that was reported by some automated test setup. I used the same set of Cc emails and sent it off. However, it was missing the list that needed to hear about the patch. It wasn't until I pinged after a week of silence that this had been realized. Why did it miss the target list? I don't know, but checkpatch and whatever hooks `send-email` has didn't figure it out (and there were a dozen+ emails already, so spotting a missing one wasn't easy).

So this isn't about going anywhere near what BitKeeper was. It's about adding more roads to Rome and putting up better signage and helpful tourist centers along the way.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 22:21 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (2 responses)

> there'd be a single place to find out about the entire history of a change. Review comments, change over time, the status of its journey to Linus' tree, etc.

As long as GitHub doesn't decide to garbage collect those commits, of course. And the delta between submissions of the same patch would be inaccessible from the web interface, because there's no way to do a range-diff from upstream to a PR.

GitLab is better, but not too much.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 22:52 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Yes, I agree that GitHub's interface is subpar for workflows that rewrite patches a lot. I'm not disputing that. I think it's that people think it's "Github or nothing".

In any case, ghostflow could push its check refs to the repository to force them to not be garbage collected. Any other system could probably also do the same.

Pulling GitHub into the kernel process

Posted Jun 25, 2021 12:53 UTC (Fri) by bluca (subscriber, #118303) [Link]

The delta is accessible on Github too nowadays - there's a notitication line in the PR when a force push happens: "<USER> force-pushed the <USER>:<BRANCH> branch from 1234 to 5678 x time ago", and the "force-pushed" text is a link that opens the delta before/after the force push.