Hello,
I've recently seen constructive and polite[1] as well as destructive and
rude[2] examples of dialogues with upstreams who cannot or would not
support long-term stable releases of their software.
I have not heard often of Debian maintainers negotiating with upstreams
before packaging their software in Debian, about which versions should
be packaged, which versions should go to stable, who gets to deal with
bugs on the stable version after 6 months, a year, two years, three
years it's been released.
I know I do not always perceive the action of packaging and uploading
something to unstable as an action which can have consequences 3 years
from now. Yet, if all goes well and I don't file an RC bug to block it,
the expected path of that package leads to testing, freeze, and stable.
I don't think that we should, willingly or accidentally, end up forcing
upstreams to support their software beyond what they are able or willing
to support. There are alternatives we can negotiate: Debian maintainers
can offer help upstream with stable support, or perform stable support
entirely inside Debian.
At the moment, the only ways that we have of having something in Debian
that does not end in stable is to upload it to experimental or to open
an RC bug to prevent transition to testing.
Still, I see value in running testing over unstable, and although I very
happily keep my servers on stable so that my services keep working for
years, I keep my personal laptop permanently on testing so that I can
keep up with recent news in software development, and I still get a
somehow consistent dependency set.
I would like to be able to decide, at upload time, whether everyone is
ok to have that version of that package supported for 3 years, and so
whether it is intended for stable or not.
If it is not, I would still like that version of that package to enter a
somewhat useable but volatile kind of Debian with no expectation of
stable support.
I have the impression that something like this would greatly reduce the
size of our next stable release, and at the same time make it more
likely that all in it can be supported[3].
If that means that some important packages risk disappearing from the
next stable, then it would be an opportunity to engage in a discussion
and negotiation with upstreams on how to make stable possible for them.
I don't like the idea of having unsafe packages in stable, that just
look clean because they are mostly unused or unreviewed.
I don't like the idea of forcing upstreams to get email about versions
of their software they never intended to release long term, and would
have long forgotten if it wasn't for us accidentally making our users
believe that they care.
I'd like to have a safer, sane and consensual stable.
How much work would it be to declare at upload time whether a package
should transition to stable, and to have a testing-like suite with
testing plus those packages not intended for stable?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745027
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
[3] Look at the versions of node-* packages here:
https://packages.debian.org/stable/web/
how many of those can really be supported a year from now? Or even
right now?
Enrico
--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature