[Ksummit-discuss] Kernel Summit Agenda -- 2nd draft

Mark Brown broonie at kernel.org
Wed Oct 21 17:25:28 UTC 2015


On Wed, Oct 21, 2015 at 09:37:04AM -0700, Guenter Roeck wrote:

> Does submitting patches all over the place benefit or hurt my reputation
> with other maintainers, given that the percentage of rejected patches
> is quite high ? I don't know, and I don't really care that much since my
> ultimate goal is to get problems fixed, not to get my patches accepted.
> However, for others it may play a role when deciding if or if not to
> spend the time, track down a problem, and submit a patch for it.

Yeah, I mostly just report problems (partly because it's just less time
consuming).  On the reviewer side fixes like that only get to be an
issue when submitters ignore feedback and keep on sending the same stuff
even after discussion as to why other approaches are better.

> >I've seen some active resistance to pushing fixes to mainline without
> >lengthy soaks in -next in a very rules based fashion which isn't super
> >awesome when it takes out other testing due to the breakage.  As the
> >test coverage improves this is going to be getting to be more and more
> >of an issue as failures to build or boot will cause gaps in other
> >testing.

> For fixes ? I don't recall seeing that reaction, at least not to patches
> I have been involved in. Unless in very special cases, it doesn't seem
> to make much sense to me to require bug fixes to soak in -next.

It's definitely not the norm but I have encountered it.  Obviously
indivudal cases will differ, sometimes there will be value in exposure
in -next (eg, if it's likely to get validation from the boot farms),
it's a question of what the issue is, what the coverage is and what the
risks of the fix are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20151021/8284fae0/attachment.sig>


More information about the Ksummit-discuss mailing list