Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

[Ingo Molnar <mingo@elte.hu>]

* Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

[...]
> > That action might hang or crash his kernel, and if that user then 
> > reports:
> > 
> >   " Hey, -rc7 just hung on me after enabling this new .config option
> > it offered for the radeon driver i am using, please add this to the
> > list of regressions. "
> > 
> > is this really the right kind of reply:
> > 
> >  " Since we moved it from drivers/staging/ to drivers/ this hang you
> > are seeing is technically not a regression, we might or might not fix
> > it. "
> > 
> > ?
> > 
> > I doubt the user would be overly enthusiastic about that kind of
> > reply ;-)
> 
> Whether or not it's a regression is mostly irrelevant, it's a real bug and 
> the radeon guys are working on fixing it. [...]

Fortunately it's being worked on.

I beg to differ with your argument about it not mattering whether a bug is 
categorized as a regression: Rafael's regression list is far more prominent 
and the bugs listed there get fixed with a high likelhood.

Note that there's clear evidence of that in this very thread: the hang bug 
was ignored as a "plain" DRM non-regression bugreport, _despite_ the prior 
scrutiny in the thread, up to the moment Linus pointed it out and turned it 
into a de-facto regression ...

There's also another purpose of categorizing bugs as regressions: tester 
timeliness. We tend to treat bugs as 'plain bugs' when they are reported too 
late after a few kernel releases of the bug having been in the wild. We do 
this to encourage testers to test earlier -rc's as well, as there's a real 
tangible benefit of the 'we dont do regressions' policy: bugs get fixed and 
testers feel involved, and it's also the stage were we _can_ fix bugs with a 
lower cost to all parties involved.

But what 'timeliness of testing' can there be if new features are added in a 
late -rc and bugs are explicitly categorized as 'not a regression'?

	Ingo