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

In other words, I'm not at all ra-ra about implementing this, but if
there is enough consensus that it's worth trying out, I will be happy to
set something up for a test spin.

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation