Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
[ sorry for duplicate, Neil, pressed the wrong button ]
On 2012-03-26 09:17, Neil Williams wrote:
> On Mon, 26 Mar 2012 09:55:35 +0300
> "Eugene V. Lyubimkin" <jackyf@debian.org> wrote:
[...]
> > 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. [...]
No, it has. At least for me. I certainly know about or even installed
some software solely because I saw an ITP for them, for example,
'lightspark'. I doubt that many people use a search engine once a while
to see if there is new flash player available.
And my own example to that is #524605. I know it caused some discussion
before that ITP was closed, and I am fairly sure very few people would
find it through a search engine.
> > 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.
Generally, yes. But not always.
> > > 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. 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.
> [...]
> 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.
This is true only for the software you are upstream for, which is, I
believe, the minority of Debian packages. I'm now convinced that there
are proper quickly-packaged things in Debian, but I'm still not
convinced the average package could be packaged so.
> 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.
May be useful, but not sure if a single absolute time limit would fit
all the cases.
> 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.
Cannot agree. People who are trying to get their packages to Debian on
debian-mentors@l.d.o often wait for more than the month. Of course we
can establish a new policy to comment in ITP threads more, but that's
not how things are now.
Ah, by the way, another example out of my head. #611400 was about 4.5
months without a comment. Would you close it on 2012-03-01?
> If the upload is simply waiting for a
> sponsor then *say so* in the ITP and put a link to mentors.debian.net.
So ITP owners should write more mails to ITP. Sounds fine, but this
suggestion to write more manual mails somehow contradicts to the point
(of Joey, and, as I understand, of you) that writing a one
semi-automatic e-mail (ITP) is a big burden.
> ITP bugs must not be allowed to block actual work. It's equivalent to
> domain-squatting and just as distasteful.
True, but I don't consider 'write to the old ITP of your new intent and wait a
week before the upload' as too much 'block actual work'. Again,
license/copyright problems, repacking original tarballs and waiting for
the NEW queue procession happen more often that clashed ITPs, right?
> 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).
Agreed.
> 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.
Don't agree with that. To me it's like if I have filed a normal-severity bug
in the "third-party" package, and that bug blocks (some) my work, I can NMU
the package after a month without saying anything to the maintainer
and/or but thread, if the maintainer didn't respond to the bug. Wouldn't
that be rude?
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
----- End forwarded message -----
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
Reply to: