On Thu, Sep 22, 2016 at 11:33:13PM +0200, Tobias Frost wrote:
> Adrian,
>
> Am Donnerstag, den 22.09.2016, 12:15 +0300 schrieb Adrian Bunk:
> > On Sun, Sep 04, 2016 at 12:33:00PM +0200, Tobias Frost wrote:
> > >
> > > Followup-For: Bug #673959
> > > Control: reassign 673959 ftp.debian.org
> > > Control: retitle 673959 RM: cobalt-panel-utils -- RoQA, low popcon,
> > > dead upstream, unmaintained
> > >
> > > I think this software is EOL and should be removed.
> > > Popcon is 1 and the Homepage does not exist anymore.
> >
> > Hi Tobias,
> >
> > did you ever bother to check what this package you successfully
> > managed
> > to get removed from unstable actually does before claiming that it
> > would
> > be EOL?
>
> Hey, calm down.
>
> Of course I checked the package throughly before coming to this
> decision. I never take RM requests lightly.
I do not think that you checked this thoroughly enough.
You removed a package providing hardware support without checking
whether the hardware is on machines still supported by Debian.
> > popcon is never a good metric for verifying that there are no users.
>
> Popcon is an important data point, but for of course not the only one.
Treating popcon as an important data point is not good.
Popcon is not very represenative, especially for special-purpose
software.
> > Even less for a package like cobalt-panel-tils, that provides
> > hardware support for exotic hardware - such a package can never
> > achieve high popcon numbers.
>
> Additionally, the package was orphaned 4 years ago, had several bugs
> open, some even with patches...
That's just blindly looking at statistics.
None of the bugs seems to matter for a normal user of the package.
> No one cared enough to adopt it in all
> those years.
See below for an explanation why your "all users are developers" logic
is flawed.
> Popcon was never high, yes, but it has been significantly
> higher in the past.
And again you are arguing based on popcon.
Your "significantly higher in the past" sounds a lot less convincing
when expressed as "16 popcon-reporting machines less have it installed".
> > Support for the older MIPS based Cobalts was already
> > removed in Debian 8,
> > and support for the newer x86 based Cobalts might lack kernel p arts.
> > So you might be lucky that cobalt-panel-utils was actually EOL.
>
> Didn't I write "dead upstream", did I?
What you wrote is pretty unrelated to what I am talking about.
You wrote that cobalt-panel-utils was dead upstream.
This is correct, but completely irrelevant.
It is normal and expected that upstream is dead at this point.
cobalt-panel-utils upstream was already dead for years at wheezy times,
but wheezy does explicitely list the MIPS Cobalts as supported.
The only relevant question is whether there are any MIPS or x86 based
Cobalts that are still working in unstable, and where users will miss
cobalt-panel-utils.
I think the answer is No, but someone from the MIPS list should confirm
whether it is in principle still possible to run Debian on any Cobalts.
> > But this is something you should really have verified before asking
> > for removal.
>
> In the combination of above reasons, the RM was warranted and in order.
> Apparently ftp masters agreed with my reasonsing, otherwise they won't
> have executed it.
An ftp master mistaking two bad reasons for a good reason doesn't make
it right.
> You
> might to want become upstream, though, to solve the dead-upstream
> thing.
You miss that the dead upstream is not a problem for such a package.
This code was published by Sun in 2003, and the "dead-upstream"
you are referring to is a guy who did some modifications to
cobalt-panel-utils in 2005.
MIPS Cobalts are officially listed as supported in wheezy, which was
released a year after cobalt-panel-utils was orphaned.
Nothing in the bugs indicated that cobalt-panel-utils was broken when
the hardware was still officially supported in a new stable Debian
in 2013, 8 years after the last upstream release and 7 years (sic)
after the last Debian upload.
> If you disagree with all this, just open up an ITP bug and reintroduce
> the package as maintainer. (As emeritus you know how Debian works).
It is a common misconception that Debian is for Debian developers only.
In reality, Debian stable is used in many areas, and the vast majority
of users won't see anything done on unstable until after the next stable
is released.
Please be more careful when asking for removal for software that is in
stable, and check whether there really is a good reason for removal.
When a package wasn't too broken for stable and you wouldn't object
to someone ITP'ing the package back immediately afterwards, what is
the benefit of removal?
None of "orphaned". "low popcon" or "upstream homepage dead" is
convincing for removal - even in combination.
Removing hardware support without first checking whether this hardware
is on machines that are still supported is simply wrong.
Correct would have been to check whether the hardware support might
still be useful, by asking that question to people who know the answer.
Note that I am only talking about removal without a good reason.
I have no problem with with even asking myself for removal when
I think it would be better if a package would be removed
(see #628848 and #692105 as examples).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
