On Sunday 14 September 2003 19:53, Steve Langasek wrote:
> On Sun, Sep 14, 2003 at 07:38:27AM +0000, benfoley wrote:
> > and steve's untenable position that users' ignorance is their fate.
> That is a gross misstatement of my actual position.
but that's how your position comes across. sorry if my definition burns you.
> > i frankly find it baffling that manoj has had to struggle as hard as
> > he has to have the rest of you accept a point that is so blatantly
> > plain and obvious.
> I do not, in fact, object to efforts to improve the quality of
> descriptions in the distribution. Indeed, I believe that improving
> package descriptions is a valuable activity *in its own right*,
> regardless of what Policy says on the question; which, given how weak
> Policy's standard actually is, is effectively the *only* incentive for
> fixing most of the bugs that are part of this mass-filing.
could you perhaps extrapolate somewhat on *in its own right,*
and why or how that can be distinguished as apart from what policy says. or
are you proposing a new policy, or, at least, an addendum to existing policy?
if so, do us all the favor of allowing the rest of us a degree of
acquaintance with the alternatives you're inclined to propose. even better,
justify why you think your variations should have more significance than that
which is extant.
> Given that the basis for these bugs does not lie with Policy, therefore,
> the 'important' severity with which they were filed is overinflated.
but policy, 5.7.1, clearly states:
The description field needs to makes sense to anyone, even people who have no
idea about any of the things the package deals with.
if manoj, who is hardly a novice, can express confusion with a package
description that he encounters, then that section of policy has obviously
been ignored by the packager; and, furthermore, if the description doesn't
suffice for even one user, much less a contributing developer, then that
aspect of the package, for which the package maintainer is responsible, has
failed to meet policy requirements. the question is, does policy exist only
for the benefit of the developers/maintainers, or is policy intended as the
grease that makes the system equally accessible to the users? that quote
above tends to suggest to me, at least, that the latter is the case.
> And anyone who thinks the only reason their pet minor bug would be
> allowed to languish in the BTS is a "lazy or incompetent maintainer"
> needs a reality check.
sorry, you're wrong. the complaint is entirely valid. and i say this with the
utmost sympathy for those who do more than i can. why is manoj pissed? why is
colin putting his packages up for adoption? why is the next release
struggling its way to fruition?
>The rhetoric expended on this thread in
> upbraiding maintainers for the poor job they're doing of package
> maintenance could have been much better spent on providing patches (or
> at least suggestions) in some of those bugs that had been filed -- since
> clearly everyone involved in this thread has English fluency to spare,
> which can not be said of DDs as a whole.
here's a suggestion. either open up the packaging system to allow non-novice
users to review package description, or accept the bug reportage of late.
> > i wish, as i'm fairly sure most plain users wish, that i could contribute
> > more. one does what one can. these days, i run woody, and i have no
> > complaints. a year ago, i ran sid and participated much more on
> > debian-user. as ever, i am in debt to those of you who make it possible
> > for all of us to be free in our choice of operating system, but it's
> > noticeable that, apart from manoj, colin, and branden, there are few
> > developers who regularly listen to what goes on on debian-user. pose the
> > question there, especially for the novices' sake, whether the package
> > description is adequate. we, the users, are those who require adequate
> > package description, if for no other reason than to accommodate our
> > desire to share what we can amongst ourselves.
> If you are able to recognize that a given package description is
> inadequate, you are also capable of discerning *what* is wrong with it,
> even if you don't know what the package does; and you are therefore very
> much qualified to contribute comments to individual package description
> bugs in the BTS, which is likely the most time consuming part of the
> exercise of getting these bugs addressed, and which does not require
> familiarity with the package. Contrary to Manoj's sneering, there is
> very good reason to believe that those most qualified to maintain a
> given package in other respects are also least likely to be able to
> identify those traits that render their package descriptions problematic
> for users unfamiliar with the package. So if you want good package
> descriptions, don't complain -- help.
the problem there is that, for users, we generally don't get to see package
descriptions before the package has been released. i would bet anything that
the majority of debian users run whatever is stable, at least on critical
machines, at any given time, and the problem i have with this notion that
such users should be made responsible for the failed responsibility of a
package maintainer is that the argument simply makes no sense. we don't get
to question policy. we rely on policy. if you don't adhere to it, we have
nothing to rely on.
as for helping, as much as you seem to think that complaint is antithetical
to help, what i've taken the time to write here is proposed as help. i think
i've already made it clear that your work is appreciated. i have no interest
in upbraiding any maintainer, but, as i pointed out before, there's a growing
distance between the developers/maintainers and the regular users. make it
easier for us to help. dump the elitism that preserves the gap. take some
time to peruse debian-user and appreciate the degree of "enlightened
self-interest" going on there.
- Re: Done
- From: Marek Habersack <email@example.com>
- Re: Done
- From: benfoley <firstname.lastname@example.org>
- Re: Done
- From: Steve Langasek <email@example.com>