Re: Upcoming Debian Releases
> dwarf@polaris.net (Dale Scheetz) wrote on 08.01.97 in <[🔎] Pine.LNX.3.95.970108133949.1926B-100000@dwarf.polaris.net>:
>
> > Yes, there are reasons for bugs to go unanswered "forever"!
>
> Which?
Bugs which are legitimate requests for enhancement, but don't affect the
basic operation of a package.
Bugs which affect a minor point of operation, but doesn't seem to affect
normal operation (example: There were a series of bugs dealing with how
the echo command handled write failures, filed for each of the shells
with built-in echo's, and with /bin/echo. The bug report is still open
for tcsh (bug#820), but except for the fact that the bug is over 21
months old, isn't critical IMO).
IMHO, bugs that have been forwarded upstream should -not-, by default,
be safe from being critical (Imagine the sendmail-hole-of-the-week being
dealt with by simply forwarding the bug report upstream, and waiting for
the next release?), but many bugs that are can go unfixed indefinately.
I feel that no bug should go unanswered indefinately; they should at
least be acknowledged by the maintainer. On the otherhand, there are
some bugs that should remain uncritical indefinately.
Critical bugs, IMHO, are showstoppers. A minor bug, even if it has been
around a year or more, shouldn't be a showstopper.
> > > 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.
>
> So what's wrong with "forwarded"?
Should Chris Lameter forward upstream enhancement requests for debmake
to take those requests of the critical list?
Again, I think "forwarded" and "critical" should be orthogonal.
>
> > 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
>
> That only works if it _is_ forwarded.
But then, right now, that takes bugs off the critical list, which isn't
(IMHO) always correct. In fact, I don't think there is any automated
listing of bugs forwarded but not fixed. I think it is currently a
forward-and-forget operation, which is IMHO, bad.
>
> > > > > * No bug reports older than 12 months at release time
> > > > > (bcwhite@verisim.com)
> > > >
> > > > Please, not based on time?
> >
> > Determine how critical the bug is by applying some objective criterion!
>
> Time *is* an objective criterion. And, strictly as a user, I'll definitely
> say that the older a bug is, the more critical it is. Even a fairly small
> bug can get extremely obnoxious if nothing is done about it.
>
How about this idea:
Attach to each bug a critical-on: field, that holds a date.
On new bug reports, this is defaultsto some date between 3 and 12 months
(either a fixed time frame, or 1 month before the next planned
Debian release, or something similar). The maintainer can change this
field, if necessary, to reflect how critical -he- thinks the bug is.
Perhaps it could be set so that the maintainer can't set it forward more
than one release, so that the maintainer would get nagged at least
once every 3 months about it. I do -not- feel that forwarding should
clear this field -- some bugs should be both forwarded -and- be
showstoppers until fixed somehow.
This means that every bug requires some sort of maintenance on a
periodic basis so it doesn't become critical. If that maintenance isn't
done, then either a new maintainer should be chosen or a package
withdrawn.
Yes, time is an objective criteria. But it -should- be a flexible
objective criteria.
Other objective criteria:
1) Does it cause the system to crash?
2) Does it cause the program to crash in reasonable operation?
3) Does it cause a security problem for the system?
4) Does it cause a violation of critical Debian policies?
a) Does it break the free/non-free distinction?
b) Does it cause a dependancy problem?
1) Does it depend on a non-existant package?
2) Does it depend on a less important package?
3) Does it depend on a less free package?
5) Does it depend on a package which it shouldn't?
4) Does it -not- depend on a package which it should?
c) Does it break installation?
d) etc.
(Note, some of these "objective" criteria are somewhat subjective. What
are "critical Debian policies"? What is "reasonable operation"? But
over all, I think they might be considered fairly objective.)
>
> MfG Kai
>
>
> --
> 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
>
--
Buddha Buck bmbuck@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
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: