Re: Kernel development collaboration platform wish list

[Daniel Axtens <dja@axtens.net>]

Eric Wong <e@80x24.org> writes:

> "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
>> One of the things I'd like to add as a strong desire is the ability to
>> review patches via web if that's what users would like to do.  There
>> are some real benefits for web-based review.  It means that if you
>> need to see greater context, it's relatively easy to do this.  It also
>> is convenient to be able to see the conversation for a particular hunk
>> of code right alongside the code.
>
> I've already started on that with public-inbox; it's not enabled
> on lore, yet(*); but public-inbox.org/git can use "git apply"
> and dfpre:/dfpost: search prefixes to reconstruct git blobs out
> of emailed patches.
>
> For example, a self-rejected patch I posted in 2016:
>
>   https://public-inbox.org/git/20160711210243.GA1604@whir/
>
> If you follow the link at the hunk header offset "+3,7",
> it'll bring you to:
>
>   https://public-inbox.org/git/8d27707/s/?b=http-walker.c#n4
>
>   The bottom of that page has a a "debug log:" which tells
>   how the blob is reconstructed using the email and pre-existing
>   blob.
>
> Since it can recreate blobs using patches, the next step is to
> support showing "git diff" against reconstructed blobs with for
> arbitrary contexts; but I got side-tracked from that earlier
> this year...
>
> (*) lore could configure coderepo associations, but that's a
>     bear with the amount of repos kernel.org has...
>
>> It's clear that whatever we do, it needs to be compatible with e-mail.
>> That's very clear.  But it would be useful if we can support both the
>> e-mail and web-based review.  There have some prototypes that have
>> been floated which shows that it is at least possible; perhaps
>> imperfectly, but something which provides a bidrectional gateway
>> between those who perfer to use e-mail and those that prefer to use a
>> web-based UI would be able to do it.
>
> A hacker-oriented a webmail UI could be derived from
> public-inbox and completely interoperable with other mail
> servers (it would also support SMTP/IMAP, of course).
>
>> There will be many potential kernel contributors who will be used to
>> web-based UI's such as those that are available on github.  So while
>> remaining e-mail compatible, having some way of allow as many
>> operations to be done via web interfaces might help us get some newer
>> developers who are more comfortable to living on the web than some of
>> us more senior developers who remember when "gopher" was a text-based
>> search engine, and not a mascot for the Go programming langauge.  :-)
>
> Unfortunate, but yeah.  Any web-based UIs ought to include some
> subtle (or maybe not-so-subtle) hints/pointers towards
> cheaper-to-run-and-likely-more-powerful tools and practices.
>
> I can't prove it, but it seems like public-inbox has been
> successful at promoting the use of Message-IDs in URLs and
> git-send-email :)

FYI, the next release of Patchwork will move to message-id based URLs
rather than numeric IDs. (Old URLs will still work of course! They will
redirect to new URLs.)

Regards,
Daniel