Hear ye, hear ye! At the BugZappers meeting that occurred today, March 12, 2008, two proposals for dealing with the backlog of bugs, both now and in the future, were discussed. It was also discussed that this would be another useful forum to solicit feedback from. Our goal here is not to disenfranchise bug reporters or cause them more work. Instead, it is designed to introduce predictability into the lifecycle of a bug. This is part of the relaunch of the BugZappers initiative, which I had announced yesterday. It's important to note, that while you're just now starting to see stuff from us visibly, this has been several months in the making and thought through very thoroughly.
These proposals will be presented at the meeting of the Fedora Engineering Steering Committee (FESCo) tomorrow, with a vote to be rendered on 2008-03-20 if necessary, and execution to begin shortly thereafter. Please feel free to make comments by replying to this e-mail or editing the wiki. We also hang out in #fedora-qa on freenode (my nick is jds2001), and our mailing list is fedora-test-list@redhat.com for other ways to make contact with us.
The purpose of the meeting today was to solicit input on proposals for dealing with the current unmanageable backlog of bugs. In the long term, this backlog will cause Fedora irreparable harm, if it has not already. Our most valuable asset, the bug reporter, is feeling left out in the cold. Community triagers feel discouraged by what they see as a insurmountable task, thereby making the problem feed on itself. We have to act, and the time to do it is now.
To that end, I am proud to present two proposals, One has to do with dealing with the backlog that we have now, and the other has to do with making sure we never get into this situation again -- ever. We believe that these proposals are the right thing to do, and now is the right time to do them, right before a release.
I'd also like to give credit where it's due for these proposals. The primary author of both of them is John Poelstra, without whom many of the things that have been accomplished to date would not have been. In just a few short months, we've gone from having almost nothing formalized to having a formal bug workflow, and having formal plans of dealing with the backlog, both now and in the future.
It's important to note that these are PROPOSALS at the current time, and have not been approved in any way. I am expecting, and welcome, impassioned debate on these proposals. In the course of these debates, however, lets be civil with one another - we're allresponsible adults here. If you have comments or concerns about either of the proposals, there's a comments section at the bottom of both of them on the wiki, which I encourage you to use. Also, please come to the meeting and/or reply to this e-mail if you have comments. Please try to back up changes to the proposals with a specific example of where the proposed action is wrong/bad/whatever, and what could be done differently to alleviate the concern.
Also note that the framework of the proposals is there. The exact text to be found in bugs is still yet to be written, however that will be written in the next week or so. I realize that both this introduction and the proposals themselves are extremely long, but please read them! The wiki versions of these proposals can be found at:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
On Wed, 2008-03-12 at 14:32 -0400, Jon Stanley wrote:
Hear ye, hear ye! At the BugZappers meeting that occurred today, March 12, 2008, two proposals for dealing with the backlog of bugs, both now and in the future, were discussed. It was also discussed that this would be another useful forum to solicit feedback from. Our goal here is not to disenfranchise bug reporters or cause them more work. Instead, it is designed to introduce predictability into the lifecycle of a bug. This is part of the relaunch of the BugZappers initiative, which I had announced yesterday. It's important to note, that while you're just now starting to see stuff from us visibly, this has been several months in the making and thought through very thoroughly.
These proposals will be presented at the meeting of the Fedora Engineering Steering Committee (FESCo) tomorrow, with a vote to be rendered on 2008-03-20 if necessary, and execution to begin shortly thereafter. Please feel free to make comments by replying to this e-mail or editing the wiki. We also hang out in #fedora-qa on freenode (my nick is jds2001), and our mailing list is fedora-test-list@redhat.com for other ways to make contact with us.
The purpose of the meeting today was to solicit input on proposals for dealing with the current unmanageable backlog of bugs.
Simple. slow down the cycle of new releases until the previous one is stable, while new updates arrive to be tested, as usual. Everyone on the list freely contributes what they know, it just takes awhile to catch up to you guys and gals.
If at all possible, get the real Java installed if the new licensing scheme is finally in place. That alone might quell some of the bugs related to Java. My two cents, Ric
On Thu, Mar 13, 2008 at 9:41 PM, Ric Moore wayward4now@gmail.com wrote:
On Wed, 2008-03-12 at 14:32 -0400, Jon Stanley wrote:
Hear ye, hear ye! At the BugZappers meeting that occurred today, March 12, 2008, two proposals for dealing with the backlog of bugs, both now and in the future, were discussed. It was also discussed that this would be another useful forum to solicit feedback from. Our goal here is not to disenfranchise bug reporters or cause them more work. Instead, it is designed to introduce predictability into the lifecycle of a bug. This is part of the relaunch of the BugZappers initiative, which I had announced yesterday. It's important to note, that while you're just now starting to see stuff from us visibly, this has been several months in the making and thought through very thoroughly.
These proposals will be presented at the meeting of the Fedora Engineering Steering Committee (FESCo) tomorrow, with a vote to be rendered on 2008-03-20 if necessary, and execution to begin shortly thereafter. Please feel free to make comments by replying to this e-mail or editing the wiki. We also hang out in #fedora-qa on freenode (my nick is jds2001), and our mailing list is fedora-test-list@redhat.com for other ways to make contact with us.
The purpose of the meeting today was to solicit input on proposals for dealing with the current unmanageable backlog of bugs.
Simple. slow down the cycle of new releases until the previous one is stable, while new updates arrive to be tested, as usual. Everyone on the list freely contributes what they know, it just takes awhile to catch up to you guys and gals.
If at all possible, get the real Java installed if the new licensing scheme is finally in place. That alone might quell some of the bugs related to Java. My two cents, Ric
--
My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. Linux user# 44256 Sign up at: http://counter.li.org/ http://www.sourceforge.net/projects/oar http://www.wayward4now.net <---down4now too ================================================
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Personally i think the release cycle is to short. Can someone explain to me why a new version has to come out every six or seven months? Shouldn't there be a long term release? I actually don't mind that much but i always wondered about that, it has got to a major pain in the ass or maybe not but i'd still like to hear the reasoning behind it.
max bianco wrote:
Personally i think the release cycle is to short. Can someone explain to me why a new version has to come out every six or seven months? Shouldn't there be a long term release? I actually don't mind that much but i always wondered about that, it has got to a major pain in the ass or maybe not but i'd still like to hear the reasoning behind it.
In order to advance progress for the releases a short life cycle is needed to ensure programs do not remain static and outdated. Some of the refined programs that change just for the sake of change are annoying but overall the short cycles are just fine if you want some reprieve from the development cycle. You have about a year for each release support expires which sounds like plenty of time to move up release cycles.
I prefer the constantly moving rawhide so I do not find release cycles as that important. I am one release back on a server installation but Fedora 8 and its upgrade limitations discouraged me from bothering with making a dvd and upgrading.
Jim
Small comments thru the text, rant follows.
Jon Stanley wrote:
Hear ye, hear ye! At the BugZappers meeting that occurred today, March 12, 2008, two proposals for dealing with the backlog of bugs, both now and in the future, were discussed. It was also discussed that this would be another useful forum to solicit feedback from. Our goal here is not to disenfranchise bug reporters or cause them more work. Instead, it is designed to introduce predictability into the lifecycle of a bug. This is part of the relaunch of the BugZappers initiative, which I had announced yesterday. It's important to note, that while you're just now starting to see stuff from us visibly, this has been several months in the making and thought through very thoroughly.
These proposals will be presented at the meeting of the Fedora Engineering Steering Committee (FESCo) tomorrow, with a vote to be rendered on 2008-03-20 if necessary, and execution to begin shortly thereafter. Please feel free to make comments by replying to this e-mail or editing the wiki. We also hang out in #fedora-qa on freenode (my nick is jds2001), and our mailing list is fedora-test-list@redhat.com for other ways to make contact with us.
The purpose of the meeting today was to solicit input on proposals for dealing with the current unmanageable backlog of bugs. In the long term, this backlog will cause Fedora irreparable harm, if it has not already. Our most valuable asset, the bug reporter, is feeling left out in the cold. Community triagers feel discouraged by what they see as a insurmountable task, thereby making the problem feed on itself. We have to act, and the time to do it is now.
I agree that the backlog of unsolved bugs is seriously hurting user perceptions.
To that end, I am proud to present two proposals, One has to do with dealing with the backlog that we have now, and the other has to do with making sure we never get into this situation again -- ever. We believe that these proposals are the right thing to do, and now is the right time to do them, right before a release.
I would suggest that the time to fix them is now, *instead* of a release. To clear the backlog by *fixing* the bugs, not by writing clever scripts to mark them CLOSED:WONTFIX or send notes to bug submitters to update the version to keep the bug open (unfixed) for another two releases.
I'd also like to give credit where it's due for these proposals. The primary author of both of them is John Poelstra, without whom many of the things that have been accomplished to date would not have been. In just a few short months, we've gone from having almost nothing formalized to having a formal bug workflow, and having formal plans of dealing with the backlog, both now and in the future.
It's important to note that these are PROPOSALS at the current time, and have not been approved in any way. I am expecting, and welcome, impassioned debate on these proposals. In the course of these debates, however, lets be civil with one another - we're allresponsible adults here. If you have comments or concerns about either of the proposals, there's a comments section at the bottom of both of them on the wiki, which I encourage you to use. Also, please come to the meeting and/or reply to this e-mail if you have comments. Please try to back up changes to the proposals with a specific example of where the proposed action is wrong/bad/whatever, and what could be done differently to alleviate the concern.
Also note that the framework of the proposals is there. The exact text to be found in bugs is still yet to be written, however that will be written in the next week or so. I realize that both this introduction and the proposals themselves are extremely long, but please read them! The wiki versions of these proposals can be found at:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
I read them, and I find lots of ways to make unfixed bugs exit bugzilla, but no indication that bugs will actually be fixed in a more timely fashion.
I think you need a "deadline scheduler" approach, if a bug in a package isn't fixed by some (reasonable) time after it's reported, it should be evaluated, and unless it's waiting on external info it should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a separate group in the next release, the way "extras" used to be.
I believe that maintainers would be motivated to avoid having their packages marked UNMAINTAINED, and if they aren't, the description is accurate. You would hate to drop a package, but having one with serious bugs is worse. You can define "serious" any way you want, users know "doesn't work" when they report it.
In other words, if the package is still usable by most users, document the bug as trivial and live with it, and if a major bug isn't fixed, the reason doesn't matter. Developers enjoy adding new features more than bug fixing, or become too busy to maintain. Good intentions are nice, but they don't buy you a beer.
On Fri, 2008-03-14 at 20:41 -0400, Jim Cornette wrote:
In order to advance progress for the releases a short life cycle is needed to ensure programs do not remain static and outdated.
I do not agree. Programs can advance and change, without the OS having to change. OS and applications are separate things.
Some of the refined programs that change just for the sake of change are annoying but overall the short cycles are just fine if you want some reprieve from the development cycle. You have about a year for each release support expires which sounds like plenty of time to move up release cycles.
I don't agree with this either. For instance, the people maintaining some applications, such as Evolution, have flatly refused to fix some faults [1] with it in a current release (FC7). Their answer is you'll have to use the next Fedora release (FC8). For some people this just isn't practical, whether that simply is the hassles of changing a whole OS to suit one application, or because that release doesn't work for you on the whole.
That attitude can mean that some software never works. The current release is always broken, with fixes only being applied to a future version.
1: One of them being that Evolution crashes if you try to use the date picker when setting up filters or search folders.
Tim wrote:
On Fri, 2008-03-14 at 20:41 -0400, Jim Cornette wrote:
In order to advance progress for the releases a short life cycle is needed to ensure programs do not remain static and outdated.
I do not agree. Programs can advance and change, without the OS having to change. OS and applications are separate things.
Maybe each final release should follow the no changes to the OS and only upgrade applications except for security updates for the OS. That would be a good experiment to see how well it goes. Then rawhide could be where OS advancements are handled beforete next release cycle.
Some of the refined programs that change just for the sake of change are annoying but overall the short cycles are just fine if you want some reprieve from the development cycle. You have about a year for each release support expires which sounds like plenty of time to move up release cycles.
I don't agree with this either. For instance, the people maintaining some applications, such as Evolution, have flatly refused to fix some faults [1] with it in a current release (FC7). Their answer is you'll have to use the next Fedora release (FC8). For some people this just isn't practical, whether that simply is the hassles of changing a whole OS to suit one application, or because that release doesn't work for you on the whole.
That attitude can mean that some software never works. The current release is always broken, with fixes only being applied to a future version.
I was thinking in particular to gdm changing in my view simply to change. The current state of gdm for development is pretty bad. I felt things worked well as a login manager without the fading and transition goodies that were added to later versions. I haven't use evolution since one of the earlier phases of red carpet or its preceding gdm alternative desktop sources. Of course that has nothing to do with needing to upgrade to a newer release in order to get advancements. Maybe going to a go.gnome, redcarpet or whatever there used to be needs to be reimplemented for desktops for alternative sources of upstream desktop sources.
1: One of them being that Evolution crashes if you try to use the date picker when setting up filters or search folders.
I wouldn't know since I left Evolution back when the monkey twirled around in that chair during updates.
Jim
Bill Davidsen wrote, On 03/15/2008 05:37 PM:
Small comments thru the text, rant follows.
Jon Stanley wrote:
Hear ye, hear ye! At the BugZappers meeting that occurred today, March 12, 2008, two proposals for dealing with the backlog of bugs,
<SNIP>
To that end, I am proud to present two proposals, One has to do with dealing with the backlog that we have now, and the other has to do with making sure we never get into this situation again -- ever. We believe that these proposals are the right thing to do, and now is the right time to do them, right before a release.
I would suggest that the time to fix them is now, *instead* of a release. To clear the backlog by *fixing* the bugs, not by writing clever scripts to mark them CLOSED:WONTFIX or send notes to bug submitters to update the version to keep the bug open (unfixed) for another two releases.
<SNIP>
http://fedoraproject.org/wiki/BugZappers/HouseKeeping http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
I read them, and I find lots of ways to make unfixed bugs exit bugzilla, but no indication that bugs will actually be fixed in a more timely fashion.
I think you need a "deadline scheduler" approach, if a bug in a package isn't fixed by some (reasonable) time after it's reported, it should be evaluated, and unless it's waiting on external info it should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a separate group in the next release, the way "extras" used to be.
I believe that maintainers would be motivated to avoid having their packages marked UNMAINTAINED, and if they aren't, the description is accurate. You would hate to drop a package, but having one with serious bugs is worse. You can define "serious" any way you want, users know "doesn't work" when they report it.
In other words, if the package is still usable by most users, document the bug as trivial and live with it, and if a major bug isn't fixed, the reason doesn't matter. Developers enjoy adding new features more than bug fixing, or become too busy to maintain. Good intentions are nice, but they don't buy you a beer.
+1, to a point.
If the "maintainer" has (reasonably) asked for more information and it has been 1 release with no more information coming in, _then_ it would be reasonable to close the bug.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Todd Denniston wrote: | Bill Davidsen wrote, On 03/15/2008 05:37 PM: |> Small comments thru the text, rant follows. |> |> Jon Stanley wrote: |>> Hear ye, hear ye! At the BugZappers meeting that occurred today, |>> March 12, 2008, two proposals for dealing with the backlog of bugs, | <SNIP> |> |>> To that end, I am proud to present two proposals, One has to do with |>> dealing with the backlog that we have now, and the other has to do |>> with making sure we never get into this situation again -- ever. We |>> believe that these proposals are the right thing to do, and now is the |>> right time to do them, right before a release. |>> |> I would suggest that the time to fix them is now, *instead* of a release. To clear the backlog by *fixing* the bugs, not by writing clever scripts to mark them CLOSED:WONTFIX or send notes to bug submitters to update the version to keep the bug open (unfixed) for another two releases. |> | <SNIP> |>> |>> http://fedoraproject.org/wiki/BugZappers/HouseKeeping |>> http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver |>> |> I read them, and I find lots of ways to make unfixed bugs exit bugzilla, but no indication that bugs will actually be fixed in a more timely fashion. |> |> I think you need a "deadline scheduler" approach, if a bug in a package isn't fixed by some (reasonable) time after it's reported, it should be evaluated, and unless it's waiting on external info it should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a separate group in the next release, the way "extras" used to be. |> |> I believe that maintainers would be motivated to avoid having their packages marked UNMAINTAINED, and if they aren't, the description is accurate. You would hate to drop a package, but having one with serious bugs is worse. You can define "serious" any way you want, users know "doesn't work" when they report it. |> |> In other words, if the package is still usable by most users, document the bug as trivial and live with it, and if a major bug isn't fixed, the reason doesn't matter. Developers enjoy adding new features more than bug fixing, or become too busy to maintain. Good intentions are nice, but they don't buy you a beer. |> | | +1, to a point. | | If the "maintainer" has (reasonably) asked for more information and it has been 1 release with no more information coming in, _then_ it would be reasonable to close the bug. | | But, iff the release addressed an issue related to the bug report in the first place. Closing a bug just because you don't have any more complaints is not really a valid reason. Maybe part of the release process should be to recreate the problem and be able to prove the problem is fixed by testing!
James
On Mon, Mar 17, 2008 at 10:59 AM, James Kosin jkosin@beta.intcomgrp.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Todd Denniston wrote: | Bill Davidsen wrote, On 03/15/2008 05:37 PM: |> Small comments thru the text, rant follows. |> |> Jon Stanley wrote: |>> Hear ye, hear ye! At the BugZappers meeting that occurred today, |>> March 12, 2008, two proposals for dealing with the backlog of bugs, | <SNIP> |> |>> To that end, I am proud to present two proposals, One has to do with |>> dealing with the backlog that we have now, and the other has to do |>> with making sure we never get into this situation again -- ever. We |>> believe that these proposals are the right thing to do, and now is the |>> right time to do them, right before a release. |>> |> I would suggest that the time to fix them is now, *instead* of a release. To clear the backlog by *fixing* the bugs, not by writing clever scripts to mark them CLOSED:WONTFIX or send notes to bug submitters to update the version to keep the bug open (unfixed) for another two releases. |> | <SNIP> |>> |>> http://fedoraproject.org/wiki/BugZappers/HouseKeeping |>> http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver |>> |> I read them, and I find lots of ways to make unfixed bugs exit bugzilla, but no indication that bugs will actually be fixed in a more timely fashion. |> |> I think you need a "deadline scheduler" approach, if a bug in a package isn't fixed by some (reasonable) time after it's reported, it should be evaluated, and unless it's waiting on external info it should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a separate group in the next release, the way "extras" used to be. |> |> I believe that maintainers would be motivated to avoid having their packages marked UNMAINTAINED, and if they aren't, the description is accurate. You would hate to drop a package, but having one with serious bugs is worse. You can define "serious" any way you want, users know "doesn't work" when they report it. |> |> In other words, if the package is still usable by most users, document the bug as trivial and live with it, and if a major bug isn't fixed, the reason doesn't matter. Developers enjoy adding new features more than bug fixing, or become too busy to maintain. Good intentions are nice, but they don't buy you a beer. |> | | +1, to a point. | | If the "maintainer" has (reasonably) asked for more information and it has been 1 release with no more information coming in, _then_ it would be reasonable to close the bug. | | But, iff the release addressed an issue related to the bug report in the first place. Closing a bug just because you don't have any more complaints is not really a valid reason.
How long should it be kept open if no more information is forthcoming?
Maybe part of the release process should be to recreate the problem and be able to prove the problem is fixed by testing!
How do you know the bug is real? The person reporting the bug needs to provide enough information to reproduce the issue. What is essential info? I think a bug reporting tool that is integrated into the desktop itself is going to be required here. The tool could walk a user through the bug reporting process and maybe insure that appropriate logs are attached by default, at least we need to ensure that enough info is provided to reproduce the problem. Sometimes people report as bugs things that are not bugs and alot of time gets wasted. If we want all bugs fixed in a timely manner then we have to provide the developers the means to do so and i think that means some sort of integrated bug reporting tool that ensures that a minimum amount of info is provided for them. How many times has someone cursed the application only to find that they overlooked something simple? Everyone has their own custom setup and that can make reproducing a problem difficult.
Max
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
max bianco wrote: | | << SNIP >>
| | | | +1, to a point. | | | | If the "maintainer" has (reasonably) asked for more information and it | has been 1 release with no more information coming in, _then_ it would | be reasonable to close the bug. | | | | | But, iff the release addressed an issue related to the bug report in the | first place. Closing a bug just because you don't have any more | complaints is not really a valid reason. | | | How long should it be kept open if no more information is forthcoming? | | | | Maybe part of the release process should be to recreate the problem and | be able to prove the problem is fixed by testing! | | | How do you know the bug is real? The person reporting the bug needs to provide enough information to reproduce the issue. What is essential info? | I think a bug reporting tool that is integrated into the desktop itself is going to be required here. The tool could walk a user through the bug reporting process and maybe insure that appropriate logs are attached by default, at least we need to ensure that enough info is provided to reproduce the problem. Sometimes people report as bugs things that are not bugs and alot of time gets wasted. If we want all bugs fixed in a timely manner then we have to provide the developers the means to do so and i think that means some sort of integrated bug reporting tool that ensures that a minimum amount of info is provided for them. How many times has someone cursed the application only to find that they overlooked something simple? Everyone has their own custom setup and that can make reproducing a problem difficult. | | | Max |
Max,
I was commenting on the assumption it was a valid BUG. It is difficult if not impossible to catch everything. If a bug is or does not contain enough information then it really isn't a bug yet.
I agree we need a better method to capture the problem and provide enough information to reproduce the problem elsewhere, but whose responsibility is that. The bug reporter often either knows very little of the problem or has caused the problem himself in most cases; but, some are caused by others.... selinux security settings for example, and when fixed sometimes ILL documented in the release notes. At the same time, the user needs to keep on top of his/her bugs and update them as needed. Just ignoring a bug can lead to BAD things for both parties. The user in that the problem may not be fixed (causing issues for others in the future) or worse still the maintainer not knowing what the true bug status is.
At the same time, we shouldn't take bug reports lightly. They are difficult enough for users to write up properly, so anyone taking the time to actually write one up should be looked at carefully.
Some standard questions should be (1) post configuration files, (2) post any pertinent log files, (3) core dumps if available. At the same time, the maintainer needs to be able to provide the user a way to DEBUG the issue. Not everyone is experienced in the debugger tools or how to get a trace, or dump of any core files.
James
On Mon, Mar 17, 2008 at 12:20 PM, James Kosin jkosin@beta.intcomgrp.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
max bianco wrote: | | << SNIP >>
| | | | +1, to a point. | | | | If the "maintainer" has (reasonably) asked for more information and it | has been 1 release with no more information coming in, _then_ it would | be reasonable to close the bug. | | | | | But, iff the release addressed an issue related to the bug report in the | first place. Closing a bug just because you don't have any more | complaints is not really a valid reason. | | | How long should it be kept open if no more information is forthcoming? | | | | Maybe part of the release process should be to recreate the problem and | be able to prove the problem is fixed by testing! | | | How do you know the bug is real? The person reporting the bug needs to provide enough information to reproduce the issue. What is essential info? | I think a bug reporting tool that is integrated into the desktop itself is going to be required here. The tool could walk a user through the bug reporting process and maybe insure that appropriate logs are attached by default, at least we need to ensure that enough info is provided to reproduce the problem. Sometimes people report as bugs things that are not bugs and alot of time gets wasted. If we want all bugs fixed in a timely manner then we have to provide the developers the means to do so and i think that means some sort of integrated bug reporting tool that ensures that a minimum amount of info is provided for them. How many times has someone cursed the application only to find that they overlooked something simple? Everyone has their own custom setup and that can make reproducing a problem difficult. | | | Max |
Max,
I was commenting on the assumption it was a valid BUG. It is difficult if not impossible to catch everything. If a bug is or does not contain enough information then it really isn't a bug yet.
I agree we need a better method to capture the problem and provide enough information to reproduce the problem elsewhere, but whose responsibility is that. The bug reporter often either knows very little of the problem or has caused the problem himself in most cases; but, some are caused by others.... selinux security settings for example, and when fixed sometimes ILL documented in the release notes. At the same time, the user needs to keep on top of his/her bugs and update them as needed. Just ignoring a bug can lead to BAD things for both parties. The user in that the problem may not be fixed (causing issues for others in the future) or worse still the maintainer not knowing what the true bug status is.
At the same time, we shouldn't take bug reports lightly. They are difficult enough for users to write up properly, so anyone taking the time to actually write one up should be looked at carefully.
Some standard questions should be (1) post configuration files, (2) post any pertinent log files, (3) core dumps if available. At the same time, the maintainer needs to be able to provide the user a way to DEBUG the issue. Not everyone is experienced in the debugger tools or how to get a trace, or dump of any core files.
I think we agree on the major points. It is precisely because not everyone is an experienced debugger that I think some sort of integrated tool is required. An integrated tool that would default to attaching appropriate log info is essential. Better to much info than not enough. How many will tell on themselves if they figure out it was their fault? Not many! Most will never report back, in which case you have a bug report floating around that can never be resolved because it was never a bug to begin with....or due to inexperience on the users part it takes forever to get the required information. So some kind of bug reporting\ debugging tool is needed. I don't think you will find many objections to the idea in theory but the rub will be in how it gets implemented.
Max
Todd Denniston wrote:
Bill Davidsen wrote, On 03/15/2008 05:37 PM:
Small comments thru the text, rant follows.
Jon Stanley wrote:
Hear ye, hear ye! At the BugZappers meeting that occurred today, March 12, 2008, two proposals for dealing with the backlog of bugs,
<SNIP> > >> To that end, I am proud to present two proposals, One has to do with >> dealing with the backlog that we have now, and the other has to do >> with making sure we never get into this situation again -- ever. We >> believe that these proposals are the right thing to do, and now is the >> right time to do them, right before a release. >> > I would suggest that the time to fix them is now, *instead* of a > release. To clear the backlog by *fixing* the bugs, not by writing > clever scripts to mark them CLOSED:WONTFIX or send notes to bug > submitters to update the version to keep the bug open (unfixed) for > another two releases. > <SNIP> >> >> http://fedoraproject.org/wiki/BugZappers/HouseKeeping >> http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver >> > I read them, and I find lots of ways to make unfixed bugs exit > bugzilla, but no indication that bugs will actually be fixed in a more > timely fashion. > > I think you need a "deadline scheduler" approach, if a bug in a > package isn't fixed by some (reasonable) time after it's reported, it > should be evaluated, and unless it's waiting on external info it > should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), > or mark the package as UNMAINTAINED. Then release the UNMAINTAINED > packages as a separate group in the next release, the way "extras" > used to be. > > I believe that maintainers would be motivated to avoid having their > packages marked UNMAINTAINED, and if they aren't, the description is > accurate. You would hate to drop a package, but having one with > serious bugs is worse. You can define "serious" any way you want, > users know "doesn't work" when they report it. > > In other words, if the package is still usable by most users, document > the bug as trivial and live with it, and if a major bug isn't fixed, > the reason doesn't matter. Developers enjoy adding new features more > than bug fixing, or become too busy to maintain. Good intentions are > nice, but they don't buy you a beer. >
+1, to a point.
If the "maintainer" has (reasonably) asked for more information and it has been 1 release with no more information coming in, _then_ it would be reasonable to close the bug.
There is a status, IIRC "NEEDINFO" which puts the ball back in the reporters court. I don't object to closing some of these (an automated eMail to the submitter would be nice) if the submitter doesn't care and the maintainer isn't able to reproduce. In those cases closure would be a reasonable option.
But in the case of a reproducible problem, perhaps more effort to either fix the problem or identify the package as having slow/no bugfixes just to help people find alternatives.
I would fell that "extras" served us well, and a category for packages with unfixed serious bugs would be appropriate to informed consent. Also note the WONTFIX disposition I suggested for bugs users can avoid, or which don't prevent productive usage of an application.
First, let me apologize for not answering for a week. This is not an account that I generally watch (though I should have subscribed from the account that I *do* watch in order to post this - my fault entirely). For the record, the account that I do watch is jonstanley AT <google's popular mail service>.
On Sat, Mar 15, 2008 at 5:37 PM, Bill Davidsen davidsen@tmr.com wrote:
I would suggest that the time to fix them is now, *instead* of a release. To clear the backlog by *fixing* the bugs, not by writing clever scripts to mark them CLOSED:WONTFIX or send notes to bug submitters to update the version to keep the bug open (unfixed) for another two releases.
That would be the ideal solution. The problem is that with the pace of Fedora releases, with an older bug, we can't be sure that the reported issue has actually been fixed without any action on the part of the maintainer. Fedora frequently re-bases applications to current upstream releases, where a lot of work goes on. There is simply not the manpower to determine if the reported problem actually still exists or not.
I read them, and I find lots of ways to make unfixed bugs exit bugzilla, but no indication that bugs will actually be fixed in a more timely fashion.
Unfortunately, as a triage community, I don't think that we're in a place to do that. We think that what reporters really want is a human to acknowledge that they have reported a bug and there's a human on the other end that has evaluated it. To that end, I encourage everyone to become involved in the BugZappers project - anyone can do it. See http://fedoraproject.org/wiki/BugZappers for more.
I think you need a "deadline scheduler" approach, if a bug in a package isn't fixed by some (reasonable) time after it's reported, it should be evaluated, and unless it's waiting on external info it should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a separate group in the next release, the way "extras" used to be.
This is in theory a great idea. I don't think that we're to that point - yet. I just ran a report for bugs that were created in January (in February we had the GCC 4.3 rebuild that would skew numbers a bit). There were 1956 bugs reported against all versions of Fedora, 1219 of which are currently closed - that;s 62% of them that are fully dealt with. Seems like a good percentage to me. However, we also have 468 bugs from that time period that are in NEW that need some love.
In other words, if the package is still usable by most users, document the bug as trivial and live with it, and if a major bug isn't fixed, the reason doesn't matter. Developers enjoy adding new features more than bug fixing, or become too busy to maintain. Good intentions are nice, but they don't buy you a beer.
There's the old saying "don't attribute to malice that which can be explained by incompetence". It's a well known fact that in Fedora, many of our package maintainers are *not* developers - they rely on upstream to actually fix any bugs that may exist (as should happen - all of our work should happen upstream - whether the Fedora maintainer actually *does* the work upstream is irrelevant).
On Sun, Mar 16, 2008 at 10:28 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2008-03-14 at 20:41 -0400, Jim Cornette wrote:
In order to advance progress for the releases a short life cycle is needed to ensure programs do not remain static and outdated.
I do not agree. Programs can advance and change, without the OS having to change. OS and applications are separate things.
Where do you draw the line here? The kernel, for example gets "lots* of updates, most of them not for the sake of the fact that we can update it, but rather that there were bugs that users reported that were fixed. Do we not fix bugs that actually exist for the sake of stability for users that have not experienced them? I hate to say it, but RHEL may be the product that you're looking for, where this exact thing happens. Between update releases, only critical/security bugs are fixed. Anything that's not a showstopper waits til the next update relasee.
I don't agree with this either. For instance, the people maintaining some applications, such as Evolution, have flatly refused to fix some faults [1] with it in a current release (FC7). Their answer is you'll have to use the next Fedora release (FC8). For some people this just isn't practical, whether that simply is the hassles of changing a whole OS to suit one application, or because that release doesn't work for you on the whole.
I can see this, to a point. Particularly with desktop apps, where the rate of evolution upstream is so fast as to not allow backporting to the earliest Fedora release supported (perhaps there were major API/ABI changes that would break consumers of content from the app, etc). I can't really comment on the desktop situation, as I personally deal more in core OS type stuff. If Matej is on the list, he can comment further on the specific desktop situation.
That attitude can mean that some software never works. The current release is always broken, with fixes only being applied to a future version.
This is the state of most FLOSS as far as upstream is concerned. In Fedora, we always have the option of upgrading to a new upstream version, which we can and do exercise freely.
On Mon, Mar 17, 2008 at 10:59 AM, James Kosin jkosin@beta.intcomgrp.com wrote:
Maybe part of the release process should be to recreate the problem and be able to prove the problem is fixed by testing!
This isn't always possible. Perhaps the problem has to do with your specific hardware that the maintainer does not have at his or her disposal to test with. Perhaps it has to do with the specifc data that you were using with the application, etc.
Jim Cornette:
In order to advance progress for the releases a short life cycle is needed to ensure programs do not remain static and outdated.
Tim:
I do not agree. Programs can advance and change, without the OS having to change. OS and applications are separate things.
Jon Stanley:
Where do you draw the line here? The kernel, for example gets "lots* of updates, most of them not for the sake of the fact that we can update it, but rather that there were bugs that users reported that were fixed. Do we not fix bugs that actually exist for the sake of stability for users that have not experienced them?
That's a different direction than the point I was countering: That some believe that applications cannot and will not progress if you don't change the OS, as well. It's a furphy. Applications can change and advance, lots, while still running on the same unchanged OS. They're two very different things.
I hate to say it, but RHEL may be the product that you're looking for, where this exact thing happens. Between update releases, only critical/security bugs are fixed. Anything that's not a showstopper waits til the next update relasee.
I have played with CentOS, but it *seems* to suffer from the problem I outlined above. People looking after the applications seem to artificially stagnate them.
I'll say it again, the OS and applications are separate things, you can advance them individually.
Jon Stanley wrote:
First, let me apologize for not answering for a week. This is not an account that I generally watch (though I should have subscribed from the account that I *do* watch in order to post this - my fault entirely). For the record, the account that I do watch is jonstanley AT <google's popular mail service>.
On Sat, Mar 15, 2008 at 5:37 PM, Bill Davidsen davidsen@tmr.com wrote:
I would suggest that the time to fix them is now, *instead* of a release. To clear the backlog by *fixing* the bugs, not by writing clever scripts to mark them CLOSED:WONTFIX or send notes to bug submitters to update the version to keep the bug open (unfixed) for another two releases.
That would be the ideal solution. The problem is that with the pace of Fedora releases, with an older bug, we can't be sure that the reported issue has actually been fixed without any action on the part of the maintainer. Fedora frequently re-bases applications to current upstream releases, where a lot of work goes on. There is simply not the manpower to determine if the reported problem actually still exists or not.
I read them, and I find lots of ways to make unfixed bugs exit bugzilla, but no indication that bugs will actually be fixed in a more timely fashion.
Unfortunately, as a triage community, I don't think that we're in a place to do that. We think that what reporters really want is a human to acknowledge that they have reported a bug and there's a human on the other end that has evaluated it. To that end, I encourage everyone to become involved in the BugZappers project - anyone can do it. See http://fedoraproject.org/wiki/BugZappers for more.
I think you need a "deadline scheduler" approach, if a bug in a package isn't fixed by some (reasonable) time after it's reported, it should be evaluated, and unless it's waiting on external info it should be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a separate group in the next release, the way "extras" used to be.
This is in theory a great idea. I don't think that we're to that point - yet. I just ran a report for bugs that were created in January (in February we had the GCC 4.3 rebuild that would skew numbers a bit). There were 1956 bugs reported against all versions of Fedora, 1219 of which are currently closed - that;s 62% of them that are fully dealt with. Seems like a good percentage to me. However, we also have 468 bugs from that time period that are in NEW that need some love.
In other words, if the package is still usable by most users, document the bug as trivial and live with it, and if a major bug isn't fixed, the reason doesn't matter. Developers enjoy adding new features more than bug fixing, or become too busy to maintain. Good intentions are nice, but they don't buy you a beer.
There's the old saying "don't attribute to malice that which can be explained by incompetence". It's a well known fact that in Fedora, many of our package maintainers are *not* developers - they rely on upstream to actually fix any bugs that may exist (as should happen - all of our work should happen upstream - whether the Fedora maintainer actually *does* the work upstream is irrelevant).
Sounds as if people not bothering to report bugs is going to continue. If no one will fix them, or check that some new upstream version will fix them, and you don't intend to stop rebasing packages or put them in some documented unfixed category even if the developer doesn't fix bugs, then what does reporting a bug do to justify the effort?
My view is that there is currently a disconnect between reporting bugs and getting them fixed, if the maintainers are the only ones who are going to do something, then the user might as well bypass Fedora and complain directly to the developer. At least that way they will know about it.
On Sun, 2008-03-23 at 14:11 -0400, Bill Davidsen wrote:
My view is that there is currently a disconnect between reporting bugs and getting them fixed, if the maintainers are the only ones who are going to do something, then the user might as well bypass Fedora and complain directly to the developer. At least that way they will know about it.
There's worth in that, but I can see one place it'll fail: You'll get the program maintainer saying that you should go and bugzilla it with Fedora, because Fedora has modified their program, and the fault's not theirs (whether true or not), or that the modifications makes it too hard to determine whether the fault is theirs or Fedora's.
Certainly, if you'd found a fault and a solution, and presented that to the maintainer, you're got much more chance of it being accepted.