Re: On the removal of yaclc
On 19/03/11 at 23:09 -0700, Andrew Pollock wrote:
> Hi,
>
> I just noticed that yaclc was removed, under the premise of being orphaned
> and having a low popcon score.
>
> This broke my workflow (I had a pbuilder hook that installed lintian and
> yaclc together, and that started failing, so I noticed the absence of the
> lintian run).
>
> My particular use case hides the popularity of yaclc, because it's only ever
> installed in the pbuilder chroot at the end of a package build. I just
> wonder how many other people were doing that too? I must have got the idea
> from somewhere...
>
> Also, was the package actually buggy? I'd been using it for years, and it's
> not like the BTS or the changelog format have fundamentally changed, so if
> it wasn't totally busted, so what if it's orphaned? Couldn't the QA team
> have adopted it instead? It seems like a useful tool to me (yes I've seen
> the discussion on the removal bug, but I don't see how removing it before a
> replacement exists helps anybody).
Hi,
This removal is part of an effort to clean the archives from some of its
orphaned packages. Beginning of release cycles are a good time to do
this kind of cleanup, since there's a lot of time left to detect
packages that have been removed, but are still useful to some people.
I'm perfectly aware that being orphaned is just an indication that nobody wants
to maintain the package, not an indication that the package is useless or
completely broken. However, without investing a huge amount of time, combining
metrics such as:
- age of orphanage
- age of last upload
- popcon
probably gives a not too bad approximation.
(Look at http://udd.debian.org/bapase.cgi?t=o for the list I'm using -- or was
using: I must admit that I got rather demotivated after Joey Hess' blog
post[0])
[0] http://kitenet.net/~joey/blog/entry/the_fate_of_the_orphans/
But generally, this raises the question of what we want for Debian. Do
we want:
(1) to package everything that was ever released as free software,
accepting that we can't do it while maintaining a high quality for our
packages?
(2) to restrict ourselves to packages that are known to be useful to at
least some people, but to ensure that the packages are of reasonable quality?
I'm of the opinion that we should go for (2). And that means that a
large chunk of our ~400 orphaned packages should probably be removed.
That will allow contributors to focus on orphaned packages that really
need to stay in the archive. Also, the damage for users of
testing/unstable is limited, since the packages are still available in
stable releases and/or in snapshot.d.o.
Now answering specific points of your mail:
> Also, was the package actually buggy?
It takes users to get bug reports, and not all users report bugs. That
results in a lot of low-popcon packages having zero bugs in the BTS,
despite sometimes being severely broken.
> Couldn't the QA team have adopted it instead?
I'm under the impression that the "maintain orphan packages" part of the
QA team is at best dormant.
Since the beginning of 2011, there has been 57 QA uploads[1].
List of people having done more than one QA upload:
changed_by_name | count
-------------------------+-------
Daniel Baumann | 6
Neil Williams | 5
Clint Adams | 4
Tobias Quathamer | 3
Ralf Treinen | 3
Matthias Klose | 3
Anibal Monsalve Salazar | 3
Max Vozeler | 2
Thorsten Glaser | 2
Pino Toscano | 2
John Goerzen | 2
Jakub Wilk | 2
So, the real question is: why don't you adopt it, or provide a patch to
devscripts to integrate it in there?
[1] UDD query:
select source, changed_by_name from upload_history
where maintainer_email = 'packages@qa.debian.org'
and date >= '2011-01-01';
[2] UDD query:
select changed_by_name, count(*) from upload_history
where maintainer_email = 'packages@qa.debian.org'
and date >= '2011-01-01'
group by changed_by_name
having count(*) > 1
order by count desc;
Lucas
Reply to: