[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, Mar 26, 2012 at 09:17:53AM +0100, Neil Williams wrote:
> > 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.

Well, much like code review, a sanity check might be useful
sometimes. Just a minor suggestion to improve something could crop
up. I always prefer to have my ideas checked by someone else, but
then, that's my preference.

> 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 am guessing that the ITP was closed in hours because of NEW
processing. So, to be clear, how does waiting "minutes" for the bug
number when it will be processed in "hours" make it a waste of time?

> > > 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.

This is taking it to an extreme. Even in the case of domain-squatting,
the first attempt to fix the problem would be to contact the domain
owner and make a gentle request to vacate. In this case, I frankly
don't see the need to hijack an ITP without doing so.

> 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.

This may be your opinion, but I would still opine that it would be
decent to ask the ITP owner as to why he or she has not got back to
uploading it yet. However, my timelines differ greatly, and having the
package in the archive very quick may suit your requirements better.


Make it idiot-proof, and someone will breed a better idiot.
		-- Oliver Elphick

Reply to: