FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 03-22-2008, 06:59 PM
Bill Davidsen
 
Default Bug backlog - now and future. Some proposals.

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.



--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-23-2008, 04:52 AM
"Jon Stanley"
 
Default Bug backlog - now and future. Some proposals.

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).

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-23-2008, 05:10 AM
"Jon Stanley"
 
Default Bug backlog - now and future. Some proposals.

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.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-23-2008, 05:14 AM
"Jon Stanley"
 
Default Bug backlog - now and future. Some proposals.

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.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-23-2008, 05:50 AM
Tim
 
Default Bug backlog - now and future. Some proposals.

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.

--
(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-23-2008, 05:11 PM
Bill Davidsen
 
Default Bug backlog - now and future. Some proposals.

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.


--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-23-2008, 05:11 PM
Bill Davidsen
 
Default Bug backlog - now and future. Some proposals.

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.


--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-24-2008, 06:08 AM
Tim
 
Default Bug backlog - now and future. Some proposals.

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.

--
(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 11:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org