Re: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)

["Natalie Protasevich" <protasnb@gmail.com>]

n 8/27/07, David Rees <drees76@gmail.com> wrote:
> On 8/27/07, Daniel Walker <dwalker@mvista.com> wrote:
> > Now that I'm looking at the kernel bugzilla .. If you set the kernel
> > version to 2.6.22 and set the "Regression" check box you could denote
> > the fact that it's a regression in that kernel version ..
> >
> > I don't know if this URL is going to come out right,
> >
> > <snip url>
> >
> > That should be open bugs , kernel version 2.6.22, with the regression
> > check box set ..
> >
> > So you may not need a master tracking bug ..
>
> Yep, that's another way to do it. The method I described earlier is
> commonly used when you don't have the handy regression field in
> bugzilla. The technique is handy for creating lists for tracking other
> types of issues which don't necessarily fall into a component and you
> don't want to bother customizing bugzilla.
>
> I also suspect that there will be a number of common searches that
> many people will find useful. With recent versions of bugzilla (3.0+)
> you can share searches within groups, but it may be helpful to have a
> wiki or some other page where useful searches can be stored, or one of
> the templates edited to include those common searches.
>
> -Dave
>

What David suggested - is exactly what I was going to do, checking out
3.0 etc. Pretty much every post from everyone in this thread is an
action item.

I think we should start getting unsolved regressions in bugzilla, as a
"natural process". And maybe throwing them all in there even those
that got immediately resolved is probably a good thing - better than
to miss one. Either you do it Michal or dump it on me (I'm still doing
sorting out and cleaning things up, actually myself and Adrian - are
re-basing everything and getting rid of stale stuff).
Then I think bugzilla needs:
     adding more categories such as security, system calls (lots of
implementation suggestions for posix and non-posix ones), locking,
etc;
     improved searches - for sure, for example in addition to
pre-cooked queries make possible using "raw" queries directly on sql,
which will address misplaced bugs and will make categories more
dynamic;
    recipe database, for standard debugging requests and procedures
(serial console, getting sysreq traces, bisecting etc. - things to cut
and paste)
    user modifiable personal environment ("my bugzilla"), more of
morph type interface around the database.
... not mentioning all flaws and problems with current one (cannot get
back to home page, clear previous search, do certain updates in one
step and so on)

Regressions need to be tracked in effective manner, and I also noticed
counter intuitive question that we have now (the infamous "last
release when it _didn't_ happen") is clearly not the way to go, rather
 adding simple boxes "Was working in XX" and "Not working in XX" or
similar straightforward question.

In my opinion bugzilla is far from being a convenient tool. I suspect
that hating bugzilla comes down to having to deal with no
sophisticated interface that is inadequate - when so many nice and
slick tools and sites are around that we all used to.  I am also
investigating and checking out other bugzillas looking for good ideas.

Thanks,
--Natalie