Message-ID: <CAPDOMVgNZ84yWM1V=P_CX2GNyOFqf_LSTe14vsqNuE4e4TSnZw@mail.gmail.com>
Date:	Sun, 29 Jun 2014 22:09:35 -0400
From:	Nick Krause <xerofoify@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>, Levente Kurusa <levex@...ux.com>,
	"Gideon D'souza" <gidisrael@...il.com>,
	Nick Krause <xerofoify@...il.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Cleanup of Kernel Bugzilla

If that is true , it may be a good idea to get me or someone to write
a text file like maintainers that
is used to keep track of open bugs by subsystem in the main kernel directory.
Cheers Nick

On Sun, Jun 29, 2014 at 5:32 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Sun, Jun 29, 2014 at 09:21:46AM +0200, Levente Kurusa wrote:
>>
>> I think that is because they are relatively young and they are generally
>> used for one direct purpose. The kernel has to make sure it works in a lot
>> of different situations and hence a lot of different bugs arise.
>
> There are a huge number of bugs which are hardware specific --- and
> worse, fixing it for one hardware device can often cause problems for
> others.
>
>> >With the linux kernel not only doesn't anything exist, the project
>> >itself is so bloody hard right, kernel programming, most of the
>> >bugzilla bugs I can barely understand let alone even begin to deduce
>> >what is going on. Now given that the list itself isn't maintained
>> >makes things extremely hard.
>>
>> There are still methods to extract various unresolved bugs from the
>> bugzilla though. Look in any subsystem you find delicious and then
>> just sort the bugs by the date they were modified. This will yield
>> a list of nice fresh bugs along with some recently fixed bugs.
>
> Or, try to find your own bugs.  Grab the development kernel, and see
> if it breaks on your system.  If it does, and it was working on the
> last stable kernel, then you can use "git bisect" to try to find the
> point where things broke, and report the problem, and perhaps try to
> figure out why it didn't work.  This can be a huge benefit for
> developers who can't test their changes on every single hardware
> configuration out there, so this sort of early testing of either daily
> linux-next, or the mainline linux tree right after the merge window,
> is a great way to learn about kernel programming.
>
> Because of the focus on "no new regressions", testing the bleeding
> edge development kernels so we can fix problems before they get
> released to civilians is not only important, but often means that the
> bugs that are still open are the ones which are incredibly hard to
> reproduce, or which require very specialized hardware.  So it's very
> likely that they won't be the bugs that are best suited for people who
> are just getting started on kernel development.  Basically, for the
> most part, if they were easy, they would have been fixed already.  :-)
>
>> I brought this up as well on the Kernel Summit list. There wasn't any
>> feedback on this :-), I guess there are some maintainers who care about
>> bugzilla, but the rest (and the majority probably) does not care.
>
> If you ("you" being the generic you) are someone who likes grooming
> the bug tracking systems, you can certainly start to try to figure out
> which bugs are no longer relevant, and then work with someone like
> Alan so they can get closed out.  Over time, as you become trusted to
> have good judgement over bugs, various subsystem maintainers may be
> willing to give you admin bits to close bugs directly.  (And by the
> way, that's something else important to note --- it's good to
> specialize; the kernel is huge, so focusing on a single subsystem is a
> good way to more quickly build up expertise, and for developers for
> that subsystem to get to know you and to trust your judgement and your
> skills.)
>
> However, you may find that unless you're someone who tends to be a bit
> obsessive-compulsive, that grooming the bugzilla doesn't really
> provide much in the way of real benefit to kernel development, and so
> don't provide you with much satisfaction.
>
> After all, we don't have any direct management oversight over
> developers for the upstream kernel.  So tracking things so that
> policies such as "all P1 bugs must be updated every day" can be
> enforced, or to keep lists of which bugs have been opened for the
> longest time so that people can have long interminable meetings about
> why a short-staffed team has so many bugs open, are things which are
> much more applicable for pointy-haired engineering managers who can
> boss engineers around and tell them to work on a particular bugs or
> else they will get a bad rating at the next performance review.  But
> for a volunteer project, keeping track of bugs is something that has
> benefits which are much more indirect.  If as a result, you don't find
> bug grooming to be very satisfying, there's no shame in moving on to
> some other form of kernel contributions that *do* give you more
> satisfaction.
>
> Best regards,
>
>                                                 - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists