Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Tue, 11 Sep 2018 02:05:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Ted,
> 
> On Tuesday, 11 September 2018 00:11:28 EEST Theodore Y. Ts'o wrote:
> > On Mon, Sep 10, 2018 at 11:32:00PM +0300, Laurent Pinchart wrote:  
> > > On my side, there are three very important features that a communication
> > > system should have:
> > > 
> > > - It should be push-based. I don't want to have to log in and pull
> > > information from web UIs.
> > > 
> > > - It should be customizable, offering an easy way to script review, and
> > > patch and pull request handling.
> > > 
> > > - It should offer an offline mode. Lots of us travel a lot or generally
> > > have to work without an internet connection more often than we would
> > > like, so any solution that requires being online won't work.
> > > 
> > > Emails provide all that, there may be good options I just fail to think
> > > about right now.  
> > 
> > One more requirement I would add is that messages should be archived,
> > and should have a first class search system.  We should be able to
> > reference a commit id in a communications thread, and then a search
> > for that commit id (or commit description) should be able to turn up
> > that message, and from there, be able to see the rest of the messages
> > on that thread.
> > 
> > Being able to find the "legislative history" behind a particular
> > change in the kernel is super-important.  
> 
> Fully agreed. I would even go one step further, I'd like a system where 
> relationships between messages are kept. This obviously means linking patches 
> from the same series, but also detecting new versions of patch series (to the 
> extent possible, as already discussed in this mail thread).
> 

Let me go one step down.

While I do agree that the main Kernel development should happen via
email on the foreseen future, Why e-mail would be a mandatory
requirement for all kinds of Kernel development? 

I don't believe that a single development model fits all cases.

Let's say that someone is using something like github to manage the
development of a single driver - or even a low traffic subsystem.

The communication traffic between the developers there is usually
not relevant (nor wanted) at LKML.

What we usually do on normal subsystems is to have those discussions
"filtered" on a separate mailing list. I don't see why not use a
web-based interface for such purpose.

Btw, that's not that different on what happens on some companies that
do their driver developments internally. They do whatever they want
when developing the driver. Only when they have something ready they
use e-mail.

A github-like interface is actually better than that, as people 
interested on such driver/subsystem could contribute earlier than 
on a closed doors model, as the discussions can be seen publicly.

On both cases, the only relevant discussions for LKML and for the
Kernel maintainer that would be taking their patches are when they
send a pull request upstream.

Granted, there will be some drawbacks if email interface is not
available if such development community would need to talk with
other subsystems. So, yes, it is desirable to have an e-mail
interface, as otherwise a human would have to handle such things
manually, but, again, for low traffic development, such things
would be doable.

Thanks,
Mauro