[lkml]   [2007]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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


[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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-30 10:53    [W:0.103 / U:26.600 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site