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    [W:0.027 / U:60.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site