Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

I'm not really sure if this should improve or worsen Mauro's rate.

Just my two cents,
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux