Re: Long descriptions in RFS emails.
On Sunday 10 February 2008 10:13:50 am Neil Williams wrote:
> Just a note for everyone - I will now ignore any RFS that does not
> include the long description for the package.
> It doesn't matter how many times you "ping", without a long description
> posted to *this* list, I will no longer waste time either asking for one
> or reviewing your package and your RFS is likely to be deleted without
> any further action.
I actually thought anything that's not part of the template would be
considered cruft, thus I avoided adding anything extra to any RFS I sent. I
also avoided writing an RFS that didn't look like the template since I
thought the template was all the information any sponsor would need and in a
format that's easily readable by anyone.
Perhaps it's best to include where the description and other information
should go. I'm thinking something like:
From: maintainer's name <email@example.com>
Subject: RFS: package -- short description
I am looking for a sponsor for my package "package".
* Package name : package
Version : version
Upstream Author : [fill in name and email of upstream]
* URL : [fill in URL of upstreams web site]
* License : [fill in]
Section : section
. . .
In case the long description is not the appropriate place for a reason,
maybe a reason section could be added, describing why this package should
be included in Debian (example: it helps these Debian users, it's needed by
this other useful package, etc.).
It builds these binary packages:
binary-package - binary package short description
next-binary-package - next binary package short description
. . .
The package appears to be lintian clean.
The upload would fix these bugs: XXXXXX . . .
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/package
- Source repository: deb-src http://mentors.debian.net/debian unstable main
Note: Any special notes that a sponsor (or anyone) would need to be aware
of should probably go here.
I would be glad if someone uploaded this package for me.
Also, the update template should probably include the Reason section right
before the section where it lists the binary packages that are built. Here a
maintainer should add stuff like:
This is a new upstream. It fixes a security issue that allowed this and that.
etc. . . .