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

Re: Bug#524787: ITP: unicorn -- Drivers and applications for the Bewan ADSL PCI ST and USB modems



Nick Leverton <nick@leverton.org> (22/04/2009):
> Thanks for your interest in my IT(re)P and your comments.

No problem.

> Of the stated reasons for removal:
> 
> > | Please remove unicorn:
> > | - mostly unused (2 in popcon for the binary package unicorn)
> 
> The unicorn binary package contains ancillary utils which are frankly
> of little use.  A better metric for the use of driver packages such
> as unicorn would be the module source.  Unicorn-source scores a not
> completely moribund 50 users.

Alright. I guess the person proposing the removal thought that the tools
were some kind of needed to get it working.

> A better decision on the package's user base could have been gathered
> by considering all the packages built from unicorn, not just one of
> them.

Sounds fair.

> > | - unmaintained (last upload from a year ago)
> 
> As mentioned in the removal proposal it was very hasty on those
> grounds alone.  There are packages which haven't been uploaded since
> Etch, are they unmaintained as a result ?

-qa people try and gather clues using different metrics, and that's one
of them. Some other packages didn't need upload since them, and hence
aren't considered for removal.

> > | - doesn't build with Lenny kernel
> 
> I had done considerable work on this following the discussion in
> #394465 and was preparing an NMU even as the removal was being
> considered.  Just a ping on the bug would have got my attention rather
> than assuming the package was not being worked on.

Yes, it's bad luck that your activity wasn't noticed.

> My NMU was already on Mentors seeking an upload when the package was
> actually removed.
> 
> > | - not in Lenny
> 
> Again, not of itself a reason for removal IMO, only if there were no
> action on it and it was hence unlikely to be in squeeze.  Myself and
> others were working on updating it as seen in #394465 but didn't have
> time before the freeze.

I agree it no longer applies when it comes to integrating it back.

> > | - depends on legacy libs (GTK 1.2), which will be removed soon
> 
> Trivial to fix, took me about 2 hours once pointed out.  No bug was
> raised on this issue beforehand; it's a reason for raising a fresh bug
> with a warning of removal, perhaps, but still not a reason for removal
> IMO.

I guess this package might not have got a serious bug filed against
it/wasn't noticed when the first round of gtk1 MBF because it's in
non-free?

Also, not all packages are trivially portable, quite the opposite from
what I've seen. Good luck it only took 2 hours. :)

> > | - lacks support for important archs like amd64 (#306322)
> 
> This one is problematical to fix but not a reason for removal IMO as
> long as there are i386 users who need it (50 according to popcon,
> placing it almost 10,000 packages from the bottom ranking)

Agreed.

> My biggest beef with this removal is that no bug was filed against
> unicorn itself.  I have been monitoring the package to see what bugs I
> could fix in my NMU.  Had there been any hint that the above causes
> for removal were being considered I could have responded and dealt
> with them.

I think it might be worth adding an X-Debbugs-CC to the $package@ QA
address when filing removal with reportbug, and add that step to the
process. As you said, since you were monitoring this package, you would
have then been notified and had more chance to reply.

> But I think this removal was not even justified according to the
> stated grounds, and only allowing the last uploader 3 weeks to reply
> after a ping is perhaps a bit precipitate before deciding they are
> MIA.  I can't speak for him but I certainly had email to him bounce at
> around that time, apparently due to to Sourceforge mail servers.

Do you think the above-proposed step would help in such case?

> I think that perhaps I should open a bug on the removal process, so
> that at least removal notices are filed against the actual package,
> and due time is given for other interested parties to respond.  It is
> not as if the removal of unicorn was necessary to get a new release
> out or to enable some blocked transition involving hundreds of other
> packages.

I'll take that topic to debian-qa@.
> 
> > 
> > > * Package name    : unicorn
> > >   Version         : 0.9.3
> > >   Upstream Author : Frode Isaksen <fisaksen@bewan.com>
> > > * URL             : http://www.bewan.com
> > > * License         : GPL and Proprietary
> >                               ^^^^^^^^^^^
> > 
> > What the hell? Oh, that's for non-free, apparently, OK…
> 
> Yep.  It's GPL interface code to a closed-source but redistributable
> binary, like many other bits of non-free.  I intend to have another
> push at the distributor to get the closed-source bit opened, and if
> they won't then I hope I have sufficient experience to reverse
> engineer it if the Unicorn driver is still widely used by then.
> Others may disagree but I think it's more environmentally friendly to
> re-use old second hand hardware as I am doing, even if non-free when
> originally sold, rather than to create still more electronic waste.

Alright. Just made me bounce until I noticed itused to be in that
section. :)

> Anyway as I say, thanks for your interest and your time in responding.
> I hope I've addressed your comments fairly.

No problem. I might nevertheless remove unicorn from m-a's
compliant.list (I plan to do some cruft removal in the next upload).
You're welcome to open a bug against module-assistant to have it
included back once your package reaches the archive (although I'm trying
to follow *-source package additions by myself).

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: