Re: Upstream stable branches and Debian freeze
On Mon, January 31, 2011 18:09, Christian PERRIER wrote: However, upstream's policy in their stable branches is alway to only fix important bugs (they don't call them this way...but the definition is fairly close to Debian's). So, *in the case of samba*, I can guarantee that the user's (indeed sysadmin's) experience is much improved if (s)he can follow the upstream minor releases. In the past such things have not been allowed with the argumentation that even though stable may contain bugs, users rely on the behaviour that stable has. They may know about a bug but may have worked around it (and the update may break the workaround) or they do not know about a bug but a fix for it may break a previously functional system. And of course as we all know: bugfixes are not zero-risk and do have chances on new bugs being introduced. Being completely bug-free would be nice, but is probably unachievable. I think there's something to say for the predictability of a release: it may not be perfect, but once installed and tested it will keep working. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edb1dc090de6330490ab7f897785b9f.squir...@wm.kinkhorst.nl
Re: Upstream stable branches and Debian freeze
On Tue, 01 Feb 2011, Thijs Kinkhorst wrote: On Mon, January 31, 2011 18:09, Christian PERRIER wrote: However, upstream's policy in their stable branches is alway to only fix important bugs (they don't call them this way...but the definition is fairly close to Debian's). So, *in the case of samba*, I can guarantee that the user's (indeed sysadmin's) experience is much improved if (s)he can follow the upstream minor releases. In the past such things have not been allowed with the argumentation that even though stable may contain bugs, users rely on the behaviour that stable has. They may know about a bug but may have worked around it (and the update may break the workaround) or they do not know about a bug but a fix for it may break a previously functional system. And of course as we all know: bugfixes are not zero-risk and do have chances on new bugs being introduced. It is a good thing that we are actually able to learn, and move forward then, isn't it? Some upstreams do so much regression testing and are so strict, that you'd actually be doing a disservice to your users if you don't track their stable branch during Debian stable lifetime. Being completely bug-free would be nice, but is probably unachievable. I think there's something to say for the predictability of a release: it may You can just unplug it from the net and never update, if you want that (and if you're going to do that, be smart and use read-only media for the invariant parts of the system already): We've had several regressions due to security fixes. While those are not frequent, they're certainly not rare enough that you can ignore the fact. We seem to have reached a good equilibrium of stability versus bug-fixing on most packages. The current de-facto system works, let's not mess with that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201114155.gb29...@khazad-dum.debian.net
Re: Upstream stable branches and Debian freeze
Thijs Kinkhorst writes (Re: Upstream stable branches and Debian freeze): In the past such things have not been allowed with the argumentation that even though stable may contain bugs, users rely on the behaviour that stable has. They may know about a bug but may have worked around it (and the update may break the workaround) or they do not know about a bug but a fix for it may break a previously functional system. And of course as we all know: bugfixes are not zero-risk and do have chances on new bugs being introduced. Basically this argument is the update may break things. That's true, but the right questions are: how likely is that; how bad are the bugs that would be fixed by the update; and so on. Being completely bug-free would be nice, but is probably unachievable. I think there's something to say for the predictability of a release: it may not be perfect, but once installed and tested it will keep working. This argument seems very absolutist and would seem to suggest we should never do any stable release updates at all. But a user who wants that level of stability can simply not take the stable release updates, and only apply the security updates. I think there is room for us relaxing our policy for stable updates. Where upstream have a good track record of not breaking their own stable branch, I think providing those updates to our users is probably sensible. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19784.1680.379747.405...@chiark.greenend.org.uk
Re: Upstream stable branches and Debian freeze
On 2011-02-01, Ian Jackson ijack...@chiark.greenend.org.uk wrote: This argument seems very absolutist and would seem to suggest we should never do any stable release updates at all. But a user who wants that level of stability can simply not take the stable release updates, and only apply the security updates. That's not easily possible as stable as found on the mirrors is overriden by point releases.[1] So you'd need to mirror stable r0. I think there is room for us relaxing our policy for stable updates. Where upstream have a good track record of not breaking their own stable branch, I think providing those updates to our users is probably sensible. First off they have to establish that track record with us, though. (See also [2]. There will be a few updates to leaf packages in stable. However updates to stable server software will be considered carefully, and it depends on how we're convinced of the QA of maintainers and the quality of upstream releases. PostgreSQL did that[3]. For others we'll act on a case-by-case basis.) Kind regards Philipp Kern [1] Ubuntu does it a tad differently. On normal releases their release suite isn't updated. Instead updates are just pushed through the -updates suite. So here you're free to ignore those. LTS do point releases like we do, though. [2] http://lists.debian.org/debian-volatile-announce/2011/msg0.html [3] And they better don't screw up... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnikg9su.sv7.tr...@kelgar.0x539.de
Re: Upstream stable branches and Debian freeze
Hi, Ian: On Tuesday 01 February 2011 14:11:44 Ian Jackson wrote: Thijs Kinkhorst writes (Re: Upstream stable branches and Debian freeze): In the past such things have not been allowed with the argumentation that even though stable may contain bugs, users rely on the behaviour that stable has. They may know about a bug but may have worked around it (and the update may break the workaround) or they do not know about a bug but a fix for it may break a previously functional system. And of course as we all know: bugfixes are not zero-risk and do have chances on new bugs being introduced. Basically this argument is the update may break things. [...] I think there is room for us relaxing our policy for stable updates. Where upstream have a good track record of not breaking their own stable branch, I think providing those updates to our users is probably sensible. I don't think relax is the word but reinterpret. Why is the policy exactly the way it is? It's obvious that changes are allowed as security and point releases show. The why is obvious too: because security and/or severe malfunctions overweight the risk of breaking things *and* Debian release/security team try to minimize that risk by patching the bare minimum to achieve the intended result. That said, I find that to be the proper way for a maintenance policy and an interesting one to push forward to upstream maintainers: it's not Debian, it's proper engineering to strictly segregate bug fixing from new functionality; it's proper engineering comitting for long term maintenance for selected versions of your software and it's proper engineering taking responsibility for the software one publishes and the bugs that come along with it. So, may I propose (if not already done) a document that outlines with enough detail what Debian maintenance policy is and why from an upstream point of view, and then allow for within Stable upgrades for software that has demonstrated to pursue the same standards as Debian? Kindof a quality seal that will allow to push minor versions: it would mean more with less since Debian maintainers wouldn't need to maintain their own patch sets and they would know in advance what the proper version to pack for Stable is (the one that upstream publishes for long term maintenance within the time-frame for the new Stable version). For those upstreamers interested in doing the things the proper way, they could find Debian people to be knowledgeable and helpful about it (since they've been doing it for years and it's in their own interest). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102011709.40161.jesus.nava...@undominio.net
Re: Upstream stable branches and Debian freeze
2011/2/1 Jesús M. Navarro jesus.nava...@undominio.net: So, may I propose (if not already done) a document that outlines with enough detail what Debian maintenance policy is and why from an upstream point of view, and then allow for within Stable upgrades for software that has demonstrated to pursue the same standards as Debian? Kindof a quality seal that will allow to push minor versions: it would mean more with less since Debian maintainers wouldn't need to maintain their own patch sets and they would know in advance what the proper version to pack for Stable is (the one that upstream publishes for long term maintenance within the time-frame for the new Stable version). For those upstreamers interested in doing the things the proper way, they could find Debian people to be knowledgeable and helpful about it (since they've been doing it for years and it's in their own interest). It depends on the kind of package and computer whether it makes sense. For production servers, stability is (way) more important. For desktop users and packages like browsers, which might be fast moving, new features might be more important. Upstream for Firefox and Chrome are not going to provide stable branches that are maintained for two+ years. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinOqYUc=g6gy9ckkjsgfkp6jzs8nxsws0qst...@mail.gmail.com
Re: Upstream stable branches and Debian freeze
Hi, Olaf: On Tuesday 01 February 2011 17:18:58 Olaf van der Spek wrote: 2011/2/1 Jesús M. Navarro jesus.nava...@undominio.net: So, may I propose (if not already done) a document that outlines with enough detail what Debian maintenance policy is and why from an upstream point of view, and then allow for within Stable upgrades for software that has demonstrated to pursue the same standards as Debian? Kindof a quality seal that will allow to push minor versions: it would mean more with less since Debian maintainers wouldn't need to maintain their own patch sets and they would know in advance what the proper version to pack for Stable is (the one that upstream publishes for long term maintenance within the time-frame for the new Stable version). For those upstreamers interested in doing the things the proper way, they could find Debian people to be knowledgeable and helpful about it (since they've been doing it for years and it's in their own interest). It depends on the kind of package and computer whether it makes sense. For production servers, stability is (way) more important. For desktop users and packages like browsers, which might be fast moving, new features might be more important. It depends more on the use case than in the package. As long as there's no interface with externals/third parties it makes more sense add new functionality only as needed, no matter if it's a kernel or a web browser. Upstream for Firefox and Chrome are not going to provide stable branches that are maintained for two+ years. That's up to them and, in fact, it makes no difference: they won't get the quality seal and their maintenance procedures within Debian will be just the way they are now so no loss from this side. On the other hand, each and every package that would go under the quality seal umbrella would mean an easier day for the package maintainer, a higher quality software for everybody and, on a side note, source of unintended benefits for everybody (remember Mark Shuttleworth's interest on sincronizing packages among distributions? It would be a natural outcome if a significant number of upstreamers aligned to the quality seal idea: distributions interested on stability would just converge around the long term versions distributed by upstream). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102011740.20430.jesus.nava...@undominio.net
Upstream stable branches and Debian freeze
Hi, I'm the upstream maintainer of the Music Player Daemon project, and receive a number of support requests / bug reports from Debian users who use the outdated version 0.15.12 of mpd, currently in testing. These bugs were already fixed in newer maintenance releases. I know that Debian does not upgrade upstream versions at this point. However, I would like to know if upgrading within an upstream stable branch like MPD's v0.15.x would be acceptable. It seems common practice to cherry-pick upstream patches, and apply them to the old Debian package. That however seems like a waste of time, since all commits in our stable branch are bug fixes which would need to be picked, and in the end, you would essentially have version 0.15.15 which prints 0.15.12 on --version, just to fulfill Debian's policy. For me personally, this boils down to the question: shall I continue to maintain the old branch v0.15.x? (there is also v0.16.x which is also in maintenance mode) If Debian picks up my maintenance releases, then it's worth it to keep on maintaining the branch, to ensure that Debian users get the most stable MPD version. If not, I'll drop the branch, and fix bugs only on v0.16.x. Regards, Max Kellermann (Please keep me on Cc, I'm not subscribed) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110131142511.ga18...@squirrel.blarg.de
Re: Upstream stable branches and Debian freeze
Hi Dne Mon, 31 Jan 2011 15:25:11 +0100 Max Kellermann m...@duempel.org napsal(a): I'm the upstream maintainer of the Music Player Daemon project, and receive a number of support requests / bug reports from Debian users who use the outdated version 0.15.12 of mpd, currently in testing. These bugs were already fixed in newer maintenance releases. I know that Debian does not upgrade upstream versions at this point. However, I would like to know if upgrading within an upstream stable branch like MPD's v0.15.x would be acceptable. It's probably too late now, but you could definitely do it during freeze if it did fix some important bug. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Upstream stable branches and Debian freeze
Michal Čihař, le Mon 31 Jan 2011 16:01:54 +0100, a écrit : Dne Mon, 31 Jan 2011 15:25:11 +0100 Max Kellermann m...@duempel.org napsal(a): I'm the upstream maintainer of the Music Player Daemon project, and receive a number of support requests / bug reports from Debian users who use the outdated version 0.15.12 of mpd, currently in testing. These bugs were already fixed in newer maintenance releases. I know that Debian does not upgrade upstream versions at this point. However, I would like to know if upgrading within an upstream stable branch like MPD's v0.15.x would be acceptable. It's probably too late now, but you could definitely do it during freeze if it did fix some important bug. His question could be rephrased: will the 6.0.x updates be allowed to pick up new upstream stable fixes releases? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110131150933.gn6...@const.bordeaux.inria.fr
Re: Upstream stable branches and Debian freeze
On Mon, 31 Jan 2011 15:25:11 +0100, Max Kellermann wrote: Hi, I'm the upstream maintainer of the Music Player Daemon project, and receive a number of support requests / bug reports from Debian users who use the outdated version 0.15.12 of mpd, currently in testing. These bugs were already fixed in newer maintenance releases. I know that Debian does not upgrade upstream versions at this point. However, I would like to know if upgrading within an upstream stable branch like MPD's v0.15.x would be acceptable. It seems common practice to cherry-pick upstream patches, and apply them to the old Debian package. That however seems like a waste of time, since all commits in our stable branch are bug fixes which would need to be picked, and in the end, you would essentially have version 0.15.15 which prints 0.15.12 on --version, just to fulfill Debian's policy. For me personally, this boils down to the question: shall I continue to maintain the old branch v0.15.x? (there is also v0.16.x which is also in maintenance mode) It's too late now to make any changes for the initial squeeze release, but you (or the Debian maintainer) can propose an update for 6.0.1, which will be reviewed by the release team. If the changes have a low chance of breaking things, which it sounds like in this case, they will usually accept it. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110131105511.73108247.michael.s.gilb...@gmail.com
Re: Upstream stable branches and Debian freeze
Quoting Max Kellermann (m...@duempel.org): I'm the upstream maintainer of the Music Player Daemon project, and receive a number of support requests / bug reports from Debian users who use the outdated version 0.15.12 of mpd, currently in testing. These bugs were already fixed in newer maintenance releases. I know that Debian does not upgrade upstream versions at this point. However, I would like to know if upgrading within an upstream stable branch like MPD's v0.15.x would be acceptable. I have about the same concern for samba..:-) (except that I'm not samba upstream as most people know...) For the lenny release cycle, we (samba maintainers...indeed often me) pushed several upstream fixes for bugs reported in Debian with severity important. This, in addition, of course, to the security fixes. This has been accepted by the Stable Release Team in each case. However, upstream's policy in their stable branches is alway to only fix important bugs (they don't call them this way...but the definition is fairly close to Debian's). So, *in the case of samba*, I can guarantee that the user's (indeed sysadmin's) experience is much improved if (s)he can follow the upstream minor releases. So, I'm strongly considering asking the SRT if it would be OK to track samba 3.5 branch along the life of squeeze (we'll be releasing with samba 3.5.6). This is certainly a trade-off to do on a case-by-case basis. In the case of samba, I'm as certain as one can be that upstream's policy is strict enough for me to more or less blindly follow them (particularly just right now as samba 3.5 has aged enough in the Samba Team barrels...;-)). The situation may be different for other upstreams, of course. signature.asc Description: Digital signature
Re: Upstream stable branches and Debian freeze
]] Samuel Thibault Hi, | His question could be rephrased: will the 6.0.x updates be allowed to | pick up new upstream stable fixes releases? While I can't speak for the release team (neither the stable or the «regular» one), I know that postgresql stable releases are generally allowed into new stable releases, since they're about as picky and conservative as we are with regards to what the backport to their stable branches. So, I think this depends on what the policy for the upstream branch is. If it's just important fixes, it might be. If it's a random mix of new features, bug fixes and so on, it's less likely. Best regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4hk964c@qurzaw.varnish-software.com
