Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

On Mon, Jun 17, 2019 at 08:03:15AM -0300, Mauro Carvalho Chehab wrote:
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > On Fri, Jun 14, 2019 at 12:11:37PM -0300, Mauro Carvalho Chehab wrote:

> > > We're receiving about 400 to 1000 patches per month, meaning 18 to 45
> > > patches per working days (22 days/month). From those, we accept about
> > > 100 to 300 patches per month (4.5 to 13.6 patches per day).

> > > Currently, I review all accepted patches.  

> > As other have said or hinted, this is where things start getting wrong.
> > As a maintainer your duty isn't to work for 24h a day and review every
> > single patch. The duty of a maintainer is to help the subsystem stay
> > healthy and move forward. This can involve lots of technical work, but
> > it doesn't have to, that can also be delegated (providing, of course,

> There are a couple of reasons why I keep doing that. Among them:

> 1) I'd like to follow what's happening at the subsystem. Reviewing the
> patches allow me to have at least a rough idea about what's happening,
> with makes easier when we need to discuss about possible changes at
> the core;

> 2) An additional reviewer improves code quality. One of the feedbacks
> I get from sub-maintainers is that we need more core review. So, I'm
> doing my part.

> 3) I like my work.

This doesn't have to be an either/or thing - one of the things that you
can do is vary how much attention you're paying depending on whatever
factors are useful (which can be very fuzzy sometimes).  Thinking too
much about formailzing things can get in the way sometimes, both with
decision making paralysis and with making things seem scarier for
contributors who are being asked to take on responsibility.

> Also, as I said, this is media dirty laundering: weather I would keep
> doing patch reviews or not - and how this will work - is something for
> our internal discussions, and not for KS.

The specific example is from the media subsystem but these are general
issues.

> > > Also, as also discussed during the media summit, in order to have such
> > > kind of automation, we would need to improve our infrastructure, moving
> > > the tests from a noisy/heated server I have over my desk to some VM
> > > inside the cloud, once we get funds for it.  

> > Sure, and I think this is a topic that would gain from being discussed
> > with a wider audience. The media subsystem isn't the only one to be
> > large enough that it would benefit a lot from automation (I would even
> > argue that all subsystems could benefit from that), so sharing
> > experiences, and hearing other subsystem's wishes, would be useful here.

> Maybe.

> Are there any other subsystem currently working to get funding for
> hosting/automation?

Not sure if it's specifically what you're looking at but there's stuff
going on that's at least very adjacent to this, more from the angle of
providing general infrastructure than subsystem specific things and
currently mainly foucsed on getting tests run.  To me that sort of
approach seems good since it avoids duplicated efforts between
subsystems.

There's people working on things like KernelCI (people are working on
expanding to include runtime tests, and there's active efforts on
securing more funding) and CKI which aren't focused on specific
subsystems but more on general infrastructure.  Tim Bird (CCed) has been
pushing on trying to get people working in this area talking to each
other - there's a mailing list and monthly call:

    https://elinux.org/Automated_Testing

and one of the things people are talking about is what sorts of things
the kernel community would find useful here so it's probably useful at
least putting ideas for things that'd be useful in the heads of people
who are interested in working on the infrastructure and automation end
of things.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]