[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upcoming Debian Releases



On 11 Jan 1997, Kai Henningsen wrote:

> 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?

Primarily those of the reminder or enhansement type. I have a bug against
elm that was submitted by the previous maintainer. (#2557) That was a
reminder to Carl of something he wanted to do with the package. I WILL
eventually get the more important things out of the way and get time to
track down just what was meant by the cryptic remarks found in the bug
report, but not anytime soon. I certainly don't see any reason to get all
hot and bothered by this bug report even though it may get to be ancient.

> 
> > All of the attempts to "tighten" up
> > the bug system "appear" as pinative and bureaucratic without speaking to
> > the nature of what "critical" means.
> 
> Certainly doesn't look that way to me.
Well, making up a set of rules that does not address the nature of
critical and heckles the maintainer based on those arbitrary rules
certainly does to me.

> 
> > > 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"?
> 
Nothing, when it is appropriate, I just don't think it's appropriate to
decide based on time passed. This should be based on which party gets the
responsibility of the fix. 
Certainly forwarding is of no value for Debian specific packages.

> > 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 forwarding alone is insufficient to resolve issues with some upstream
maintainers.

> 
> > > > > * 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!
> 
> 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.
> 
Only if it truely impacts your use of the product (I refer you back to my
elm example). It is the impact that makes it critical, not the time it has
been on the books.

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: