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

Re: removal instead of orphaning?

On 26-08-16 23:40, Julien Cristau wrote:
>> Who is this a burden for? As long as there are no RC bugs filed for
>> the orphaned packages, I don't see any a direct reason to remove
>> them. If no-one used the package, then sure, the package is really
>> useless. But if at least some people are using it, it has value.
> off the top of my head:
> - it's wasting time of anyone doing QA work
> - it's wasting time of any user who looks for a piece of software to
>   do
>   $stuff and gets to eliminate all the noise from unmaintained
>   probably-broken cruft

These were indeed the two items I was mostly thinking of. I felt the
pain of the first item last year with the dh-python migration at
Debconf. And I have felt the pain of the second item multiple times in
the past. Nowadays, I check all the tracker.d.o pages of packages before
I install a package which function is provided by multiple packages. I
think we could do better on that front. This is a first simple step.

And I don't agree that if a package is non-RC, it is worth keeping in
our archive. I like to see our archive in good quality. A package
without an active maintainer is always in danger of slipping in quality,
with only the users noticing, who may file bugs, but if the bugs are
non-RC, there is nobody to notice.

On 26-08-16 21:52, Guus Sliepen wrote:
> On Fri, Aug 26, 2016 at 07:43:20AM -1000, David Prévot wrote:
>> What about, e.g., security issues: if nobody cares about maintaining
>> code, whether dormant or dead upstream, or simply no maintainer to
>> include security fixes or upload new upstream versions, then I believe
>> it may cause direct harm to the project.
> Perhaps. But consider this: people who don't need a package don't
> install it. Those who do need it do. If Debian, for whatever reason,
> does not provide the package they need, they will have to download it
> themselves and install it on their machine. Which for them will take
> more time and effort than apt-get install would.

Yes, but consider the same case but where upstream has newer releases,
at least this user can get proper upstream support, while he isn't
getting any support in Debian. And as Julien noted, there may be more
packages that can do the same. This user should find the maintained
package instead of this one. (So yes, if your package provides
functionality available elsewhere in the archive, you have a higher
chance of saying, yes, let's remove it instead).

> So while Debian the project can
> wash its hands of the package in question, the harm done to the end-user
> is still the same or maybe even larger.

I don't agree. I think users expect good packages from Debian, and if we
don't maintain a package, it is a service to the users to say so clearly
(e.g. by not providing it). By the way, remember that we have
derivatives that don't pull from stable, but from unstable to develop
on. They get our unmaintained packages, even if we would keep it out of
testing/the next release.

> I'm quite sure there are many packages with active maintainers for which
> nobody cares enough to file RC-bugs either. Are you actively checking
> for security problems in all of your packages?

Yes I do and I think that is a task of you as a maintainer. Things like
DMD¹ make that easy (at least that is what I use currently).

> If you haven't automated
> it in some way, do you manually check for new versions and upstream bug
> reports every day or week?

New versions, yes, uscan and watch files do that, so also that shows up
in QA pages like DMD and DDPO². DMD even pushes that to you if you
subscribe to the RSS feed.

> I personally find the criterion "package is orphaned" too arbitrary to
> say it should be removed.

And I never said that. I wanted to say: instead of orphaning, consider
if your package should be removed from Debian instead of being orphaned.


¹ https://udd.debian.org/dmd.cgi?email1=elbrus%40debian.org
² https://qa.debian.org/developer.php?email=elbrus%40debian.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: