This is the list of topics for the Media mini-summit on May 2nd in San Jose.
We plan to start at 9:00 and I assume we have the room until 18:00 (Mauro, can you confirm this?). This means we will probably have effectively 6 hours of discussions.
Topics for the V4L2/DVB mini-summit:
9:00-9:20 Introduction
9:20-10:50 V4L2 Ambiguities (Hans Verkuil)
This will have a large section devoted to composing/cropping/scaling. Draft presentation is available here: http://hverkuil.home.xs4all.nl/presentations/ambiguities3.odp
10:50-11:15 Break
11:15-11:30 Compound types in the control framework (Hans Verkuil)
11:30-12:30 Per-frame settings aka configuration stores (Hans Verkuil)
12:30-13:30 Lunch break
13:30-14:00 Integration of the of-graph helpers and the component framework (drivers/base/component.c) in V4L2 (Laurent Pinchart)
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?
14:15-15:15 Linux media power management (Shuah Khan)
15:15-15:45 Break
15:45-16:45 DVB demux improvements brainstorming (Mauro Carvalho Chehab)
16:45-17:00 Demo of the revamped vivi driver (Hans Verkuil)
17:00-17:30 AVB Presentation (Hans Verkuil)
If I missed topics, or you think the time for your section is too long/short, or if you need it moved to another time, then let me know.
The times are approximate, in practice some topics will take more time than expected, others less. Experience from past summits shows that it will average out.
Shuah, I allocated one hour for your presentation, do you think that is sufficient?
Regards,
Hans
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?
Hi Mauro,
On Monday 28 April 2014 04:47:06 Mauro Carvalho Chehab wrote:
Em Sun, 20 Apr 2014 17:50:06 +0200 Hans Verkuil 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.
I think we all agree on this. I don't see that as a problem.
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
I think that a part of the issues is caused by our merge process. Patches are sent to the mailing list, they get reviewed, possibly merged in a sub- maintainer tree, and a pull request is then sent to the linux-media mailing list to get the patches in the media tree. Those pull requests are often processed close to the end of the kernel cycle and the opening of the next merge window, at which point you review the patches. This means that if an issue is found at that point the changes will very likely miss the merge window.
To solve it I believe it would help if you could review patches (or at least the patches that are more likely to cause issues) without batching them at the end of the cycle.
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;
I don't agree that DT patches *require* a review from a DT maintainer. That's of course a good practice rule, but the DT maintainers have made it clear in the past that if they don't respond to pings we're allowed to bypass them.
Furthermore The DT maintainers have little knowledge about video devices, so there's a large part of the bindings that they might have trouble reviewing. I'm not saying we should bypass them, having an outside view of the problem can also help pinpointing blatant issues that we fail to see, but having V4L2 developers reviewing bindings is at least equally important.
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?
Em Wed, 30 Apr 2014 23:44:58 +0200 Laurent Pinchart laurent.pinchart@ideasonboard.com escreveu:
Hi Mauro,
On Monday 28 April 2014 04:47:06 Mauro Carvalho Chehab wrote:
Em Sun, 20 Apr 2014 17:50:06 +0200 Hans Verkuil 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.
I think we all agree on this. I don't see that as a problem.
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
I think that a part of the issues is caused by our merge process. Patches are sent to the mailing list, they get reviewed, possibly merged in a sub- maintainer tree, and a pull request is then sent to the linux-media mailing list to get the patches in the media tree. Those pull requests are often processed close to the end of the kernel cycle and the opening of the next merge window, at which point you review the patches. This means that if an issue is found at that point the changes will very likely miss the merge window.
Yes. Well, I tend to fast track sub-maintainers pull request, but, either sub-maintainers send them latter at -rc cycle, or the amount of pending patches (that got accumulated after the merge window, due to issue 1), forces me to give more attention to the individual patches that sub-maintainers don't handle. We still have hundreds of such patches on every Kernel cycle.
To solve it I believe it would help if you could review patches (or at least the patches that are more likely to cause issues) without batching them at the end of the cycle.
I agree, but then those patches should be tagged with a different "color" to help me identify what are those patches. Please notice that there are two distinct conditions here:
1) patches made by someone, that a sub-maintainer reviewed. If those patches don't add new APIs, they're unlikely to be rejected by me, as the sub-maintainer already reviewed. On the cases where this happens (for exemple, due to a serious conflict with some other patches), the amount of work to fix is not much, and those are merged in time;
2) patches made by the sub-maintainer, submitted via his own tree. Those require more care, as they don't have a previous review.
That's actually a third type of patches: the ones send by some developer that have a git tree at linuxtv.org. Those are similar to case (2), as they may not have enough review.
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;
I don't agree that DT patches *require* a review from a DT maintainer. That's of course a good practice rule, but the DT maintainers have made it clear in the past that if they don't respond to pings we're allowed to bypass them.
Yeah, after ~1 month, from what I remember from their presentations during KS.
Yet, see what happened during this merge window, with the patches that moved the OF graph out of V4L2 directory.
I had to do very ugly things, rebasing the main upstream tree. Even so, we got problems with two patches series that I sent Linus, and he had to manually fix the conflicts. All due to a very late DT maintainer patchset reject.
Furthermore The DT maintainers have little knowledge about video devices, so there's a large part of the bindings that they might have trouble reviewing. I'm not saying we should bypass them, having an outside view of the problem can also help pinpointing blatant issues that we fail to see, but having V4L2 developers reviewing bindings is at least equally important.
Yeah, I agree. We should have one sub-maintainer responsible for media DT stuff, if possible with DT maintainers bless do do it on their behalf.
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?
-
Hans Verkuil -
Laurent Pinchart -
Mauro Carvalho Chehab