Message-ID: <20140629213206.GE2162@thunk.org>
Date:	Sun, 29 Jun 2014 17:32:06 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Levente Kurusa <levex@...ux.com>
Cc:	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

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