lkml.org 
[lkml]   [2007]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)
On Wed, Aug 29, 2007 at 04:59:47PM -0700, Natalie Protasevich wrote:
> > Bugzilla is for tracking bugs, not for discussing possible
> > kernel features.
>
> True, but some of them are categorized as bugs from the reporter's
> prospective, when they say "man page says" or "according to POSIX it's
> wrong".

If code behaves differently from how it should that is a bug. [1]

> I am going to push ones that are feature suggestions,
> re-design suggestions, and some way implementation related out to the
> site that Rick is going to help to maintain, which is more of
> suggested projects list.
>
> > Tracking feature or implementation suggestions wouldn't make sense.
> > Consider e.g. that there are several people on linux-kernel who often
> > write what they think the kernel should do but who never write a single
> > line of code themselves. There's no value in tracking such stuff.
>
> Yes, but some suggestions seem to make sense. How about evaluating it?
> and if they are real making it a possible project for someone who
> would do appropriate research, etc. And we move them from bugzilla
> where they don't belong to a development arena.

Fine with me, my point was simply that they don't belong into a
_bug_ tracker.

> > > 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;
> >
> > What do you have in mind?
>
> I am going to look into the bugzilla software to start with, and see
> if there is a way to expand it this way. we used to have such internal
> tracking (unix based) at work, where we could compose pretty much
> freelance queries, it is really not big deal for developers who script
> and write huge regular expressions for their convenience every
> day...just a vogue idea for now, trying to think how to minimize bugs
> that get lost because of wrong bucket. Going manually through all of
> them is not very effective.

Is there any reasonable query that would be possible through SQL but
isn't already possible through the web interface?

> > I've always been able to do any search I wanted using the "Advanced Search"
> > of Bugzilla. Well, just checking, it seems the search for the new
> > "regression" flag could be made easier, but that's not a general problem.
>
> Yes but you have to assume that everything is in the right place from
> start, besides putting things into categories is often impossible
> before some exchange with reporter and initial diagnostics. The worst
> category so fas as I found is "other" (in every place where it
> exists). Most of the "other" bugs haven't been touched, and some have
> huge "SATA" letters in the description written in them :)
>...

You need some kind of first level support that does some initial
debugging and assigns the bug into the right category, and that will
always be a manual task done by going through all new bugs.

> --Natalie

cu
Adrian

[1] there are special cases where the kernel might deliberately not
some specification

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-30 10:53    [from the cache]
©2003-2011 Jasper Spaans