Bug#524787: ITP: unicorn -- Drivers and applications for the Bewan ADSL PCI ST and USB modems
On Wed, Apr 22, 2009 at 03:49:46PM +0200, Cyril Brulebois wrote:
> 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.
I'm thinking of renaming the binary package as unicorn-utils for the
next upload to make this clearer. It's going to go into NEW anyway.
Though with only two popcon users I guess most people have figured it
out :) It contains the natty GTK control/status app for the board though
which I've done some work on.
> > 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.
Well I've discovered this may not be QA's oversight. For some reason
the last upload didn't seem to link unicorn-source .deb to the unicorn
source package. Don't know why not as they are both in the .dsc.
> Yes, it's bad luck that your activity wasn't noticed.
No worries. People running unstable should be prepared for packages
popping in and out of installability. It's probably quantum ...
> 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. :)
My hubris was too quick, I found some bugs due to the Glade1 templates
generating some code which didn't work the same in GTK2. Getting rid
of autoconf cruft from the .diff after running autoreconf took a while
too :(
> 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.
Good idea.
> > 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,
>
> I'll take that topic to debian-qa@.
I wouldn't want to mandate times because circumstances differ and the
core teams do a great job anyway without adding constraints. I think
a policy of filing a bug on the package would be sufficient "notice to
interested parties".
Doing so with some suitable bug-tag might also help to automate the
remainder of the process, thus hopefully not adding to QA's work once
the decision had been taken to remove a package as unused/unmaintained.
By someone taking ownership of the bug they could declare an interest
and forestall the process. However I wouldn't currently have time to
learn debbugs and code this myself :) so I would understand if other
stuff were more important.
Hope I don't sound too legalistic. I think Debian's Developer and
QA processes are two of its great strengths and the chief source of
its consistently high quality. The prospect of Debian quality control
helping us meet engineering standards is the reason I'm pushing Debian
at work instead of our existing RH/Fedora lash ups.
> > 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).
That'd be fine by me. I've re-packaged it to work with and indeed to
build using module-assistant, but I want to make sure the package is
great before re-introducing it. The motherboard with the card in seems
to be buggy and causing IRQ problems. I need to try it in a different
machine to be sure the drivers are OK, before uploading unicorn again.
Nick
Reply to: