Re: An alarming trend (no it's not flaimbait.) (fwd)
On Wed, Dec 26, 2001 at 08:40:52AM +0000, David Graham wrote:
>
> On Wed, 26 Dec 2001, ahzz-debate@vmail.terrabox.com wrote:
> > For some time now there has been an increasing trend in people that
> > I know who use debian. It is the view that debian is becoming
> > increasingly "old"/outdated, and that developers either a: dont'
> > have the time to properly maintain packages, or just don't care.
>
> Does this comment apply to unstable, or just to stable? Stable being
> out-of-date is a very different problem than unstable being out-of-date...
I'm speaking of testing,frozen mainly. Way Back Then(tm) I could depend
on unstable to function better than windows. :) Alas this is no more. And
Stable looks/feels/smells like my gret grandpa. Open Source simply moves too
fast to keep a stable dist up to date. but good lord! I get visions of a mummy!
*GRIN*
>
> > However, that leaves a problem. I've been told by several developers
> > that "it's an upstream problem. send them a patch and when they
> > include it we will update". Wel, that argument doesn't work in
>
> This is only a valid excuse when upstream is active. I have often said
> something like that re. fetchmail (although it is more like: this is
> upstream's ground. If upstream agrees to do it, I will follow him. Bug
> forwarded).
*nod* In the case of upstreams, are there any metrics to approximate
how long it takes to get a bug fixed from upstream? Any kind of tools that
would allow you to manage patches so that a fix the user provides, can be
used at the debian maintainer leve until it appears from upstream? This would
alleviate the issue of slow upstream maintainers I believe...
>
> On the other hand, if a Debian developer is NOT willing to become upstream
> for a package that is being badly maintained upstream, he should orphan that
> package, and maybe even request its removal from the archive if the package
> state is really bad.
Agreed. Completely. :) Sadly, this is not the case. Debian has a case
of Scales. ;-P packages dried up and flaking off, like CDRToaster (My current
target to pick on to keep things centered...)
>
> > the debian packagers problem. If they are unwilling or unable to fix
> > it, then the package should be marked as "BAD" or "dead-upstream" as
>
> Some would even say the package should have a bug filled, severity important
> (or higher): "WARNING: package not being maintained actively". Which should
> be closed by the maintainer, when he comes back from lala-land, or when it
> is handled over to someone else.
This sounds like a good idea. I have heard murmurs of packages getting
tossed that have severe and critical bugs before a release. However, Is it
logical to apply this same measure to packages in testing that sit with a CRIT
or SEVERE bug status of one or more bugs for an extended period of time?
It does no good to toss things out at the end. I believe that curing
the root of the problem before it interferes with the life of the distro is
the proper method of treating the problem. By kicking a package back into
unstable when it has CRIT bugs for more than a few days, debian can keep
testing clean enough to make a MUCH shorter bug-fix-fest and release cycle.
This is mostly due to nailing these critters as they pop up and don't get
resolved before they acumulate and cause a 6-month long frozen period.
>
> <wears QA hat>Please file such a bug against that CD recoding package. If
> the maintainer complains that he is 'actively maintaining' it, tell him to
> stop lying to himself and admit he either needs to become upstream and fix
> all bugs, or drop the package (and keep the bug open)</wears QA hat>
Aye Aye Captain! ;) 9 times out of ten, i'm beaten to the bug report.
heh. So I loose interest in chasing every one due to believing someone else
has probably reported it allready.
This is a flaw in MY method that I shall strive to change.
>
> > a warning to the user that they should pick a different utility like
> > this one to use.
>
> This is actually a good idea. One can use the BTS to file bugs (I suggest
> bug severity to be either "important", or if the package is too sorry a
> state, "grave" -- but do be very sure of what you're doing if you file a
> "grave" bug).
See above about filing bugs. Guilty your honour. ;)
>
> However, do expect to be yelled at if you misfile any such bugs, a lot of
> maintainers will not like that at all. You have been warned.
Heh. I got yelled at for suggesting someone add a 1 liner to the deb
.diff once or twice. ;-P I fear not overfiend, why shall I fear a Lesser
Evil? *duck*
>
> > Ok, this has gotten long enough. I'm proposing as a user that you
> > (debian et al) find a way to somehow warn the user that this package
> > is dead upstream and that bugs aren't likely to get fixed if the
> > maintainer is unwilling/able to fix it. I am also proposing that it
>
> Right now, using the BTS properly you could do suck marking of packages
> without any extra tools. I expect such packages to be dropped at release
> time if they are really unmaintained.
*nod* now where on my calendar can I allocate 2 weeks to pumping up the bug stats. ;) I'll file them as I can and find them.
>
> > be required of a maintainer that they have at least a rudimentary
> > ability to fix minor bugs like this.
>
> I believe most maintainers already take that view. Those who don't, really
> should know better.
I guess i've managed to hit a cross section f developers that don't
agree with either of us. 8-\ There are quite a few good packages...
>
> > It is my opinion that if you are putting your name to somethign that
> > you are providing for download, you are implying that you have
> > accepted responsibility for the quality of the software.
>
> Indeed. I would like to point out, however, that this applies to the
> package level too. If someone maintains a package, and uploads it to Debian,
> he better be ready to stand behind the quality of his work. Otherwise, he
> should either improve that packaging fast, or get lost (and please orphan
> his packages properly while at it).
>
> 'Thank you for all the fishes, do come back when you have the proper skill
> level and/or amount of spare time to actually maintain your Debian packages'
> may be a harsh thing to say; it looks elitist, even. But it is the best
> thing to do from a QA (and therefore, an user's) point of view, IMHO. Heck,
> one does not even need to leave the project, just take an extended vacation
> (BUT FOLLOW THE PROPER PROCEDURE FOR DOING SO, thank you), and come back
> later, as many have done in the history of the project.
Something this harsh may very well be needed. Some of the staff at
OPN have reached this level of frustration with things there as well and
have walked due to a lack of serious listening or solutions. A project is
no better than average of it's members abilities IMHO.
An interesting side note here. One of my main beefs with *BSD
distros is that the developers are TOO eleetist. You can't get in to
actualy contribute without being a Coding God(tm). ;-P That is too far.
Maybe they should simply have thier ID flagged to be reviewed by a
fellow developer that acts as a mentor?
>
> > system of packaging volunteers that have NO responsibility for
>
> I (along with many others) will fight using deadly weaponry to avoid such an
> fate. We need responsible maintainers in Debian, not packagers that go
> their merry way leaving the distro littered with outdated and often broken
> crap.
Aye, and I as a user will wave my Clue Bat(tm) as forcefully as
required and as frequently as required at developer heads that I have
contact with that don't believe that quality matters. I just wish I had the
time and the skills to make debian better. *sigh*
>
> --
> "One disk to rule them all, One disk to find them. One disk to bring
> them all and in the darkness grind them. In the Land of Redmond
> where the shadows lie." -- The Silicon Valley Tarot
> Henrique Holschuh
heh. cute. Need to see that movie. "Lord of The Valley"
>
--
--------------------------------------------------------------------------------
Brian Wolfe <brianw@terrabox.com> "Down to earth computing!"
TerraBox.com Fingerprint: 2849 5090 D4E0 2A6C C648 A750 52F8 8504 67DB 205C
Reply to: