Em Sun, 20 Apr 2014 17:50:06 +0200 Hans Verkuil hverkuil@xs4all.nl escreveu:
14:00-14:15 Patch review process (Laurent Pinchart) Several developers were unhappy with patch series posted a month before being rejected right before the mainline merge window. Should our process be improved in that area?
15 mins is probably not enough for a brainstorm about the process review, So, I suggest that we should start discussing this topic via ML, and use the 15 mins there just to do the final adjustments on the process improvement ideas.
Let me start this discussion with the issues that, on my view, are causing a high delay. We should remind that API patches and new drivers in general require a higher delay than usual patches, as, in the first case, we want more review to be sure that the API is stable before setting it into a stone and, on the second case, new drivers (especially from new developers) require more review.
Issue 1: Master branch freeze - The main branch is freezed at -rc7, remaining (almost) frozen for 3 weeks; - The week after, it receives typically only bug fixes; - That generates a delay of about one month, and accumulates patches to review that affects patches during the other weeks;
Proposal: - Use topic branches during the freeze period (to be done: what topic branches?) - Topic branches can be rebased any time
Issue 2) API reviews - Those need a larger delay, in order to stablize the changes - It is not that easy to identify what patch series are due to API, and, among the patch series, what patches contain API, and what patches are there “just for example” (e. g. They don't define the API, but are there showing how to use the new API and/or are patches).
Proposal: - Tag API changes on a different way
Issue 3) DT Patches - Those require a DT maintainer review before we can start our process
Proposal: - Talk with DT maintainers, and see if one of the V4L maintainer could be an ad-hoc DT maintainer;
Issue 4) Some sub-maintainers are taking too long to review patches - That generates an additional delay, as I generally wait for them to merge patches; - When a sub-maintainer takes too long, and I realize the problem, I sometimes just act as a normal patch. Yet, the delay already happened.
Proposal:
- We need to identify the cases and see what's happening at sub-maintainers side;
Issue 5) There are still some areas with sub-maintainers (like RC)
Any other bottlenecks?