On Mon, Oct 1, 2012 at 11:44 AM, Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx> wrote: > On 10/01/2012 04:28 PM, Hans Verkuil wrote: >> On Mon October 1 2012 16:05:15 Ezequiel Garcia wrote: >>> Mauro and folks, >>> >>> On Mon, Oct 1, 2012 at 10:35 AM, Mauro Carvalho Chehab >>> <mchehab@xxxxxxxxxx> wrote: >>>> Hi Anti/Sylwester, >>>> >>>> Em 01-10-2012 08:50, Antti Palosaari escreveu: >>>>> Hello >>>>> I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. >>>>> >>>>> What I propose: >>>>> 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] >>>>> 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... >>>>> 3) PULL request are handled more often, like during one week or maximum two >>>> >>>> Yes, for sure we need to improve the workflow. After the return from KS, >>>> I found ~400 patches/pull requests on my queue. I'm working hard to get rid >>>> of that backlog, but still there are ~270 patches/pull requests on my >>>> queue today. >>>> >>>> The thing is that patches come on a high rate at the ML, and there's no >>>> obvious way to discover what patches are just the normal patch review >>>> discussions (e. g. RFC) and what are real patches. >>>> >>>> To make things worse, we have nowadays 494 drivers. A very few of those >>>> have an entry at MAINTAINERS, or a maintainer that care enough about >>>> his drivers to handle patches sent to the mailing list (even the trivial >>>> ones). >>>> >>>> Due to the missing MAINTAINERS entries, all patches go through the ML directly, >>>> instead of going through the driver maintainer. >>>> >>>> So, I need to manually review every single email that looks to have a patch >>>> inside, typically forwarding it to the driver maintainer, when it exists, >>>> handling them myself otherwise. >>>> >>>> I'm counting with our discussions at the Barcelona's mini-summit in order >>>> to be able to get fresh ideas and discuss some alternatives to improve >>>> the patch workflow, but there are several things that could be done already, >>>> like the ones you've proposed, and keeping the MAINTAINERS file updated. >>>> >>> >>> Perhaps I'm missing something but I don't think there's an obvious >>> solution for this, >>> unless more maintainers are willing to start providing reviews / tests >>> / acks / etc. >>> for patches that arrive. >>> >>> Seems to me media/ has become a truly large subsystem, >>> though I'm not sure how does it compare to others subsystems. >>> Has anyone thought about breaking media/ down into smaller sub-subsystems, >>> with respective sub-maintainer? >> >> Yes, and this will be discussed next month during the Media Summit. > > Something like this came through my mind as well. It seems handling all > the drivers/media stuff is becoming simply too much to tackle by one person > in quality and timely manner. > Another issue that needs discussion is the vast amount of different devices (consider em28xx for instance) making maintainment particularly hard. Perhaps, some sort of "Device donation request" (aimed at hw vendors) to distribute among developers could be helpful. Regards, Ezequiel. -- 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
