[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Mauro Carvalho Chehab]

Em Fri, 7 Sep 2018 09:07:41 -0600
Jens Axboe <axboe at kernel.dk> escreveu:

> On 9/7/18 8:56 AM, Sasha Levin via Ksummit-discuss wrote:
> > On Fri, Sep 07, 2018 at 12:27:54AM -0400, Theodore Y. Ts'o wrote:  
> >> As far as users testing Linux-next --- I'm willing to try running
> >> anything past, say, -rc3 on my laptop.  But running linux-next?  Heck,
> >> no!  That's way too scary for me.  
> > 
> > That's why linux-next has a pending-fixes branch. IMO it makes more
> > sense to run that than a random -rcX release.  
> 
> I'm pretty convinced that linux-next is very useful as integration
> testing. On numerous occasions I learn of conflicts that will impact me
> for the merge window, and Stephen is great at providing merge fixes that
> helps everybody out. I'm much less convinced that it's useful for
> runtime testing. It's extremely rare that I get a bug report on
> linux-next, whereas I get them after patches have been merged into
> Linus's tree all the time. Nobody is going to be running that
> pending-fixes branch.

Same applies here: the stuff I usually get from linux-next bots
are usually due to some random config that, and, while it is nice
to fix, there's no real impact in practice, as it usually means 
building a driver for an architecture where it doesn't apply, or
a weird mix of modules/builtin drivers with no users.

Yet, I always wait for a patch to be merged at next before sending
upstream, although I usually don't wait for a long time after
-next in order to send stuff upstream, as I don't expect users
to actually test what's at -next.

Thanks,
Mauro