[Ksummit-discuss] [CORE TOPIC] Issues with stable process

[Olof Johansson]

On Wed, Jul 15, 2015 at 9:03 AM, Greg KH <greg at kroah.com> wrote:
> On Wed, Jul 15, 2015 at 10:52:13AM -0400, Olof Johansson wrote:
>> On Mon, Jul 13, 2015 at 2:51 PM, Mark Brown <broonie at kernel.org> wrote:
>> > On Mon, Jul 13, 2015 at 02:21:32PM -0400, Steven Rostedt wrote:
>> >
>> >> I disagree. I thought next was a place to have integration of new
>> >> development, and not just a place to test. Really, how many people test
>> >> next compared to Linus's tree? I trip over bugs all the times in
>> >> Linus's tree that's been in -next for almost a whole release cycle.
>> >
>> >> The only bugs that I find that come from -next is integration issues,
>> >> where an interface changes and another subsystem stumbles over it.
>> >> That's exactly what it was for and what it's good at.
>> >
>> > In the embedded space it's much more common to track -next as people are
>> > often working with multiple subsystems so the integration is important.
>> > Most of my code is developed against -next then moved to topic branches
>> > for submission.
>> >
>> > We also catch quite a lot of issues in -next as a result of the work on
>> > boot testing that kernelci.org and Olof's bots are doing, hopefully
>> > that'll start to build out to include test suites like kselftest (I know
>> > there's work in progress there but no ETA as of yet).  Things get
>> > exposed to a lot more systems and configurations than individual
>> > maintainers have access to which can shake out issues in code that deals
>> > with hardware.
>>
>> I've stopped running -stable releases through the tester. It didn't
>> fit the way I kept track of what's been built very well and it was
>> hard to capture a useful state in which to test.
>>
>> For a while I tried to capture the current-state-of-the-queue from
>> gregkh's public quilt series ever so often, but it's quite churny.
>> There's an -rc that's posted for review but not tagged and not
>> provided as a git branch of applied patches, so it's hard to
>> automatically test just those.
>>
>> That would be the ideal setup for me though -- tagged or branched -rc
>> candidates of stable releases that I'd be happy to put through the
>> build/boot test at my end.
>
> kernelci now handles -rc stable releases, so would this just be a
> duplication of that work?

Great, then I won't waste my time on it.


-Olof