Re: Linux 2.6.21



On Thu, 26 Apr 2007, Diego Calleja wrote:

From my humble POV, it's a problem that all this discussion was generated
on what Adrian does or stop doing. Apparently, unless Adrian posts his
list of know regressions, most of the people doesn't look at the bugzilla
at all. Maybe it'd be useful to create a per-release bug tracker in the
bugzilla or collect them into one of the a kernel.org's wiki, to make easier
to follow the current state of all the "important" regressions.

Any web-based interface is a no-no. It's one reason I don't use bugzilla a
lot. If I can't get it by email, it doesn't exist, as far as I'm
concerned.

I bet that's true even of a lot of people who are more "web oriented" than
I am. They may look at webpages, but getting notified by email is still
the wakeup call. There's a difference between "active and directed pushing
to the involved people" and "the resource exists, that people could look
at".

So it would have to be more than just a wiki or a bugzilla entry. It would
have to have that weekly email status thing, and I think that it needs to
have some human who tries to find messages on the kernel mailing list too,
and make a first-level judgement on the bugs. Adrian was doing a good job.

But it doesn't necessarily need somebody with intimate knowledge of the
kernel. In fact, almost everybody who *does* have intimate knowledge tends
to have so in a very specific area (nobody knows everything - and that
very much includes people like me and Andrew too) and maybe be skewed in
other ways too, so a "generalist" is probably more useful than somebody
who is a "deep coder" in some subsystem.

And it almost certainly doesn't have/prefer to be _one_ person. I suspect
that this is something where it actually might be better to have some
collection of people interested in it, and yes, perhaps editing a wiki is
part of the process, but with at least that "automated email" thing going
on in additin (and it needs to go to the people involved, not just the
kernel mailing list - so part of it is not just gathering the reports
themselves, but also gathering target addresses from MAINTAINERS files and
perhaps git logs etc).

And yes, it's quite possibly a good way to get into kernel development -
it definitely helps to know about programming, but as mentioned, I don't
think it is something where you even need to know specifically about
*kernel* programming per se.

For example, I don't think it was an accident that Adrian (who has been
involved in kernelnewbies, janitors and the trivial tree) was the one who
picked it up. That's exactly the kind of involvement that the regression
tracking is all about!

(In fact, I think regression tracking might be "easier" to get into than
actually getting into some of the janitorial projects, exactly because
it's less about coding. The fact that a person who tracks regressions
might then *also* indirectly get into the code itself would just be a big
additional bonus!)

So yes, some automation can almost certainly help (especially if there are
multiple people involved), but I think a lot of it is that "human
judgement" and ability to group things and communicate. Are there any
kernel janitors/newbies/mentors that can think of people who would want to
do something like this?

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
    ... use bugzilla only for long-term bugs and avoid the needless bureaucracy. ... I put all of the reported regressions into the Bugzilla early. ... "Kernel version" given by reporter should be checked against the latest ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... stop trying to track the bleeding edge? ... on what Adrian does or stop doing. ... bugzilla or collect them into one of the a kernel.org's wiki, ... to follow the current state of all the "important" regressions. ...
    (Linux-Kernel)
  • Re: regression tracking (Re: Linux 2.6.21)
    ... The problem is not the bug tracking system, be it manual tracking in a ... Tracking regressions is not a real problem. ... I sent weekly regression reports. ... "And it's not that Linus started developing the Linux kernel with writing ...
    (Linux-Kernel)
  • Re: 2.6.0-test9 - poor swap performance on low end machines
    ... because variance in thrashing benchmarks is pretty bad). ... Problem is, ten or twenty kernel releases later, you can't easily ... * We don't want to kill a process with direct hardware access. ... several, independant regressions. ...
    (Linux-Kernel)
  • Re: RFC: Starting a stable kernel series off the 2.6 kernel
    ... > we've regressed until after a kernel update is in the end-users hands. ... user-space component foo to be at least x.y.z if feature bar is used" ... Regressions will always occur when driver updates happen. ...
    (Linux-Kernel)