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 <enr...@enricozini.org>
signature.asc
Description: PGP signature
