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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Monday, September 10, 2018 11:19:41 PM CEST Konstantin Ryabitsev wrote:
> On 9/10/18 4:32 PM, Laurent Pinchart wrote:
> > If we want to challenge that, we'll have to agree about another communication 
> > system for the whole kernel. While I don't think that's realistic, I'm not 
> > opposed to discussing it. However, I expect many developers to come up with 
> > lists of requirements, and the result of merging all those requirements 
> > together to be exactly email and nothing else :-)
> > 
> > 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.
> 
> This is part of the reason why I mentioned pagure.io in a different
> thread -- it is mostly a web-ui sitting on top of gitolite and was
> written with an eye to be fully workable via ssh and email:
> 
> https://docs.pagure.org/pagure/overview.html#overview
> 
> With Pagure, *theoretically* (I haven't looked in any depth into any of
> it), everyone who is happy with the current gitolite/email workflow
> would just continue using their existing routine. Anyone who wants to
> use the UI for issue tracking and pull requests can optionally choose to
> do so. Since it uses gitolite, there wouldn't be a "flag day" where
> everyone would have to switch to the new workflow.
> 
> It is used by Fedora and therefore, I guess, is to some degree "backed"
> by Red Hat (in the same sense as how Fedora is "backed" by Red Hat). It
> also has the benefit of not suffering from the "community edition" vs.
> "commercial edition" duality that GitLab has. From my experience using
> Puppet, I know how tempting it is for orgs to prevent useful features
> from making it into the "community edition" if they can charge for them
> instead.
> 
> That said, I'm not sure if this would actually reduce confusion instead
> of creating more. We know for a fact that central issue tracking a-la
> Github would fail for the kernel unless there is someone in a
> janitorial^W heroic position of figuring out to whom assign each
> incoming bug.

And knowledge and enough power to make the relevant party actually take care
of the report.

And even with all that it sometimes isn't clear where the problem is to start
with and some debug work needs to be done upfront.

> I also know from experience that almost every web UI tool
> written to work with git chokes and fails on something as large as the
> kernel or when hit with a firehose of chatter like LKML.

Right.

Cheers,
Rafael