Re: [MAINTAINERS SUMMIT] [0/4] Common scenario for four proposals regarding regressions

James Bottomley
2024-06-20T14:02:02Z

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On Thu, 2024-06-20 at 14:55 +0100, Mark Brown wrote:
> On Thu, Jun 20, 2024 at 08:57:29AM -0400, James Bottomley wrote:
>
> > Actually, if we got more people to try mainline we could perhaps
> > find more bugs.  Testing -next is problematic because its
> > instability makes things like bisection and update to next release
> > difficult.
>
> -next is problematic to actually *use* but it's not particularly bad
> for testing, mostly it's fine but you have to be able to cope with
> things going bad in you in potentially very bad ways.  For testing
> the stability is generally perfectly fine, and given that the whole
> goal is to find problems it's hard to see much of an issue.
> Bisection also works about as well as for mainline - you need to
> bisect from whatever commit in Linus' tree things were based off (or
> pending-fixes if you know that was fine) rather than a prior -next
> tag but otherwise I can't say I notice much difference to mainline.
>
> If your tests take more than a day to run then it gets more tricky,
> but that's just generally harder no matter which tree you're testing.

The difficulty is usually that by the time you get a signal something
is wrong, the next tree is different. I agree you can freeze on the
next tree you have and hope that the identified commit (by the time you
find it) is still in the current version of -next, but there is a non-
zero chance it would get rebased which makes testing next a bit more of
a chore than testing main, which is why it's tested less often than
main

Regardless, I don't think -next is a useful tree for the wider pool who
usually test stable to try because of all the difficulties. I do think
it's not impossible to get some of them to move up to main (after all
it's the .0 of stable).

James

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]