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

Re: Done

On Mon, 15 Sep 2003 14:52:48 -0400, Greg Folkert <greg@gregfolkert.net> said: 

> On Mon, 2003-09-15 at 13:33, Joey Hess wrote:
>> Greg Folkert wrote:
>> > Great basic rule of thumb... first off if you DO NOT know what
>> > BLACS or LAM is... you don't need it. I apply this rule
>> > everywhere. And obviously you should as well. If you knew what
>> > BLACS or LAM then you would definitely know >WHAT< it is and
>> > >WHY< you would need it.

	I see. Great way to never learn anything. So, we should
 discourage our users from exploring new packages, just so that we can
 retain the 'lite under-80-char-cool-description. Part of promoting
 free software is to educate users about it; promoting a culture of
 ignorance gets us nowhere.

>> > We(you and Ben) are forgetting the prime reason Debian exists. If

	I have forgotten the prime reason Debian exists? How horribly
 remiss of me.  However, I am sure you shall enlighten me (_I_ thought
 the prime reason for Debian was so that I can have a competent and
 fre OS for my cluster of machines, but I am not sure tihs is what you

>> > you don't know that you obviously shouldn't be on the Devel
>> > list.

	Oh No! I don't belong on the -devel list!  Perhaps you can
 educate me about my place in Debian?

>> > Maybe you should just go over to Debian User and actually
>> > interface with people having problems that need to be
>> > solved. Rather than piss and moan about descriptions that are
>> > obvious, when you do need them you know they apply.

	I do lurk on the user list, and delurk to answer kernel
 compilation questions, or anything pertaining to the packages I am
 interested in.  Also, if I can't understand what a package does, or
 make a decision about whether I would want to install a package, then
 the description is not obvious.  Or do you work under the premise
 that if it is good enough for you, the hell with everybody else?

>> > Maybe you should understand that a mere 80 characters *MIGHT* be
>> > all that is needed. I see Debian descriptions and they are very
>> > understandable to me, when I know HOW they apply. I would
>> > hesitate to make some of them longer, as it would make them
>> > similar to a fluffy romance novel.

	Oh, yes, I see you do work under that premise. Yes, they
 might; we may have a few packages where one may be able to convey
 what it does, why is that useful, how it compares with other packages
 that do the same, whether it is meant to be installed directly, or
 shall be pulled in by dependencies, all in under 80chars; but the
 possibility seems fleetingly small.

> Very plausible. The trick is to get the requester to use the
> skill/knowledge they posses to help traverse the decision tree. I
> know... they never help or are hard to get a hold of... very brutal
> when working with them... etc... etc...

	Right. Shift the burden on to the users, and let every bunch
 of users make this same effort, just so we can save, according to
 Matt, under a minute coming up with a long description that would
 make these decisions easier.

	Do you realize that this degrades the quality of the
 distribution for what seems to be a minor effort on the part of the

> Often they are the ones with the decision capacity. Point them in
> the proper direction and ask them to pick between the choices you
> have. I do this most of the time, when I don't, often have to
> retrace my steps and change the setup.

	Great work around for work that should already have been done.

>> I think my scenario is completly plausable. And yes, I do read
>> debian-user.

> "We" meant Manoj Srivastava and Ben Foley. I have been reading DD on
> lists.d.o the web-server for quite sometime and I must have missed
> your comments.

	Yup, I don't know the prime reason Debian is here, and I don't
 belong on -devel. Got that. 

> I just think that a significant portion of Debain Developers *ARE*
> ignoring the end-user (end-luser a number say) if they can't immerse
> themselves in FIXING the stuff the write by helping out
> periodically, I'd be hard pressed to guess they WANT to make the
> package a success...  Blue-sky attitude is a good thing, but you
> need some mud and dirt in there to make things grow.

	For the most part, the end user is not a pressing concern of
 mine, no. Improving my packages is, and I'll take help in improving
 my packages from anyone; but the motivation for doing so are entirely

> I guess, I have a different perspective being on the "make things
> work" side for a few too many years of the support train to really
> believe Descriptions will change the world. If short and long

	Nothing much really changes the world drastically, most things
 that combine to improve conditions do so incrementally, and in small
 measure (ocean made of amalgamation  of dropets of water ...).

> descriptions are the same, maybe a Bug-Report SHOULD be made and the
> reporter include a good description themselves. On the other hand, a

	On _any_ bug report, there should be NO requirement that a
 solution be proposed.  And I have demonstrated that I can tell when a
 description is inadequate, but have no idea what the patch to fix it
 would be -- since I know little about the package.

The shortest measurable interval of time is the time between the
moment I put a little extra aside for a sudden emergency and the
arrival of that emergency.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: