Re: Done
- To: debian-devel@lists.debian.org
- Subject: Re: Done
- From: Andreas Rottmann <a.rottmann@gmx.at>
- Date: Wed, 08 Oct 2003 00:59:08 +0200
- Message-id: <[🔎] 87llrwhcxv.fsf@alice.rotty.yi.org>
- In-reply-to: <20030916165814.GW1917@tennyson.netexpress.net> (Steve Langasek's message of "Tue, 16 Sep 2003 11:58:14 -0500")
- References: <20030911011216.GD2431@thanes.org> <877k4eqaa8.fsf@glaurung.green-gryphon.com> <20030913134040.GA10950@riva.ucam.org> <E19yPY4-0007tX-00@smtp.web.de> <20030914195351.GA3707@quetzlcoatl.dodds.net> <87znh636y7.fsf@glaurung.green-gryphon.com> <20030915153745.GC27987@tennyson.netexpress.net> <87oexl3o6s.fsf@glaurung.green-gryphon.com> <20030916165814.GW1917@tennyson.netexpress.net>
Steve Langasek <vorlon@netexpress.net> writes:
> On Mon, Sep 15, 2003 at 01:24:11PM -0500, Manoj Srivastava wrote:
>> On Mon, 15 Sep 2003 10:37:48 -0500, Steve Langasek <vorlon@netexpress.net> said:
>
>> > There is a distinct difference between recognizing what is missing
>> > from a description, and being able to fill in the gap. The two acts
>> > are complementary. What helps maintainers is to understand what the
>> > questions *are* that users are going to ask about their package
>> > description. It's hard to know what questions are going to be asked
>> > when you already know the answer yourself; this is not something
>> > that can be changed through expressions of disdain.
>
>> How about these criteria?
>> a) What does the package do? If it is an add-on to another package,
>> then the short description of the package we are an add on to
>> should be put in here
>> b) Why should I want this package? This is related to the above,
>> but not the same (this is a mail user agent; this is cool, fast,
>> interfaces with pgp and ldap and imap, has features X, Y, and Z)
>> c) If this package should not be installed directly, but is pulled in
>> by another package, this should be mentioned
>> d) If the package is experimental, or there are other reasons it
>> should not be used, if there are other packages that should be
>> used instead, it should be here as well
>> e) How is this package different from the competition? Is it a better
>> implementation? more features? different features? Why should I
>> chose this package (b should talk about the class of packages, and
>> e about this particular package, if you have both b and e related
>> information).
>> f) ???
>
> These seem like very reasonable and helpful criteria. Perhaps they
> could be placed somewhere (developer's reference, policy footnote?)
> where they'll be generally visible to maintainers?
>
I strongly second that.
--
Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Packages should build-depend on what they should build-depend.
Reply to: