On Mon, Jun 17, 2019 at 08:03:15AM -0300, Mauro Carvalho Chehab wrote: > Laurent Pinchart 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.