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

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

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

Attachment: pgpYxk8JXEn_n.pgp
Description: PGP signature

Reply to: