Re: Kernel development collaboration platform wish list

From: Daniel Axtens <dja@axtens.net>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, workflows@vger.kernel.org
Cc: Shuah Khan <skhan@linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Jiri Kosina <jikos@kernel.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: Kernel development collaboration platform wish list
Date: Tue, 01 Oct 2019 13:52:15 +1000	[thread overview]
Message-ID: <87blv13yxc.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <5072394.GngetUhsyG@kreacher>

"Rafael J. Wysocki" <rjw@rjwysocki.net> writes:

> On Friday, September 13, 2019 10:22:20 AM CEST Rafael J. Wysocki wrote:
>> Hi All,
>> 
>> During the Maintainers Summit session yesterday I started to create a wish list
>> for the new kernel development collaboration platform to be created (and to
>> replace the multiple pieces of tooling in use today).  I also asked Bjorn,
>> Jiri, Greg and Shuah for input and here's the reslut:
>> 
>> 1. Compatible with e-mail
>> 
>>   (a) E-mail send to it stored and included automatically; appears as part of
>>       the normal flow.
>> 
>>   (b) Automatic e-mail responses
>>       If e-mail is sent to it, the sender will get all responses to it in the
>>       given thread by e-mail.
>> 
>> 2. History tracking
>> 
>>   (a) Should be able to track revisions of a given patch series (or patch) down
>>       to the initial submission.
>> 
>> 3. Integration with git
>> 
>>   (a) Should be able to create git commits from patches (or patch series)
>>       tracked by it if pointed to a git branch (either locally or remotely).
>> 
>>   (b) Link tags pointing back to it should be added automatically to git
>>       commits created from patches tracked by it.
>> 
>> 4. Distributed
>> 
>>   (a) Support for running offline.
>> 
>>   (b) Support for batch updates.
>> 
>>   (c) CL-frendly.
>> 
>> 5. Patchwork-like features
>> 
>>   (a) Delegation support.
>> 
>>   (b) Support for bundles and patch series manipulation.
>> 
>>   (c) Smart mbox (download all selected patches).
>
> And one more item from myself:
>
> (d) Support for "maintainer views"
>
>     That is, by default subsystem maintainers should see patches, bug reports
>     etc against the code maintained by them, with the possibility to extend the
>     view to also see the other submissions.
>
>     [That kind of is the case in Patchwork today when patches sent to different
>      mailing lists show up under different "projects", but the problem in there
>      is that copies of one patch appear under multiple "projects" as different
>      entities if sent to multiple lists.]

/me puts on pw maintainer hat

This is true, they are each individual database entries. This is largely
because projects will often change the state of patches differently. (An
example is a patch sent to multiple lists to collect ACKs before being
merged.)

Unsurprisingly, there's not really a lot of funding for pw development
at the moment, I'm doing it mostly as a hobby - but once we smash out a
bit of technical debt I'm slogging through it should be easier to
contribute. We also have a pretty full-featured API that I would
encourage people to check out (e.g. https://patchwork.kernel.org/api/) -
we already have a few lists using this for CI with projects like
snowpatch or custom GitLab scripts - just check out the linuxppc
patchwork for an example.

Kind regards,
Daniel

>
>> 
>> 6. Easy to set up (especially for local installations)
>> 
>> 7. Bug tracking support
>> 
>> I guess there are more items to be added to this list, so please extend it if
>> you have any ideas and we'll see where this goes. :-)