Re: Upcoming Debian Releases
On Wed, 8 Jan 1997, Brian C. White wrote:
> > Bug age is not an appropriate designator of critical.
>
> You're right, it's not. There is, however, no reason for a bug to
> sit unanswered for 3 months, let alone 12! Would it be better if I
> split it into two groups: "critical" and "really should have been
> fixed by now"?
I can only agree with you first sentance, the rest is declarative without
being constructive. Yes, there are reasons for bugs to go unanswered
"forever"! No, it would be better to have an objective set of criterion
for deciding whether or not a bug is "critical".
There. Now you have my two declarative statement on the issue, so lets see
if I can provide something constructive ;-)
During my time with this group, I have from time to time complained about
some of the uses the bug list is put to. The kind members of the group
took the time to educate my on these issues and I have come to understand
that the bug reporting system for Debian is many things to many people.
One attempt at soothing that was always spoken of was the "non-punitive"
nature of the bug reporting system. All of the attempts to "tighten" up
the bug system "appear" as pinative and bureaucratic without speaking to
the nature of what "critical" means.
Maybe I'll succeed better later :-(
>
>
> > Enhancement
> > requests, design flaws requiring the upstream maintainer's concent, and
> > bugs that are currently unfixable but have work arounds, should not be
> > concidered critical and "in the way" of a release.
>
> Enhancements are seldom the responsibility of the maintainer and should
> be "forwarded". If they are the responsibility, they should either be
> done within 3 months or discarded.
>
We seem to disagree here as well. Don't forget this is an organization of
volunteers and those voluteers need to be encouraged not threatened. If we
throw away all requests for enhancements after just 3 months we will never
get a better interface for dselect, just to mention something that IS
critical and important.
> All of this software is "free" and so does _not_ require the upstream
> maintainers concent. If it is non-free or too big to be done by the
> maintainer, it should be "forwarded".
>
True, but has nothing to do with this issue. It's not a matter of knowing
where to point the finger of responsibility. Pine, for instance (no longer
my responsibility, thank you Daniel!) has several bugs against it that can
be viewed as enhancement requests that may never get addressed by the
upstream maintainer. If that bug is left in the tracking system, the
maintainer can point to it and say the the Pine Developers "Hey guys,
this really doesn't reflect well on you", and have some expectation of
moving events along. In these cases (at least for Pine) "fixing it
ourselves" is really not an option. Producing a product that claims to be
Pine but differs in some major piece of functionality (I'm thinking mainly
of "pine over-encodes my message") will cause the distribution "as a
whole" more damage than having it continue to behave as it does.
> A work-around is a fix, if not an ideal one. Mark it done or forwarded.
> The maintainer can keep a personal record of it if necessary, but it can
> be pretty well assured to be reported again once the work-around stops
> working.
>
Look at the first entry in the "problems with the 1.2 release" list.
The problem is several programs are unable to find xlib6. The "work
around" is for the user to patch up the config file and run ldconfig. I do
not consider this adequate for the removal of the bug report. This example
is, regretably, easy to fix and will, I hope not be around much longer,
much less 3 to 12 months. I can imagine, however, where the work around is
sufficient to fix the problem, but the fix can't be implimented in the
fashion the workaround was for one reason or another. (I'll leave it for
someone who is "really" bright to come up with a concrete example)
>
> > With reguard to closing bugs, Brian knows my feelings about his, properly
> > named, "nag" messages. I prioritize my limited available time for Debian
> > based on the twice weekly publication of the outstanding bugs list. I find
> > obnoxious little messages like the "nag" to be just one more annoying
> > buzzing distraction.
>
> I'm sorry, but if you can't deal with a bug in one form or another within
> three months, then you've got too much on your plate. Just think how
> obnoxious (to use your choice of words) it is to someone waiting for that
> bug to be fixed.
>
The availability of my time to this project is not dictated by the needs
of anyone outside my immediate family. We have a mechanism that allows
other maintainers, with bigger plates, to jump in and fix things that
aren't happening fast enough. We also have a firm policy of letting users
fix their own problem and provide patches of those fixes back to the
maintainer of record. I have no qualms about being obnoxious to someone
who is sitting on their own hands crying to me that I'm not fixing their
problem, while I have my hands up to the armpits in someone elses pile of
manure ;-)
>
> > > - What should we do about packages that still have "critical" bugs at
> > > release time?
> >
> > If these are identified early, and the maintainer, for one reason or
> > another, can't deal with it, we should call for volunteers to do the work.
> > As long as the fix is clear, it should be doable by release.
>
> Agreed, but that was not the question. If, at release, the work, for whatever
> reason, has _not_ been done... What should we do?
>
Line everyone up against the wall and shoot them. Then strip them of all
accrued leave and back pay, rip their lapels from their suit jackets and
make sure there is a fist sized hole in their hat, then turn them out into
the street without compunction!
(Sorry, I just couldn't resist...)
Real answer:
With proper management and planning this should never happen, however,
seeing that it has happened in the past, release it with the proper
warnings, or orphan it and remove it from the distribution. If the bug is
truely critical, then the package is as well, and the second option is not
really possible.
>
> > > * No bug reports older than 12 months at release time (bcwhite@verisim.com)
> >
> > Please, not based on time?
>
> Then what? The phase of the moon? A bug can be so marked if somebody
> reports it as serious. This is just to keep them from being forgotten about.
>
Phase of the moon? That's just another time base, no.
Determine how critical the bug is by applying some objective criterion!
Look, there are two major classes of bug: system bugs, and program bugs
(note that all system bugs can be traced to one or more program bugs).
System bugs are those that result in the system being impacted in some
unfavorable fashion (machine crashes, services go away, that kind of
stuff). Program bugs are those that only effect the opperation the one or
two application programs (like pine looses mail). Program bugs that reach
beyond the perview of their data structures to damage other things in the
system can become System bugs (for instance elm changes the permissions of
some files on an nsf mount that could be problematical to the system
hosting the mount).
As to whether a bug is critical, it should be obvious that any system bug
that makes the system either un bootable, or reasonable unusable after it
boots, should be considered critical system bugs.
As to program bugs, I considered the problem with octave segfaulting with
the new libraries as critical enough that I built a static linked version
against the old library, so there would at least be a functional program
provided by the package. I can almost guarantee that if the bug list is
analysed in this critical fashion that the list of critical bugs will be
both managable and fixable within reasonable time schedules. The release
manager should then poll the maintainers requesting completion times. A
time and motion study by the manager should make it possible to decide
what can be done and what can't. For projects that will not make the
release the manager must decide whether to dedicate more manpower (ask for
volunteers) or let the issue slide.
>
> > > - All packages to be in new source format
> >
> > This should probably be an asterisk item with higher priority. We,
> > supposidly targeted this one for the last release and only got about half
> > way there. This also might require some "floating" volunteers to get the
> > last few converted.
>
> The way I try to consider "-" vs "*" is with the question: If this has
> not been fully completed, should we consider delaying the release.
Well, I see the list of targets as "marching orders", and although this is
not an "it's broken" issue for the general user, it's bad form to leave
this design strattling the fence for too long. If you make it more visible
on the list, by making it a prominant object (with an *) it is more likely
to be acted upon than with it hidden in a long list of specific issues
that only effect specific maintainers. This is a general issue that can be
dealt with during other maintainance cycles (like upgrading to new
upstream sources) if the maintainer is aware of the need to do so.
>
> I wouldn't delay the release just because a few source packages were not
> in the correct format.
Almost no one would expect you to. That's no reason do relegate it to
"unimportant" status. This is a hold over from the last release, and I
think that that is a good objective criterion for how critical something
is. If we tried to get it done on the last release and failed, it should
become a high priority item for the next release. Yes...No?
Luck,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
------------ If you don't see what you want, just ask --------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: