Grettings, Last week I started looking into Debian packaging, and found myself at the wnpp page [1]. I spent some time browing the lists, especially RFP (Request For Package) and ITP (Intent To Package). At some point, I got discouraged because lots of these are inactive, (446 of the 831 being_packaged entries hadn't seen activity since 2004-Jan-01). I started by emailing the being_packaged maintainers asking for updates, and eventually did some scripting to automate the process. I present here the results of said mailing and also my ideas for the improvement of the wnpp area. I ran the mailer script Saturday afternoon, at which point there were 831 being_packaged, there are now 799, and this number was even lower at some point. I've received responses regarding 39 distinct packages, indicating that 4 packages will be uploaded within the next week; 4 which are waiting pending resolution of licensing issues; and 5 are waiting for a sponsor (myself excluded). Many have Cc:d the BTS, and so there should be a good number of bugs updated with status reports. I also have a list of up to 30 possibly MIA developers, which I'll investigate next week. I'm still on good terms with all who responded. Very few people indicated that they were mailed incorrectly. Most that replied have thanked me for the "prodding". I realize that some feel that an automated mailing is inappropriate; however contacting people to inquire the status of their bug seems to be accepted practice. I hadn't considered scheduling regular mailings (and I don't recommend that). Indeed, I think one of the advantages that I had here was that it was an unexpected message, which prodded developers to update the bts, either by dropped the ITP, or uploading the package, by pinging upstream, etc. In the process, I've noticed some problems and I have some recommendations about how wnpp could be made more useful. Lets talk about the RFP list. My complaint here is that there's no way of knowing if a package is still useful. There's no distinction between a 12 month old package in which many are still interested, and a 12 month old package that someone RFPd on a whim, which has been abandonned upstream, and for which there is now a more general, better, etc., replacement already packaged. Thus I recommend that RFP bugs are tagged with a date-last-requested, and should expire to an old-RFP list after, say, 4 months. Also, it should be easy to renew an RFP bug (expired or not) to update said timestamp. And RFPs which will expire shortly should be advertised as such (maybe to DWN?) such that interested parties can renew them. This would clean up the RFP list in such a way that a developer can go there and immediately see what it would be useful to package. Right now, I find that diffcult. Question for the list: is there an accepted policy towards dropping an RFP? Close the bug if the original requestor no longer requests it? A timestamp mechanism as describe above would make this more guilt-free, and the policy more obvious as it'd be easier to see that a package was not wanted by _anyone_. I think the RFP list should also be sorted differently. I've read through the list and read about the packages in which I'm interested, but there's no easy way (other than wget;grep) for me to find new RFPs. Or is there a list to which I should subscribe? Sponsors. I already recommended to debian-devel that a sponsor-needed tag be added. Then we can have a wnpp sponsor page listing packages seeking a sponsor. This makes those packages easier to find for developers, and (hopefully) accelerates the mentoring and uploading. I also think being_packaged should be cleaned, but its less important than RFP, and I realize that it may be that lots of being_packaged are holding on a long-term thing, Eg a dependency or a license issue. Please Cc: me. Justin PS. I'm currently seeking a sponsor for packages at [2]. I'm especially interested in pport: Access the output pins of a parallel port, meant to be used to control household devices. (Preliminary package only). References [1] http://www.debian.org/devel/wnpp/ [2] http://www.gettysburg.edu/~pryzju01/debian/
Attachment:
signature.asc
Description: Digital signature