Re: Kernel development collaboration platform wish list

On Friday, September 13, 2019 1:13:16 PM CEST Jani Nikula wrote:

On Fri, 13 Sep 2019, "Rafael J. Wysocki" [off-list ref] wrote:

quoted

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).

As I wrote in [1], I think git send-email and am are a lossy method of
transmission, and reliably regenerating commits from patches, with the
right baselines, as well as tracking various patch and patch series
versions, is very difficult.

Assuming that git is used to generate patches in the first place.

Some people use different methods, like quilt, however.

I think we should have a git push based mechanism to contribute, which
would in turn send the patches to the right lists and maintainers for
review.

Alternatively, one could point the change submission mechanism to a
git branch exposed from somewhere and a tree to merge it on top of.

Maintainers could, at their choosing, still use the emailed
patches (which would all be sent using the same pipeline, without the
typical issues) and their exact existing workflows, or switch to using
the commits from a branch directly.

There are more contributors than maintainers by several orders of
magnitude. It would make the maintainers' lives so much easier if the
patches came in the same way, every time.

I guess you mean a consistent view of all patches regardless of the source.

If so, then I agree, that should be one of the goals.

When we have technical issues
with patches, as maintainers, the problems rarely are in the receiving
end. IMO solving *all* the other items in this email would become much
easier if had this first.

BR,
Jani.


[1] http://lore.kernel.org/r/87lfv3w3v6.fsf@intel.com

quoted

  (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).

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. :-)

Cheers,
Rafael