Hey fellow developers
I seem to be finding lots of bugs on the kernel Bugzilla that are now
fixed , it would be great if the maintainers or bug reporters closed them.
In addition most of them , seem to from the years 2011 -2013. I have
searched through assigned ,reopened ,need info and new bug states on
the kernel Bugzilla . The bugs are up to date on assigned but the other
open states for bugs need to be cleaned up a lot. It would be great if
when you and the other maintainers have time if the bugs that are
fixed will be closed from these years that are now resolved.
Cheers ,
Nick
Do any of you use the kernel Bugzilla? If you do I was wondering if we
can clean it up.
Otherwise I was wondering were I can get an accurate list of open
bugs in the newest
kernels.
Cheers Nick
On Fri, Jun 27, 2014 at 2:11 PM, Nick Krause <[email protected]> wrote:
> Hey fellow developers
> I seem to be finding lots of bugs on the kernel Bugzilla that are now
> fixed , it would be great if the maintainers or bug reporters closed them.
> In addition most of them , seem to from the years 2011 -2013. I have
> searched through assigned ,reopened ,need info and new bug states on
> the kernel Bugzilla . The bugs are up to date on assigned but the other
> open states for bugs need to be cleaned up a lot. It would be great if
> when you and the other maintainers have time if the bugs that are
> fixed will be closed from these years that are now resolved.
> Cheers ,
> Nick
Do all of you guys even care about cleaning up bugs? If
you do it would be great if I get a reply to where I can get
a up to date list of kernel bugs.
Cheers Nick
On Fri, Jun 27, 2014 at 10:45 PM, Nick Krause <[email protected]> wrote:
> Do any of you use the kernel Bugzilla? If you do I was wondering if we
> can clean it up.
> Otherwise I was wondering were I can get an accurate list of open
> bugs in the newest
> kernels.
> Cheers Nick
>
>
> On Fri, Jun 27, 2014 at 2:11 PM, Nick Krause <[email protected]> wrote:
>> Hey fellow developers
>> I seem to be finding lots of bugs on the kernel Bugzilla that are now
>> fixed , it would be great if the maintainers or bug reporters closed them.
>> In addition most of them , seem to from the years 2011 -2013. I have
>> searched through assigned ,reopened ,need info and new bug states on
>> the kernel Bugzilla . The bugs are up to date on assigned but the other
>> open states for bugs need to be cleaned up a lot. It would be great if
>> when you and the other maintainers have time if the bugs that are
>> fixed will be closed from these years that are now resolved.
>> Cheers ,
>> Nick
On Fri, Jun 27, 2014 at 10:45:47PM -0400, Nick Krause wrote:
> Do any of you use the kernel Bugzilla? If you do I was wondering if we
> can clean it up.
> Otherwise I was wondering were I can get an accurate list of open
> bugs in the newest
> kernels.
Some subsystem maintainers use the kernel bugzilla. Others do not.
How they use it is also highly variable. For example, bugs that are
filed with the ext4 component cause mail to be sent to the linux-ext4
mailing list, and replies automatically end up in the bugzilla log.
We use the ext4 bugzilla as a record of the bug, and we'll have a
pointer to the kernel bugzilla URL with the fix. But we don't always
close out the bug. Sometimes a few kernel developers will do some
cleanup, but it's not something that done regularly.
Also note that many bugs are never filed via the bugzilla, and are
reported via the mailing list. So if you want a full and complete
list of open bugs --- sorry, there is no such thing.
- Ted
On Sat, Jun 28, 2014 at 12:06:15PM -0400, Nick Krause wrote:
> Do all of you guys even care about cleaning up bugs? If
> you do it would be great if I get a reply to where I can get
> a up to date list of kernel bugs.
We care about fixing bugs. Most kernel devs don't really care about
maintaining a list of kernel bugs or closing out bugs in bugzilla.
Why do you want an up to date list of kernel bugs?
- Ted
On Fri, 27 Jun 2014 22:45:47 -0400
Nick Krause <[email protected]> wrote:
> Do any of you use the kernel Bugzilla? If you do I was wondering if we
> can clean it up.
Developers are generally focussed on fixing bugs. Also the way bugzilla
works a lot of developers don't close the bugs and the originators never
get around to it.
Now if you want to clean up bugzilla then what would be really useful
(and probably quite tedious) is a list of all the bugs which end either in
- confirmation it is fixed, but the bug is not closed
- confirmation that it cannot be reproduced, but the bug is not closed
- with a question asking for more information which has had no reply in
say 3 months
Given lists of bugs in those categories I can then go and zap them.
Alan
Thanks that's fine , I am new to kernel work , so a list of bugs would
be very helpful in my helping out with debugging.
Cheers Nick
On Sat, Jun 28, 2014 at 3:18 PM, One Thousand Gnomes
<[email protected]> wrote:
> On Fri, 27 Jun 2014 22:45:47 -0400
> Nick Krause <[email protected]> wrote:
>
>> Do any of you use the kernel Bugzilla? If you do I was wondering if we
>> can clean it up.
>
> Developers are generally focussed on fixing bugs. Also the way bugzilla
> works a lot of developers don't close the bugs and the originators never
> get around to it.
>
> Now if you want to clean up bugzilla then what would be really useful
> (and probably quite tedious) is a list of all the bugs which end either in
>
> - confirmation it is fixed, but the bug is not closed
>
> - confirmation that it cannot be reproduced, but the bug is not closed
>
> - with a question asking for more information which has had no reply in
> say 3 months
>
> Given lists of bugs in those categories I can then go and zap them.
>
> Alan
>Why do you want an up to date list of kernel bugs?
Even I'm a newbie and was looking for the same thing. I read
eventually somewhere that bugzilla isn't maintained by kernel devs so
I entirely gave up trying to find a bug to adopt.
Many open source projects I've worked on (web frameworks mostly) have
a well maintained list of bugs and tag the right ones "newbie" or
"beginner suitable" and newbies can learn the ropes and get started
easy. Even chromium has a "GoodFirstBug" tag for newbies.
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.
Thanks @Nick for bringing this up. I would love to help you clean up
the bugs, give me an email of any ideas you have on how to start.
Regards,
Gideon
On Sun, Jun 29, 2014 at 8:34 AM, Nick Krause <[email protected]> wrote:
> Thanks that's fine , I am new to kernel work , so a list of bugs would
> be very helpful in my helping out with debugging.
> Cheers Nick
>
> On Sat, Jun 28, 2014 at 3:18 PM, One Thousand Gnomes
> <[email protected]> wrote:
>> On Fri, 27 Jun 2014 22:45:47 -0400
>> Nick Krause <[email protected]> wrote:
>>
>>> Do any of you use the kernel Bugzilla? If you do I was wondering if we
>>> can clean it up.
>>
>> Developers are generally focussed on fixing bugs. Also the way bugzilla
>> works a lot of developers don't close the bugs and the originators never
>> get around to it.
>>
>> Now if you want to clean up bugzilla then what would be really useful
>> (and probably quite tedious) is a list of all the bugs which end either in
>>
>> - confirmation it is fixed, but the bug is not closed
>>
>> - confirmation that it cannot be reproduced, but the bug is not closed
>>
>> - with a question asking for more information which has had no reply in
>> say 3 months
>>
>> Given lists of bugs in those categories I can then go and zap them.
>>
>> Alan
> --
> 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/
Hi,
[Why was stable on Cc?]
On 06/29/2014 08:33 AM, Gideon D'souza wrote:
>> Why do you want an up to date list of kernel bugs?
>
> Even I'm a newbie and was looking for the same thing. I read
> eventually somewhere that bugzilla isn't maintained by kernel devs so
> I entirely gave up trying to find a bug to adopt.
>
> Many open source projects I've worked on (web frameworks mostly) have
> a well maintained list of bugs and tag the right ones "newbie" or
> "beginner suitable" and newbies can learn the ropes and get started
> easy. Even chromium has a "GoodFirstBug" tag for newbies.
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.
The kernel is old, and hence most of the JuniorJobs (as KDE calls them)
are either already fixed, or fixed right on the spot when they are discovered.
>
> 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.
>
> Thanks @Nick for bringing this up. I would love to help you clean up
> the bugs, give me an email of any ideas you have on how to start.
>
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.
I tend to think that even if we clean up the bugzilla, it will only be a
question of time until it gets to the state that it is in now.
Thanks,
Levente Kurusa
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
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 <[email protected]> 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
On Sun, Jun 29, 2014 at 10:09:35PM -0400, Nick Krause wrote:
> 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.
Kindly please reread my message below, because I'm not sure you've
fully absorbed what I am saying, and so your reply doesn't seem to
follow.
If you want to do it, feel free to try to maintain such a list. You
can even keep it in a wiki someplace. However, it's not something
which is generally viewed as adding a huge amount of value, so just as
it wouldn't be fair to try to pressure you to try to do this work,
it's also not going to be particularly fair to ask other developers to
try to help you in this work. Well, you can ask, but if they say no,
you need to respect that.
Given that it's not clear that the list is going to be of much value
or be kept up to date (in fact, historical evidence regarding such
tracking files, whether it is for a deprecation schedule or anything
else is that it will very quickly go out of date), it's probably not a
good reason to try to maintain it inside the kernel source. It will
just invite people who expect it to be up to date to kvetch and whine
on the kernel mailing list.
Best regards,
- Ted
> On Sun, Jun 29, 2014 at 5:32 PM, Theodore Ts'o <[email protected]> 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