Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org

[Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>]

Em 15-08-2012 06:54, Hans Verkuil escreveu:
> On Tue August 14 2012 16:28:05 Mauro Carvalho Chehab wrote:
>> Em 14-08-2012 10:46, Hans Verkuil escreveu:
>>> On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:

>> Without tagging them differently, I don't have any way to know what are
>> ready for merge, and what wasn't.
> 
> It's too bad patchwork doesn't support a way where the submitter can kill a
> wrong patch. That would be very useful.

Yes. If patchwork had such support, patch senders could also be marking a patch
as superseded or as RFC.

I don't know enough about patchwork to write such addition into it.

>> Anyway, I'm open to ideas on how to handle it better, especially when it helps
>> to allow handling patches on uniform way, without needing to apply different
>> procedures for each driver maintainer.
> 
> I have no problem with making pull requests when I think a patch series is ready,
> as long as it is made very clear to me that that's the way you work for patches
> from me.
> 
> This is fine for 'regular' patches. But in practice I also have two other kinds
> of patches: the first is the trivial kind: fixing typos, compiler warnings,
> one-liner bug fixes. Basically patches where the review process takes one
> minute tops. I would propose a [PATCH TRIVIAL] category: patchwork would pick
> them up, you go through them quickly once or twice a week and either apply them
> or mark them as RFC or something if you think they aren't as trivial as they
> look.

[PATCH TRIVIAL] is something that makes sense on those cases, and it is pretty
used on other trees.
 
> That way my git tree won't get messy with lots of little branches for what are
> trivial patches, and these patches get processed quickly so they won't clutter
> patchwork.
> 
> The other type of patch are core kernel API changes. Those need a review from
> you as well, and it is frankly very annoying if after a long discussion on the
> mailinglist we come to a solution, make a final pull request for it, and only
> then will you review it and shoot it down... And sometimes that happens just
> before the merge window opens, leaving us with no time to fix things.

True. I try to follow those patches at the ML when time allows me to do it,
and I'm just not so over-bloated with a huge patch backlog. FYI, on the last 2
days, ~60 new patches arriving and are waiting for my review. That's because 
it is not close to the end of a merge window, when the volume of patch goes as
high as the sky.

> I don't mind being shot down, but I'd like to see that happen a bit earlier
> in the process when I haven't invested that much time in it and when I can
> make changes in a timely manner.
> 
> So I proprose a [PATCH API] category for patches enhancing or modifying the
> core API.

OK.

> 
> It's a signal for you that these are relevant for you as subsystem maintainer
> to look at them earlier rather than waiting for the final pull request.
> 
> What do you think?
> 
> Regards,
> 
> 	Hans
> --
> 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
> 

--
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