|
|
Subscribe / Log in / New account

Linux 5.12's very bad, double ungood day

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 19:28 UTC (Mon) by mathstuf (subscriber, #69389)
In reply to: Linux 5.12's very bad, double ungood day by syrjala
Parent article: Linux 5.12's very bad, double ungood day

Well, the state of patch status visibility on mailing lists is…low. Long mail delivery time doesn't help the issue. I'm fine with mailing lists as a development nexus, but there needs to be some infrastructure around them to indicate the status of the patches as superceded, reviewed, rejected, queued, etc.


to post comments

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 20:34 UTC (Mon) by flussence (guest, #85566) [Link] (4 responses)

That's what https://patchwork.kernel.org/ appears to already address.

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 21:56 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

Well, it *tries*. Look at this pull request:

https://patchwork.kernel.org/project/keyrings/patch/13239...

Its state is "New", but it has been dropped by the submitter. How would one change the state from "New" to "Dropped"?

This one is tracked as "New", but has been merged (as noted by the pr-tracker-bot). How did Patchtracker miss this?

https://patchwork.kernel.org/project/keyrings/patch/13228...

And this is for pull requests.

This one is "New", but has a "Reviewed-by" someone who can collect it for the subsystem. Where is it on its way into the appropriate tree(s)?

https://patchwork.kernel.org/project/keyrings/patch/20210...

And that's just the one list I follow loosely. How can one trust this site for actual tracking of arbitrary kernel patches with this quality of tracking? Sure, this list might not *use* patchtracker as much as other lists, but how does one determine *that* bit of information?

Linux 5.12's very bad, double ungood day

Posted Mar 9, 2021 16:12 UTC (Tue) by andy_shev (subscriber, #75870) [Link] (1 responses)

Unfortunately patchwork is disconnected from the target repository. That's why Gerrit is better, for example.

Linux 5.12's very bad, double ungood day

Posted Mar 9, 2021 20:29 UTC (Tue) by marcH (subscriber, #57642) [Link]

> Unfortunately patchwork is disconnected from the target repository. That's why Gerrit is better, for example.

patchwork tries to find code submissions not addressed to it directly. All other code review solutions require everything to be sent to them directly, they act as gateways. That's the very simple reason why they have all the information and all work better.

The icing on the cake is of course recipient-controlled email notifications instead of sender-control notifications (a.k.a... "spam"). In other words people routinely subscribe and unsubscribe to/from individual code reviews; not possible with a crude mailing list.

None of this is rocket science, it's all very easy to see and understand except when obsessing about the "email versus web" user interface questions; these debates are not "wrong" but they hide the much more important backend and database design issues.

You could totally have a gateway type code review tool entirely driven by email. In fact requesting all submissions, review comments and approvals or rejections to be sent (by email) to patchwork directly and putting patchwork in better control of the git repo would get at least half-way there.

Linux 5.12's very bad, double ungood day

Posted Mar 11, 2021 16:04 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Another instance I saw today was that a version of the patch that went in was never on the list (a whitespace fix). While such a tiny change is probably OK in practice, I vastly prefer having a bot attached to the service that stashes away every version of the patchset for posterity.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds