On the removal of yaclc

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

On the removal of yaclc

Andrew Pollock
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).

regards

Andrew

signature.asc (852 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Lucas Nussbaum
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 = '[hidden email]'
and date >= '2011-01-01';

[2] UDD query:
select changed_by_name, count(*) from upload_history
where maintainer_email = '[hidden email]'
and date >= '2011-01-01'
group by changed_by_name
having count(*) > 1
order by count desc;


Lucas


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110320201834.GA31429@...

Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Raphael Hertzog-3
Hi,

On Sun, 20 Mar 2011, Lucas Nussbaum wrote:
> (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/

I don't think it should have demotivated you. It's just pointing out
known deficiencies in our processes... ideally we should try to find new
maintainers more actively but this rarely happens when a package is
orphaned with WNPP bug that is not advertised to -devel or any other list
where new maintainers could pick it up.

Removing the package is more likely to have people react. And it's best to
do it at the start of a cycle like you told so that a new maintainer can
reintroduce in time.

It's way better than the opposite scenario: package is unmaintained, gets
a RC bug just before release, is removed, only to be reintroduced in the
release after.

So +1 from me to continue more aggressive removals at the start of the
cycle.

> 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?

We want the best of both: as much free software that we can reasonably
support.

> So, the real question is: why don't you adopt it, or provide a patch to
> devscripts to integrate it in there?

+1 In particular if it's low maintenance as you seem to suggest it.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110321102155.GA28803@...

Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Mark brown-22
In reply to this post by Lucas Nussbaum
On Sun, Mar 20, 2011 at 09:18:34PM +0100, Lucas Nussbaum wrote:

> 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.

It would be helpful to make more noise about removing packages - I've
noticed at least one package that I care about (intercal) removed
without even having heard that it was orphaned, let alone having heard
about any active efforts to remove it as a result of which it dropped
out of the release :(


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110321152039.GA13256@...

Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Lucas Nussbaum
On 21/03/11 at 15:20 +0000, Mark Brown wrote:

> On Sun, Mar 20, 2011 at 09:18:34PM +0100, Lucas Nussbaum wrote:
>
> > 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.
>
> It would be helpful to make more noise about removing packages - I've
> noticed at least one package that I care about (intercal) removed
> without even having heard that it was orphaned, let alone having heard
> about any active efforts to remove it as a result of which it dropped
> out of the release :(

Any suggestion on how to make more noise would be helpful. Do you have
wnpp-alert installed?

- Lucas


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110321154703.GA22975@...

Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Mark brown-22
On Mon, Mar 21, 2011 at 04:47:03PM +0100, Lucas Nussbaum wrote:

> Any suggestion on how to make more noise would be helpful. Do you have

Something along the lines of what we do for ITPs - post to -devel and so
on - would help.  Right now it's an invisible process with no public
warning that things are happening.

> wnpp-alert installed?

I've got wnpp-alert *installed* but there's nothing in devscripts
that sets up a cron job for it as far as I'm aware.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110321193354.GB13256@...

Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Ana Guerrero Lopez
In reply to this post by Andrew Pollock
On Sat, Mar 19, 2011 at 11:09:14PM -0700, Andrew Pollock wrote:
> Hi,
>
> I just noticed that yaclc was removed, under the premise of being orphaned
> and having a low popcon score.
>

yaclc is just a single perl file, maybe it could be integrated into
devscripts?

Ana


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110321220634.GA7502@...

Reply | Threaded
Open this post in threaded view
|

Re: On the removal of yaclc

Lucas Nussbaum
On 21/03/11 at 23:06 +0100, Ana Guerrero wrote:
> On Sat, Mar 19, 2011 at 11:09:14PM -0700, Andrew Pollock wrote:
> > Hi,
> >
> > I just noticed that yaclc was removed, under the premise of being orphaned
> > and having a low popcon score.
> >
>
> yaclc is just a single perl file, maybe it could be integrated into
> devscripts?

This has been suggested several times in the orphaning bug. It just
needs someone to do it.

- Lucas


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110322064317.GA9659@...