Em Tue, 29 Mar 2016 10:07:24 +0200 Hans Verkuil hverkuil@xs4all.nl escreveu:
I am adding one more topic:
linux-media development process discussion
Yeah, we should discuss ways to improve the process. Actually, this is a topic that we try to discuss on every year during the media summits, as there are always space for improvements.
Tempers have been a bit frayed recently about the way patches are reviewed and processed. We should take the opportunity of being in the same room to discuss this and see how the process can be improved.
We've always been a highly professional group of core developers, so I think it is important to address the issues that cropped up recently.
In my analysis (feel free to disagree) the core problem is what to do when important patch series get little or no review due to lack of time on the side of reviewers. I don't have any easy solutions, but perhaps it could be a mix of requiring at least one non-author sign-off from core devs for such patches, and somehow identifying the crucial patches. A review isn't normally necessary for general churn that does not impact functionality, so a way of filtering those out when reviewing might be helpful. Or explicitly asking for reviews for specific patches.
While we always wanted to have reviewers at the community, this has been a long time issue.
That's, by the way, one of the goals by having sub-maintainers were to have at least two pairs of eyes reviewing patches.
What it was agreed when we set up such model is that sub-maintainers would be reviewing the drivers from their own area and that patches affecting the core would be reviewed by the group of sub-maintainers that have expertise on that part of the core.
The original goal were to have sub-maintainers for all parts of media subsystem, like: - V4L2 driver's code; - V4L2 codecs; - Media Controller; - Webcams; - Remote Controller (RC); - DVB.
However, we never found anyone that would willing to sub-maintain RC, and sub-maintainership didn't work well for DVB.
On V4L2 side, it worked well for a while, but nowadays I'm only receiving regular pull requests from you. So, I'm assuming that the other sub-maintainers are at the -EBUSY state.
I really want extra pairs of eyes on patches, specially on core ones, but it should be something that would work well, for the cases where reviewers are rare or don't have time.
In the case of the MC work being done recently the problem is that Laurent is in a permanent state of -ENOTIME, and I have had almost no time as well during the last 4-5 months. It looks like that will change for me, so I hope to have more time very soon.
A smaller practical issue I have has been the policy of avoiding posting large patch series due to concerns of flooding of the mailinglist. I found that that made my life as reviewer much harder.
There's actually some other concerns:
- The patchbomb script at the server is programmed to not handle pushes with more than a certain number of patches. I don't remember the exact amount that is set on each tree, but it is around 50 patches or so. This is to avoid patchbomb duplicated patches when we merge back from upstream.
- when there's a problem on a very long patch series and this gets rejected, the entire series may need to be rejected;
- In the case of such rejections, we'll have another huge patchbomb series;
- Doing reviews on a very long patch series is not fun; developers need to reserve a large amount of time to review the thing;
- It is specially depressing for reviewers when they need to dig on those large patch series for more than 2/3 interactions. However, those long series usually take 10+ reviews... because the probability of having (usually minor) troubles increase exponentially with the number of patches.
IMHO this is a mailinglist for developers and as such flooding is no issue for me. Ease of reviewing trumps that any time. It's not as if this happens every day.
It is not an issue to me, but it is an issue for non-developers. Even developers complain if you send a huge patch series (and then keep re-sending it periodically until make everyone happy).
Things are now worse than before, because now we're usually sending the patch series also to other ML and other people, due to check-maintainers script.
So, I can't think on a better alternative for that.
In any case, IMHO, this specific issue should be discussed via the ML, as any changes at the ML policies and/or the split of it into smaller MLs will affect everybody that subscribes it.