Re: Auto-update for sid? Auto-backport?
- Date: Wed, 29 Nov 2017 22:56:09 +0200
- From: Adrian Bunk <bunk@xxxxxxxxxx>
- Subject: Re: Auto-update for sid? Auto-backport?
On Mon, Nov 20, 2017 at 01:20:06PM +0000, Ian Jackson wrote:
> I would much rather have a minimally maintained package, from Debian,
> in my stable release, than have to roll my own. This is particularly
> true if I don't know yet whether the thing is what I want. Trying
> something out from "apt-get" in stretch is a lot less work and a lot
> less risky than git cloning some random url and then blundering about
> trying to get the thing going.
20 years ago these discussions were about packaging all of CPAN.
Today the prime example would be the packaging of Node.js modules.
There are more than half a million Node.js modules available.
These could be automatically packaged into half a million
> I prefer this so much that in some cases I have considered packaging
> the thing myself and becoming one of these "disgrace" maintainers that
> Adrian is complaining about.
You are the kind of maintainer who would at least once per release cycle
package the latest upstream version and check the bugs.
That's not disgrace, that's average.
There is a problem due to the combination of throwing stuff into
Debian and the tendency of many people in Debian who want to get
rid of everything with low popcon quickly.
And while not always avoidable, the revolving door situation of
packages in one stable release but not in the next is causing
problems for users.
The lifecycle of such a package is often:
1. package gets ITPed
2. package is part of a stable release
3. package gets orphaned
4. package is removed from unstable
Many people are eager to remove unmaintained low-popcon buggy packages
from unstable, but often the root of the problem is actually what gets
ITPed into Debian - most of the time the package was not in a better
shape when it entered Debian.
> If I find some undermaintained package in Debian, it nearly always
> works well enough to solve my problem. And if it doesn't I have a
> uniform way to find the source, somewhere to send my packaging bug
> report, and the opportunity to NMU it if I discover something
> sufficiently bad.
This works nicely for the 0.01% of our users who are DDs.
For the whole range from "typo in the manpage" to "half the
functionality of the package is broken" one can find plenty
of > 5 year old bugs with patches and zero maintainer reaction
in the BTS.
Sometimes I see bug reports in the BTS where it is evident that a user
has spent hours or days on debugging an issue and writing a marvelous
bug report. I read the bug 10 years later with no other message ever
in the bug.
That's sad to read, and a disservice to our users.
I am aware that it is nearly impossible to prevent these from ever
happening, but it should be clear that maintaining a package in
general also includes things like handling bugs that get reported.
 there's real life, and teams with far too few people,
and many other reasons
"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