Next steps for kernel workflow improvement

Posted Nov 1, 2019 19:20 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: Next steps for kernel workflow improvement by q_q_p_p
Parent article: Next steps for kernel workflow improvement

My main issue with the email workflow (which has its benefits) is that patches get lost in the firehose. There's no public triage of patches to know anything about them, updates to patchsets is usually done through completely new threads (making it hard to see what was already discussed), joining a mailing list leaves a chasm of "before I was subscribed" and "afterwards" for older information (I read my mail in mutt). If there was better metadata tracking and linking, I'd find it a lot easier.

Next steps for kernel workflow improvement

Posted Nov 6, 2019 5:00 UTC (Wed) by marcH (subscriber, #57642) [Link]

> My main issue with the email workflow (which has its benefits) is that patches get lost in the firehose.

This is one of the main reasons absolutely every code review solution (and any every "firehose" solution for that matter) relies on some sort of *database* featuring all the typical bells and whistles: [live] queries, cross-references, statistics, [CI] triggers, filters, notifications, authentication, etc.

The web vs CLI question is important but secondary, it's "just" the interface and many code review solutions offer both to some degree.

Now what is exciting here is allusions to some _distributed_ database model? Who knows, this could revolutionize code reviews like bitkeeper decentralized and revolutionized version control...?

Next: distributed bug tracking? OK, maybe that wouldn't be useful.