Am 10.12.2012 18:38, schrieb Mauro Carvalho Chehab: > Em Mon, 10 Dec 2012 17:27:29 +0100 > Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > >> On Mon December 10 2012 16:56:16 Frank Schäfer wrote: >>> Am 10.12.2012 14:07, schrieb Hans Verkuil: >>> >>> <snip> >>>> 3) This document describes the situation we will have when the submaintainers >>>> take their place early next year. So please check if I got that part right. >>> ... >>> >>>> Reviewed-by/Acked-by >>>> ==================== >>>> >>>> Within the media subsystem there are three levels of maintainership: Mauro >>>> Carvalho Chehab is the maintainer of the whole subsystem and the >>>> DVB/V4L/IR/Media Controller core code in particular, then there are a number of >>>> submaintainers for specific areas of the subsystem: >>>> >>>> - Kamil Debski: codec (aka memory-to-memory) drivers >>>> - Hans de Goede: non-UVC USB webcam drivers >>>> - Mike Krufky: frontends/tuners/demodulators In addition he'll be the reviewer >>>> for DVB core patches. >>>> - Guennadi Liakhovetski: soc-camera drivers >>>> - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer >>>> for Media Controller core patches. >>>> - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video >>>> receivers and transmitters). In addition he'll be the reviewer for V4L2 core >>>> patches. >>>> >>>> Finally there are maintainers for specific drivers. This is documented in the >>>> MAINTAINERS file. >>>> >>>> When modifying existing code you need to get the Reviewed-by/Acked-by of the >>>> maintainer of that code. So CC that maintainer when posting patches. If said >>>> maintainer is unavailable then the submaintainer or even Mauro can accept it as >>>> well, but that should be the exception, not the rule. >>>> >>>> Once patches are accepted they will flow through the git tree of the >>>> submaintainer to the git tree of the maintainer (Mauro) who will do a final >>>> review. >>>> >>>> There are a few exceptions: code for certain platforms goes through git trees >>>> specific to that platform. The submaintainer will still review it and add a >>>> acked-by or reviewed-by line, but it will not go through the submaintainer's >>>> git tree. >>>> >>>> The platform maintainers are: >>>> >>>> TDB >>>> >>>> In case patches touch on areas that are the responsibility of multiple >>>> submaintainers, then they will decide among one another who will merge the >>>> patches. >>> I've read this "when the submaintainers take their place early next >>> year, everything will be fine" several times now. >> I doubt everything will be fine, but I sure hope it will be better at least. >> In other words, don't expect miracles :-) >> >>> But can anyone please explain me what's going to change ? >>> AFAICS, the above exactly describes the _current_ situation. >>> We already have sub-maintainers, sub-trees etc, right !? And the people >>> listed above are already doing the same job at the moment. >>> >>> Looking at patchwork, it seems we are behind at least 1 complete kernel >>> release cycle. > No, this is not true; git pull requests are typically handled faster, as > the material there is submitted either by a driver maintainer or by a > sub-maintainer. The delay there for -git is currently 2 weeks, as we closed our > merge window at the beginning of -rc7 (expecting that there won't be a -rc8). But it's not "git pull request" vs. "patches sent to the list directly", it's "reviewed" vs. "not reviewed", right ? > The very large of individual patches have a longer delays, due to the lack of > driver maintainers reviews. That's what I said, the problem is that we lack maintainers/reviewers. And people beeing subsystem maintainers AND driver maintainers have to find a balance between processing pull requests and reviewing patches. I'm not sure if I have understood yet how this balance should look like... Can you elaborate a bit on this ? At the moment it's ~12 weeks / ~2 weeks. What's the target value ? ;) > >>> And the reason seems to be, that (at least some) maintainers don't have >>> the resources to review them in time (no reproaches !). >>> >>> But to me this seems to be no structural problem. >>> If a maintainer (permanently) doesn't have the time to review patches, >>> he should leave maintainership to someone else. > Agreed. > >>> So the actual problem seems to be, that we don't have enough >>> maintainers/reviewers, right ? >> The main problem is that all the work is done by Mauro. Sure, people help >> out with reviews but a lot of the final administrative and merge effort is >> done by one person only. In particular the patch flow is something he can't >> keep up with anymore. So by assigning official submaintainers who get access >> to patchwork and can process patches quickly we hope that his job will become >> a lot easier. >> >> So the core two changes are 1) giving clear responsibilities to submaintainers >> and 2) giving submaintainers access to patchwork to keep track of the patches. >> >> So patch submitters no longer have to wait until Mauro gets around to cleaning >> out patchwork. Instead the submaintainers can do that themselves and collect >> accepted patches in their git tree and post regular pull requests for Mauro. >> >> It should simplify things substantially for Mauro, we hope. >> >> I think we have enough people doing reviews etc. (although more are always >> welcome), it's the patchflow itself that is the problem. > Yeah, the issue is that both reviewed, non-reviewed and rejected/commented > patches go into the very same queue, forcing me to revisit each patch again, > even the rejected/commented ones, and the previous versions of newer patches. > > By giving rights and responsibilities to the sub-maintainers to manage their > stuff directly at patchwork, those patches that tend to stay at patchwork for > a long time will likely disappear, and the queue will be cleaner. So who can get an account / is supposed to access patchwork ? - subsystem maintainers ? - driver maintainers ? - patch creators ? Regards, Frank > Regards, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
