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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux