On Mon, 26 Mar 2012 09:55:35 +0300 "Eugene V. Lyubimkin" <jackyf@debian.org> wrote: > On 2012-03-25 16:00, Joey Hess wrote: > > But still nothing. ITP is more often than not a pointless bureaucracy. > > No, it's not nothing, and it's not a pointless bureaucracy. Filing an > ITP shows your intent to a hundreds of developers, which is: > > a) useful for the ITP owner since it advertises the package for > the prospective users; That's true mostly after the ITP is closed but it's also true if the package, once uploaded, has a sensible package description. Both get indexed by every search engine worth using. The ITP itself has no real impact on this. The ITP shouldn't need to be open that long. > b) useful for the Debian project since experienced people may > immediately point that there are/there were some problems which > prevented the package to be added before or made the package > disappear from Debian archives in the past; > c) useful for the Debian project since experienced people may ask > the ITP owner why to package the thing at all if they know/suspect > there are superior things in the archive already; > d) useful for the Debian project because people sometimes choose > too confusing/short names for packages, and answering to an ITP > is usually the only chance for the public to suggest some better > name before the package entered the archive, after which the renaming > is more time-consuming and bureaucratic; All of which can be good for those new to packaging but those who would do the commenting are generally reasonably proficient at anticipating such issues and choosing sensible names etc. from the beginning. > > The turnaround time for packaging the average package is less than the > > turnaround time in getting back a ITP bug number. > > I very doubt that. I even have a doubt that there is a single proper > Debian package for which the time between 'Oh, I will package this' and > uploading a package to archives takes less than 15 minutes (which a BTS > turnaround time for me) as there are too many things to write/check > which require the human attention. But maybe that's me being too slow. No, it's quite often true. I can see exactly what Joey is getting at here because I suspect that my development flow may be similar at times. I get an idea for a tool or utility - I do a test in shell or something quick, decide which language it's going to be in when done properly and before I've even written a line of the final code, I'll create a debian/ directory, populate debian/control and get the whole thing rolling because often the easiest way to test the code is as a local package. If it doesn't work, no harm done. If it does work, the packaging is already in place, so the ITP is just a delay. I have still used ITPs for recent packages but the packages were all uploaded within minutes of filing the ITP and closed within hours. As Joey describes, I was waiting for the bug number in order to make the changelog entry, create a tag in the VCS and upload. It does make the whole ITP process seem a waste of time and I might not bother in future as there is not going to be any real opportunity for anyone to comment on the ITP in that time. I do the same with code written at work - the first thing I create is the debian/ directory, even before I've written main.cpp. A Debian package is my natural development platform. I can't remember when I last did any development - including upstream development - which did not start and be completely contained within a Debian package. I often release code without a debian/ directory as an upstream developer but that code has been developed and tested with the same debian/ directory as will be found in the Debian package uploaded a few moments after the upstream release. Therefore packaging takes no time at all, it is always fully complete before the code itself is even worth evaluating as useful to Debian. The packaging is part of my test harness. > > The appropriate thing to do when confronted with a months-old ITP > > for a package with the same content or name as your package is almost > > certianly to ignore old "intent" and get on with it. > > Absolutely disagree. Hijacking the ITP and/or package name without > saying a single word about that to the ITP bug thread is just plain > rude. I think ITP's should have a strict and absolute time limit - there is already some work to monitor aged ITP's/ITA's and rename to RFP: or O: but actually packaging something does not take long and if there are reasons to delay a particular package, it can be mentioned in a comment to the ITP or elsewhere. If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. If the upload is simply waiting for a sponsor then *say so* in the ITP and put a link to mentors.debian.net. ITP bugs must not be allowed to block actual work. It's equivalent to domain-squatting and just as distasteful. If there are legal problems with the package or missing dependencies, those issues need to be documented as comments in the ITP itself (including blocking that ITP with the ITP's of the missing deps). Otherwise, if you are not going to upload within a month of filing the ITP, then *close the ITP*. There should be no complaints if someone else assumes that the ITP is stale if there have been no comments on it for the last month. In most of the above, feel free to substitute ITA for ITP. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpMVgmCoThTg.pgp
Description: PGP signature