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. -- Regards, Sylwester -- 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
