[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180510153658.GE98604@atomide.com>
Date: Thu, 10 May 2018 08:36:58 -0700
From: Tony Lindgren <tony@...mide.com>
To: "Theodore Y. Ts'o" <tytso@....edu>,
Sasha Levin <Alexander.Levin@...rosoft.com>,
Greg KH <gregkh@...uxfoundation.org>, "w@....eu" <w@....eu>,
"ksummit-discuss@...ts.linuxfoundation.org"
<ksummit-discuss@...ts.linuxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] bug-introducing patches
* Tony Lindgren <tony@...mide.com> [180508 14:52]:
> * Theodore Y. Ts'o <tytso@....edu> [180508 03:50]:
> > Would I pull down linux-next, and fire up a VM running gce-xfstests?
> > Sure. But that's not a real-life use case; that's just running canned
> > test cases. And more often than not, linux-next will be broken while
> > Linus's -rcX tree is just fine; which is why I do most of my ext4
> > testing using patches based on top of -rcX, not based on top of
> > linux-next.
>
> Ideally we would somehow always end up with an -rc1 that people dare
> to use though for the "prosumer" testing :)
BTW, the reason why I think we all should test Linux next on regular
basis is that it's often "some other people's branches(tm)" that cause
the regressions :) Maybe because their own test cases did not show
any regressions, or because they were unable to test the patches.
Or it's because of some "clean-up" work that's completely untested
on some systems.
And that's how we end up with regressions getting merged into -rc1.
Regards,
Tony
Powered by blists - more mailing lists