Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Sat, Aug 31, 2013 at 5:57 PM, Michael Gilbert wrote: I've been meaning to add more informative info to the security-tracker about end-of-lifed packages. Right now you can see that info in the raw tracker data, but the generate web pages don't make that clear at all. Is the raw tracker data you are talking about? http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=co As far as I can tell users are very unlikely to notice this. The tags are exported to the Packages files in wheezy but apt doesn't do anything with that information. debsecan doesn't seem to have support for these secteam tags and also lacks integration with apt (#431804). debsecan needs more people helping with it. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6F11mpP2kn_Gn==6m4z-5d85i-qerfsbyuaevvzw-x...@mail.gmail.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
❦ 1 septembre 2013 12:04 CEST, Paul Wise p...@debian.org : http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=co As far as I can tell users are very unlikely to notice this. The tags are exported to the Packages files in wheezy but apt doesn't do anything with that information. debsecan doesn't seem to have support for these secteam tags and also lacks integration with apt (#431804). debsecan needs more people helping with it. Or a maintainer willing to accept patches: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470065 -- Use the telephone test for readability. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Sun, Sep 1, 2013 at 6:04 AM, Paul Wise wrote: On Sat, Aug 31, 2013 at 5:57 PM, Michael Gilbert wrote: I've been meaning to add more informative info to the security-tracker about end-of-lifed packages. Right now you can see that info in the raw tracker data, but the generate web pages don't make that clear at all. Is the raw tracker data you are talking about? http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=co No, the end-of-life tags in: http://anonscm.debian.org/viewvc/secure-testing/data/CVE/list?view=co As far as I can tell users are very unlikely to notice this. The tags are exported to the Packages files in wheezy but apt doesn't do anything with that information. debsecan doesn't seem to have support for these secteam tags and also lacks integration with apt (#431804). debsecan needs more people helping with it. Yes, this information really needs to be more user visible. Assistance with the security tracker is welcomed. debsecan hasn't had a maintainer upload in almost two years, so nmus fixing its open issues are quite appropriate. 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/CANTw=MMG2pZsHbMPzFUDFo6vd5MR1L79rcwHJGTEO__R=+p...@mail.gmail.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 4:50 PM, Pau Garcia i Quiles wrote: On Tue, Aug 27, 2013 at 7:18 PM, Russ Allbery wrote: IMHO the Security Team should not act as fixers themselves but more as proxies, passing information about a security issue to the maintainer of the package. And what happens then if the maintainer doesn't respond? Then, and only then, as a last resort, the Security Team / LTS Team takes care of the problem I'm pretty sure that this is a kind of wishful thinking. History has shown that people in debian will not tolerate being told what to do. If you want an itch scratched, you simply have to scratch it yourself. If you're interested in improving debian security, please become a contributor: https://security-tracker.debian.org/tracker/data/report 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/CANTw=MNEMvfZ94ud=698tpxxxjt3tqupdwhw7wkdglswjmr...@mail.gmail.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 9:58 AM, Simon McVittie wrote: On 27/08/13 14:32, Pau Garcia i Quiles wrote: What do you do with the 1 year of support Debian currently gives to oldstable? It's also 1 year you stopped using that version, so no technical challenge either. There does need to be some amount of overlap, because people can't necessarily upgrade machines (particularly servers) instantaneously on release day. Even a year of overlap seems rather long, though. Right now, its sort of a stagged overlap. For example web browser security updates are no longer happening in squeeze. Users are already expected to upgrade to wheezy for web browser security support. I've been meaning to add more informative info to the security-tracker about end-of-lifed packages. Right now you can see that info in the raw tracker data, but the generate web pages don't make that clear at all. 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/CANTw=mohhkkgu9-tv9yd8bfrf2kwchqkmfghwjl++xrfvne...@mail.gmail.com
Re: Dreamhost dumps Debian
Upgrading is easy is not really a valid retort. Though it does mitigate the cost, it does not eliminate it. Nobody wants to spend their automation budget on making upgrading easy enough to do on a whim. There are plenty of other concerns that automation must address that have nothing to do with this problem. Still completely disagree, spending a little to save lots in the future is always a good thing. Upgrading every 2 years vs. every 4 with more predictable time lines is quite obviously less desirable. Lets not forget that there is a bigger overlap (3 years) between Ubuntu LTS's, so when 14.04 comes out, they can start the move off 12.04, but they have _three years_ to complete it, which also means more time to report bugs and get them fixed in Ubuntu, etc. And if 16.04 comes around and they still have 12.04 kicking around in some dark corners, they have another year to finish that. That might well have something to do with it or as already mentioned more kernels or tested kernel configurations in the repo like 3.8 OTOH reducing staff for 4 years rather than two in a highly competitive hosting market to reduce costs may be important but if they are installing the way suggested then they are far far from that and frankly I wouldn't use them if they are installing like users do for a few machines as that doesn't reflect competence and bad practice shouldn't affect debian's processes so perhaps some more details are required as to why they do things in a way that makes the 5 year cycle matter. Your logic has a pretty big hole in it. Who said they would have to increase staff to get the upgrade done? Not really, assuming they have the most streamlined business to be as competitive as possible then that is certain if that's not the case then that removes the possibility of the cycle time being a problem in this particular regard. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/905251.72792...@smtp146.mail.ir2.yahoo.com
Re: Dreamhost dumps Debian
Clint Byrum spam...@debian.org writes: Dreamhost is a hosting company. It actually is quite possible that all 20,000 machines mentioned are unique snowflakes in this case. Though it is probably more likely that there at most 10,000 unique machines, with some customers having only one, but others having 3 or more. I would suspect that the exposed interface to the client of systems for which Dreamhost is maintaining the OS is something more like Apache and PHP 5.x. Which means the machines aren't really unique snowflakes from Dreamhost's perspective. They may each have unique client data installed on them, but that's not managed by Dreamhost. Yes, it's definitely a huge hassle to communicate to all of those customers to coordinate an upgrade from Apache 2.0 and PHP 5.x to Apache 2.2 and PHP 5.x+1. But I'm dubious that it's really 20,000 unique hassles. It's a hassle around a changed version of PHP with clients, a hassle around a new version of Perl with different clients, upgrades of a pile of backend database systems to a newer version of MySQL, and so forth. Each of those is real work, of course, but they don't multiply by number of machines, or at least not obviously. How long does FAI take to make a new machine? If it is more than 30 minutes then you need at least two FAI's going all the time to finish on time. It depends on how many packages you want FAI to install, but about five minutes. But with that many machines, you'd obviously parallelize, not do one at a time. Most of the work happens on the system being bootstrapped. You do want a fast local Debian mirror. I wasn't clear, I don't mean you'll do each one as a special snowflake in-place. I mean, 20,000 machines is simply a lot of machines to manage. No matter what, upgrading or replacing the OS all within a 1 year schedule that you do not control and cannot fully predict, is a big hassle. Oh, sure. But 20,000 machines is a lot of machines to manage for *anything* that you do, and *everything* you have to do across 20,000 machines is a big hassle. I don't think OS upgrades are a unique issue. That's why, when you have 20,000 machines, you staff up accordingly. Even assuming a sysadmin to system ratio of 1000:1 (which would be excellent and which would clearly imply a huge amount of homogeneity and automation), that's an operational group of 20 full-time people. The industry average ratio of systems to sysadmin is about 30:1 for physical systems and 80:1 for virtual systems, with common variation from 10:1 to 500:1. Dreamhost, as a hosting company instead of a more typical IT organization running things like financials, is obviously going to be pushing or exceeding the upper end of that, but I think 1000:1 is still fair as a guess. (Google is believed to be around 10,000:1, but that's after huge internal investments in specialized automation and huge efforts on absolute standardization and scaling, including tons of custom OS work and invention of their own file systems, things that I doubt Dreamhost has done.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87li3jwvc3@windlord.stanford.edu
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Thu, Aug 29, 2013 at 05:31:26PM +0200, Ondřej Surý wrote: So properly maintaining our stable/oldstable is a mandatory first step into being able to provide even longer support for random release we start to call the LTS. Whether we achieve that by throwing more manpower into the bunch, or splitting the archive into KEY packages (as defined in recent d-d-a email) and non-KEY packages, is different matter. So that means my question/suggestion is valid even for the non-LTS case, doesn't it? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20130830105846.ga20...@feivel.credativ.lan
Re: Dreamhost dumps Debian
I wasn't clear, I don't mean you'll do each one as a special snowflake in-place. I mean, 20,000 machines is simply a lot of machines to manage. No matter what, upgrading or replacing the OS all within a 1 year schedule that you do not control and cannot fully predict, is a big hassle. Well Unix caters well to changes of hardware so I disagree completely. You can easily workout what data on those 20,000 machines can be done once and copied over and sort out the rest. There are even systems like puppet that will handle imaging and scripting etc. automatically. OTOH reducing staff for 4 years rather than two in a highly competitive hosting market to reduce costs may be important but if they are installing the way suggested then they are far far from that and frankly I wouldn't use them if they are installing like users do for a few machines as that doesn't reflect competence and bad practice shouldn't affect debian's processes so perhaps some more details are required as to why they do things in a way that makes the 5 year cycle matter. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/451.78153...@smtp115.mail.ir2.yahoo.com
Re: Dreamhost dumps Debian
Excerpts from Kevin Chadwick's message of 2013-08-30 10:28:51 -0700: I wasn't clear, I don't mean you'll do each one as a special snowflake in-place. I mean, 20,000 machines is simply a lot of machines to manage. No matter what, upgrading or replacing the OS all within a 1 year schedule that you do not control and cannot fully predict, is a big hassle. Well Unix caters well to changes of hardware so I disagree completely. You can easily workout what data on those 20,000 machines can be done once and copied over and sort out the rest. There are even systems like puppet that will handle imaging and scripting etc. automatically. Upgrading is easy is not really a valid retort. Though it does mitigate the cost, it does not eliminate it. Nobody wants to spend their automation budget on making upgrading easy enough to do on a whim. There are plenty of other concerns that automation must address that have nothing to do with this problem. Upgrading every 2 years vs. every 4 with more predictable time lines is quite obviously less desirable. Lets not forget that there is a bigger overlap (3 years) between Ubuntu LTS's, so when 14.04 comes out, they can start the move off 12.04, but they have _three years_ to complete it, which also means more time to report bugs and get them fixed in Ubuntu, etc. And if 16.04 comes around and they still have 12.04 kicking around in some dark corners, they have another year to finish that. OTOH reducing staff for 4 years rather than two in a highly competitive hosting market to reduce costs may be important but if they are installing the way suggested then they are far far from that and frankly I wouldn't use them if they are installing like users do for a few machines as that doesn't reflect competence and bad practice shouldn't affect debian's processes so perhaps some more details are required as to why they do things in a way that makes the 5 year cycle matter. Your logic has a pretty big hole in it. Who said they would have to increase staff to get the upgrade done? They can complete the upgrade with less staff to begin with now. Also if they did increase staff, and there was a gap between upgrade periods, my guess is they can make use of that staff to do other things to reduce costs or increase profits. -- 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/1377885733-sup-6...@fewbar.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Hi, On Tue Aug 27, 2013 at 02:11:56 +0200, Thomas Goirand wrote: On 08/26/2013 12:33 PM, Neil McGovern wrote: I'm hoping that these raising of hands are also offers to help do the work to make it happen. Guys, if you want it to happen, raise your hands *now* like Gustavo did. Otherwise, please everyone: let this thread die and never raise the topic again in this list. I am raising my hand here. I am willing to support the debian security team. I will be able to do that during my paid work time, as my employer, credativ, is backing this. Mid-term goal should be a Debian LTS version, but we can only achieve this by enhancing the debian security team. Cheers, Martin -- Martin Zobel-Helas Teamleiter Betrieb Tel.: +49 (2161) 4643-196 Fax: +49 (2161) 4643-100 Email: martin.zobel-he...@credativ.de pgp fingerprint 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer signature.asc Description: Digital signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Thu, Aug 29, 2013 at 11:59 AM, Martin Zobel-Helas wrote: I am raising my hand here. I am willing to support the debian security team. I will be able to do that during my paid work time, as my employer, credativ, is backing this. Mid-term goal should be a Debian LTS version, but we can only achieve this by enhancing the debian security team. For yourself and anyone else who wants to get involved: Maintaining the security tracker data is a great way to start helping with security stuff: http://anonscm.debian.org/viewvc/secure-testing/doc/narrative_introduction?view=co https://security-tracker.debian.org/tracker/data/report Having debsecan (or a nagios check based on it) run on debian.org and credativ machines could be an interesting way forward. This is likely to require some triage of incoming issues since many of them are only a problem under specific conditions. The security audit efforts need reviving: http://www.debian.org/security/audit/ Targets for security updates can be found in the links on the front page of the security tracker: https://security-tracker.debian.org/tracker/ Procedures for security updates are in devref of course: http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security The codesearch site is useful for finding code copies, which are documented in SVN: http://codesearch.debian.net/ https://wiki.debian.org/EmbeddedCodeCopies It is also useful for finding potentially vulnerable code or the presence of specific issues. Some other stuff on the wiki: https://wiki.debian.org/Teams/Security There are some efforts for running static analysis tools over the archive, which could be useful for finding more potential security issues. http://firewoes.debian.net/ http://qa.debian.org/daca/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6FZFpYagfYGYYSaQ6+_AfUSB1gaQzruJ9Suc6Fqv=u...@mail.gmail.com
Update policies for security bugs [Was, Re: Dreamhost dumps Debian]
Steve Langasek writes (Update policies for security bugs [Was, Re: Dreamhost dumps Debian]): I don't think this is incompatible with my contention that updates for security bugs should be driven by the security team. If we think a security fix should not be pushed *immediately* to users, then why should we postpone it until the next point release, instead of postponing it until they upgrade to the next stable release? Either it's an important security fix and we should push it out with a high priority, or it's not important - in which case no one should expect me to spend my time on fixing it in a stable update. Perhaps it has an intermediate level of importance. 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/21023.13428.494725.549...@chiark.greenend.org.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 04:33:38PM +0200, Ondřej Surý wrote: On Wed, Aug 28, 2013 at 4:29 PM, Michael Meskes mes...@debian.org wrote: Anyhow, I doubt we can reasonably expect to maintain *all* packages for a longer period. How about starting with a defined list of packages that we do care about in an LTS? I would start with just the basic system and the most important server packages. Well, and how about starting to look at RFH for packages you care about right now and help with security (and SPU) updates right now, even without LTS? How about not combining two different topics? I don't see a reason why a discussion about a way to provide LTS needs to get shot with the suggestion to help with some random package instead. Of course you definitely have a point in that some/a lot of packages need work, but I think it is also reasonable to discuss a strategy for a desirable (IMO) long-term goal. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20130829120849.ga28...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Thu, Aug 29, 2013 at 2:08 PM, Michael Meskes mes...@debian.org wrote: On Wed, Aug 28, 2013 at 04:33:38PM +0200, Ondřej Surý wrote: On Wed, Aug 28, 2013 at 4:29 PM, Michael Meskes mes...@debian.org wrote: Anyhow, I doubt we can reasonably expect to maintain *all* packages for a longer period. How about starting with a defined list of packages that we do care about in an LTS? I would start with just the basic system and the most important server packages. Well, and how about starting to look at RFH for packages you care about right now and help with security (and SPU) updates right now, even without LTS? How about not combining two different topics? I don't see a reason why a discussion about a way to provide LTS needs to get shot with the suggestion to help with some random package instead. Of course you definitely have a point in that some/a lot of packages need work, but I think it is also reasonable to discuss a strategy for a desirable (IMO) long-term goal. I don't think it's a different topic. If we are unable to support our stable and oldstable distributions in proper way due lack of time/manpower/interest/... (see Holger's email), then I can't imagine we can support a LTS release that would require even more time and manpower. So properly maintaining our stable/oldstable is a mandatory first step into being able to provide even longer support for random release we start to call the LTS. Whether we achieve that by throwing more manpower into the bunch, or splitting the archive into KEY packages (as defined in recent d-d-a email) and non-KEY packages, is different matter. O. -- Ondřej Surý ond...@sury.org Have you tried Knot DNS – https://www.knot-dns.cz/ – a high-performance authoritative-only DNS server
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 08/27/2013 06:53 AM, Pau Garcia i Quiles wrote: stable. Having a team of people like Mike, Michael, Gustavo, me, etc to take care of EVERY package is plain impossible, especially if we want 5 years i didn't say EVERY package i say the packages we care about we simply don't have the manpower to do it, neither the interest -- 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/521fa5a2.5070...@zumbi.com.ar
Re: Dreamhost dumps Debian
Excerpts from Russ Allbery's message of 2013-08-27 13:47:01 -0700: Clint Byrum spam...@debian.org writes: Perhaps you missed the blog post [1] details? About ten months ago, we realized that the next installation of Debian was upcoming, and after upgrading about 20,000 machines since Debian 6 (aka Squeeze) was released, we got pretty tired. Even if the script is _PERFECT_ and handles all of the changes in wheezy, just scheduling downtime and doing basic sanity checks on 20,000 machines would require an incredible effort. If you started on release day, and finished 2-3 machines per hour without taking any weekend days off, you would just barely finish in time for oldstable to reach EOL. I understand that they won't be done in a linear fashion, and some will truly be a 5 minute upgrade/reboot, but no matter how you swing it you are talking about a very expensive change. A few comments here from an enterprise administration perspective: First, if you have 20,000 machines, it's highly unlikely that each system will be a special snowflake. In that environment, you're instead talking about large swaths of systems that are effectively identical. You therefore don't have to repeat your sanity checking on each individual system, just on representives of the class, while using your configuration management system to ensure that all the systems in a class are identical. And in many cases you won't have to arrange downtime at all (because the systems are part of redundant pools). Dreamhost is a hosting company. It actually is quite possible that all 20,000 machines mentioned are unique snowflakes in this case. Though it is probably more likely that there at most 10,000 unique machines, with some customers having only one, but others having 3 or more. (would be great if one of them were on this thread to comment.. ;) Second, with 20,000 machines, there is no way that I would upgrade the systems. Debian's upgrade support is very important for individual systems, personal desktops, and smaller-scale environments, but even when you're at the point of several dozen systems, I would stop doing upgrades. At Stanford, we have a general policy that we rebuild systems from FAI for new Debian releases. All local data is kept isolated from the operating system (or, ideally, not even on that system, which is the most common case -- data is on separate database servers or on the network file system) so that you can just wipe the disk, build a new system on the current stable, and put the data back on (after performing whatever related upgrade process you need to perform). There's up-front development required for your new service model for the new operating system release, which you validate outside of production, and then the production rollout is mechanical system rebuilds (which usually take under 10 minutes with FAI and are parallelizable). I was actually thinking this too, and by upgrade I mean the software that serves each specific job is now wheezy. In-place upgrades for 20,000 machines would definitely be an incredible explosion of entropy and insanity. How long does FAI take to make a new machine? If it is more than 30 minutes then you need at least two FAI's going all the time to finish on time. My personal opinion is that if someone is scripting an upgrade to 20,000 systems and running it on those systems one-by-one, they're doing things at the wrong scale and with the wrong tools for that sort of environment. I wasn't clear, I don't mean you'll do each one as a special snowflake in-place. I mean, 20,000 machines is simply a lot of machines to manage. No matter what, upgrading or replacing the OS all within a 1 year schedule that you do not control and cannot fully predict, is a big hassle. -- 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/1377644203-sup-6...@fewbar.com
Re: Dreamhost dumps Debian
On Tue, 27 Aug 2013, Steve Langasek wrote: Well, I don't think that's a very good policy. I don't see why, if the bug is worth fixing in a stable release for security reasons, it should go through the stable-updates channel instead of the security channel. Going via stable-updates allows for more review and testing. For non-critical issues that seems a useful thing to have. I have used both channels for my packages in the past and was happy with the support I received from all involved teams every time. Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- 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/20130828080805.gu17...@anguilla.noreply.org
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Ma, 27 aug 13, 10:18:53, Russ Allbery wrote: Alternately, we could be far more aggressive about removing packages from oldstable, I suppose, but I don't think that's a good idea; that just leaves our users with exactly the sorts of choices that we're trying to avoid. I think it's much cleaner and better for our users to offer full security support and then retire the whole distribution at the same time. It makes planning considerably easier, among other things. Why not add something like this to the DSA: Unfortunately due to lack of resources there will be no updated packages for oldstable. For contributing a fix yourself contact the Debian LTS Team. Maybe even not include it in the DSA, but a special new adivsory, since DSAs have a lot of boilerplate and people may not be actually reading them. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Dreamhost dumps Debian
Steve Langasek writes (Re: Dreamhost dumps Debian): To me, being redirected to stable-updates constitutes a refusal/denial by the security team to use the security updates channel. Again, if it's a security issue that's not important enough to be an official security update, it's not important enough for me to spend time on it as a stable update either. [...] I'm afraid I don't see why you'd think that. Well, I don't think that's a very good policy. I don't see why, if the bug is worth fixing in a stable release for security reasons, it should go through the stable-updates channel instead of the security channel. [...] As Peter Palfrader points out stable-updates allows more review, because it doesn't suffer from the process problems caused by the need for secrecy. stable-updates are also made in less of a hurry. Furthermore, from the pov of the user, stable-updates are less disruptive. They can choose to take a point release when it comes out, or to defer it. When they do take a point release that can be a planned activity so that they're ready to deal with any regressions. 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/21021.54269.447114.427...@chiark.greenend.org.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Bastien ROUCARIES writes (Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)): Le 27 août 2013 19:32, Ian Jackson ijack...@chiark.greenend.org.uk a écrit : Worse: in practice, removing packages is invisible to the users and their package manager. The `removed' packages just remain, vulnerable, on the users' systems. Why not un this case creating an empty package depending of an non existing package ? Because we should leave the user the choice to keep using the unsupported software, rather than ripping it out from under them. 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/21021.54443.549428.950...@chiark.greenend.org.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Ian Jackson writes (Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)): Bastien ROUCARIES writes (Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)): Why not un this case creating an empty package depending of an non existing package ? Because we should leave the user the choice to keep using the unsupported software, rather than ripping it out from under them. Oh, wait, I don't think I read your proposal correctly. I'm not sure exactly what effect this would have but, presumably, mostly a complaint from the package manager ? 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/21021.54576.467036.418...@chiark.greenend.org.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 07:52:33PM +0100, Kevin Chadwick wrote: I don't really understand it myself as server packages and their dependencies tend to be stable and I tend to want the latest versions of dovecot, unbound etc.. However perhaps there is a divide here between servers which want longer support for few packages and desktops which want stable but secure yet as featureful as is sensible desktops. I think you have a very valid point here. I kind of doubt many people would like to run on a five year old desktop. Anyhow, I doubt we can reasonably expect to maintain *all* packages for a longer period. How about starting with a defined list of packages that we do care about in an LTS? I would start with just the basic system and the most important server packages. I wonder whether it makes sense to align our LTS with others, let's say Ubuntu, to reduce the workload for both sides? Finally what do we do with packages that are no longer supported by upstream? Do we essantially take over or do we restrict updates for as long as upstream provides fixes? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20130828142908.ga12...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 4:29 PM, Michael Meskes mes...@debian.org wrote: On Tue, Aug 27, 2013 at 07:52:33PM +0100, Kevin Chadwick wrote: I don't really understand it myself as server packages and their dependencies tend to be stable and I tend to want the latest versions of dovecot, unbound etc.. However perhaps there is a divide here between servers which want longer support for few packages and desktops which want stable but secure yet as featureful as is sensible desktops. I think you have a very valid point here. I kind of doubt many people would like to run on a five year old desktop. Anyhow, I doubt we can reasonably expect to maintain *all* packages for a longer period. How about starting with a defined list of packages that we do care about in an LTS? I would start with just the basic system and the most important server packages. Well, and how about starting to look at RFH for packages you care about right now and help with security (and SPU) updates right now, even without LTS? O. -- Ondřej Surý ond...@sury.org Have you tried Knot DNS – https://www.knot-dns.cz/ – a high-performance authoritative-only DNS server
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 04:29:08PM +0200, Michael Meskes wrote: On Tue, Aug 27, 2013 at 07:52:33PM +0100, Kevin Chadwick wrote: I don't really understand it myself as server packages and their dependencies tend to be stable and I tend to want the latest versions of dovecot, unbound etc.. However perhaps there is a divide here between servers which want longer support for few packages and desktops which want stable but secure yet as featureful as is sensible desktops. I think you have a very valid point here. I kind of doubt many people would like to run on a five year old desktop. Stats seem to disagree: http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=11qpcustomb=0 Neil -- signature.asc Description: Digital signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 4:55 PM, Neil McGovern ne...@debian.org wrote: I think you have a very valid point here. I kind of doubt many people would like to run on a five year old desktop. Stats seem to disagree: http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=11qpcustomb=0 Five year old desktop doesn't matter as long as you can install recent applications. That's not a problem on Windows or Mac, and it's not a problem on Linux (or any other Unix) either thanks to RPATH/RUNPATH with $ORIGIN . -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Update policies for security bugs [Was, Re: Dreamhost dumps Debian]
On Wed, Aug 28, 2013 at 11:42:05AM +0100, Ian Jackson wrote: Steve Langasek writes (Re: Dreamhost dumps Debian): To me, being redirected to stable-updates constitutes a refusal/denial by the security team to use the security updates channel. Again, if it's a security issue that's not important enough to be an official security update, it's not important enough for me to spend time on it as a stable update either. [...] I'm afraid I don't see why you'd think that. I don't see why this would be difficult to understand. We have a process for distributing critical security updates; if the security team triages a security fix as not important enough to be sent through this process, then it's not important enough for me to work on as a maintainer either. I have no shortage of bugs to spend my time on, and while I take security bugs seriously, I'm not going to spend my time working on a security issue that our security team has by definition said is not important. Well, I don't think that's a very good policy. I don't see why, if the bug is worth fixing in a stable release for security reasons, it should go through the stable-updates channel instead of the security channel. [...] As Peter Palfrader points out stable-updates allows more review, because it doesn't suffer from the process problems caused by the need for secrecy. stable-updates are also made in less of a hurry. Unless something has regressed in the past few years and I didn't hear about it, there is a 100% public unembargoed security queue that can be used for such uploads, avoiding the secrecy-related process problems. Furthermore, from the pov of the user, stable-updates are less disruptive. They can choose to take a point release when it comes out, or to defer it. When they do take a point release that can be a planned activity so that they're ready to deal with any regressions. I don't think this is incompatible with my contention that updates for security bugs should be driven by the security team. If we think a security fix should not be pushed *immediately* to users, then why should we postpone it until the next point release, instead of postponing it until they upgrade to the next stable release? Either it's an important security fix and we should push it out with a high priority, or it's not important - in which case no one should expect me to spend my time on fixing it in a stable update. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Dreamhost dumps Debian
On 2013-08-28 10:42, Ian Jackson wrote: As Peter Palfrader points out stable-updates allows more review, because it doesn't suffer from the process problems caused by the need for secrecy. stable-updates are also made in less of a hurry. Iff people actually test proposed-updates. The feedback so far has been very slim. (Probably nobody knows about stable-announce.) Furthermore, from the pov of the user, stable-updates are less disruptive. They can choose to take a point release when it comes out, or to defer it. When they do take a point release that can be a planned activity so that they're ready to deal with any regressions. Only if you mirror everything locally. And if you do that, you could also cherry-pick security updates. Kind regards Philipp Kern -- 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/fc74728f44519605e46b79e9b56c1...@hub.kern.lc
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 12:47 PM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
Ian Jackson writes (Re: Longer maintainance for (former) stable releases of
Debian (Re: Dreamhost dumps Debian)):
Bastien ROUCARIES writes (Re: Longer maintainance for (former) stable
releases of Debian (Re: Dreamhost dumps Debian)):
Why not un this case creating an empty package depending of an non existing
package ?
Because we should leave the user the choice to keep using the
unsupported software, rather than ripping it out from under them.
Oh, wait, I don't think I read your proposal correctly. I'm not sure
exactly what effect this would have but, presumably, mostly a
complaint from the package manager ?
Exactly refuse to upgrade install security.
Supose that a package badpackage is not supported by LTS.
LTS teams release a new version of package (arch-all):
Package: badpackage
Depends: ltsnotsupported, ${misc:Depends}
Architecture: all
Section: ltsnotsuported
Description: This package is not supported any more by LTS team
This package is not supported any more by LTS team.
.
This package is not carry a SECURITY RISK and was removed
from debian LTS.
.
THIS PACKAGE WAS INSECURE LTS REMOVED.
.
This package is not instalable any more and thus upgrade will fail.
.
If you care about this package please join the LTS team or backport
security fix.
.
If you accept the security risk you should add pinning see
http://www.debian.org/ltssecuritypinning.
.
Alternatly you could remove the reverse depends of this package,
but you should be warmed that some system functionnality may
be removed see http://www.debian.org/ltssecurityremoverdepends.
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/CAE2SPAauqH3KOKDEdVHhzxT1Pt_cNk=36hkpasp3qzbbzj8...@mail.gmail.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 02:11:56AM +0200, Thomas Goirand wrote: Guys, if you want it to happen, raise your hands *now* like Gustavo did. Otherwise, please everyone: let this thread die and never raise the topic again in this list. Raising my hand here ... Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20130827085613.ga10...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes mes...@debian.org wrote: Guys, if you want it to happen, raise your hands *now* like Gustavo did. Otherwise, please everyone: let this thread die and never raise the topic again in this list. Raising my hand here ... One more hand. But I'd like to stress we need *all* developers to be involved fix bugs (esp. security) in their packages in all the supported releases, not only in current-stable. Having a team of people like Mike, Michael, Gustavo, me, etc to take care of EVERY package is plain impossible, especially if we want 5 years support for the *whole* archive (IMHO Ubuntu did a smart move in regards to support when it split the archive in main/universe/multiverse and decided to support only main). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 11:53:47AM +0200, Pau Garcia i Quiles wrote: But I'd like to stress we need *all* developers to be involved fix bugs (esp. security) in their packages in all the supported releases, not only in current-stable. I am afraid I am not on board for this. I do not agree with requiring me to support old software for years and years after I've stopped using it. It is not something that interests me as a technical challenge; instead the task is tedious and boring. If you think this extra couple of years of support is something you want to work on, that's fine. Please don't think it is a goal everyone else in Debian agrees with, or is willing to work on. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- 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/20130827100346.ga6...@mavolio.codethink.co.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, 2013-08-27 at 11:53 +0200, Pau Garcia i Quiles wrote: On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes mes...@debian.org wrote: Guys, if you want it to happen, raise your hands *now* like Gustavo did. Otherwise, please everyone: let this thread die and never raise the topic again in this list. Raising my hand here ... One more hand. But I'd like to stress we need *all* developers to be involved fix bugs (esp. security) in their packages in all the supported releases, not only in current-stable. [...] The challenge was: who is willing to do the work. Your answer is: me, but only everyone else helps. That doesn't answer the challenge at all. It's hard enough to get maintainers to fix bugs in current stable (backporting can be difficult, and some just don't care), let alone another 3 years of LTS. Ben. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: This is a digitally signed message part
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 11:41:58AM +0100, Ben Hutchings wrote: The challenge was: who is willing to do the work. Your answer is: me, but only everyone else helps. That doesn't answer the challenge at all. It's hard enough to get maintainers to fix bugs in current stable (backporting can be difficult, and some just don't care), let alone another 3 years of LTS. Indeed. Look at the security team for example. In theory, if all maintainers cared enough about the older packages, we woudn't need the level of people we currently do. So, if you want to see a longer support period, then *first* you should join the teams who support the stable releases, and encourage others to do the same. Neil signature.asc Description: Digital signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 11:41:58AM +0100, Ben Hutchings wrote: The challenge was: who is willing to do the work. Your answer is: me, but only everyone else helps. That doesn't answer the challenge at all. Agreed. It's hard enough to get maintainers to fix bugs in current stable (backporting can be difficult, and some just don't care), let alone another 3 years of LTS. Which brings up the interesting question how it works for stable now. How often do bigs get fixed by the security team and how often by maintainers themselves? How much work is this for the security team? Yes, I know, the older the software gets, the more difficult it is to backport patches, if at all possible. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20130827122809.ga20...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 2:09 PM, Neil McGovern n...@halon.org.uk wrote: Indeed. Look at the security team for example. In theory, if all maintainers cared enough about the older packages, we woudn't need the level of people we currently do. IMHO the Security Team should not act as fixers themselves but more as proxies, passing information about a security issue to the maintainer of the package. Maintainers are not always fully aware some old version of their package is affected by a security issue. OTOH, the Security Team is continually monitoring CVEs, etc. Or at least, that's how I'd like the Security Team to work. It would alleviate the burden on them and move the bugfixing/security fixing to the people who know the package better and are probably in touch with upstream. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 08/27/2013 11:53 AM, Pau Garcia i Quiles wrote: On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes mes...@debian.org mailto:mes...@debian.org wrote: Guys, if you want it to happen, raise your hands *now* like Gustavo did. Otherwise, please everyone: let this thread die and never raise the topic again in this list. Raising my hand here ... One more hand. Cool, thanks. So, we are now 4, I think that's good enough to plan on doing something. But I'd like to stress we need *all* developers to be involved fix bugs (esp. security) in their packages in all the supported releases, not only in current-stable. Having a team of people like Mike, Michael, Gustavo, me, etc to take care of EVERY package is plain impossible, especially if we want 5 years support for the *whole* archive That's not my plan. My plan is to do as much as we can for the packages we care about. For example, I need security updates for bind9, apache2, postfix and such. I'm not interested at all in doing any Desktop software maintenance (my laptop is using at least Stable, and sometimes testing (when close to a release)). (IMHO Ubuntu did a smart move in regards to support when it split the archive in main/universe/multiverse and decided to support only main). I don't see any smartness when declaring that things are community maintained (eg: the work is done in Debian, and sync if we ask...). It's just that they decided not to take responsibility for part of the archive. What we could do, would be to track what needs to be patched and what has already been fixed. If our users have a clear list of what is maintained or not, then that's enough to me. On 08/27/2013 12:03 PM, Lars Wirzenius wrote: I am afraid I am not on board for this. I do not agree with requiring me to support old software for years and years after I've stopped using it. I don't think anyone wants to *require* this from anyone. At least that's not my plan. It is not something that interests me as a technical challenge; instead the task is tedious and boring. I agree, it's boring and not interesting. Though I need it for my company online services, and so does a lot of people. My idea is just to gather workforces of those who do it privately (like some already reported in this thread) and put that in a single (trusted) repository, then see how it goes. If it gains traction after Squeeze is EOL, then we can push the idea further and make it more official, after Wheezy is EOL. Cheers, Thomas -- 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/521caa35.6010...@debian.org
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 12:03 PM, Lars Wirzenius l...@liw.fi wrote: On Tue, Aug 27, 2013 at 11:53:47AM +0200, Pau Garcia i Quiles wrote: But I'd like to stress we need *all* developers to be involved fix bugs (esp. security) in their packages in all the supported releases, not only in current-stable. I am afraid I am not on board for this. I do not agree with requiring me to support old software for years and years after I've stopped using it. It is not something that interests me as a technical challenge; instead the task is tedious and boring. (I don't want this to sound rude or smartass but genuinely interested because I'm surprised more DDs think like you, as I discovered in the DreamHost thread) What do you do with the 1 year of support Debian currently gives to oldstable? It's also 1 year you stopped using that version, so no technical challenge either. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 08/27/2013 12:41 PM, Ben Hutchings wrote: It's hard enough to get maintainers to fix bugs in current stable (backporting can be difficult, and some just don't care), let alone another 3 years of LTS. Ben. I agree with what you wrote above Ben. Though that is not in a direct relation with what we can do for packages we care about (I already gave a small list of very important packages for me). Also, what one has to do currently to get packages updated in stable is demotivating (don't get me wrong: I do understand why we have things like they are in Stable, though one got to be blind to not see the demotivating side of it). I don't intend to implement such administrative overhead for updating this very-old-stable security repository. If we are only a small group of volunteer working on it, it will be easier to implement as well. Thomas -- 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/521cabed.5080...@debian.org
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 08/27/2013 02:28 PM, Michael Meskes wrote: Which brings up the interesting question how it works for stable now. How often do bigs get fixed by the security team and how often by maintainers themselves? How much work is this for the security team? Yes, I know, the older the software gets, the more difficult it is to backport patches, if at all possible. Michael I too, would like to know these stats. Thomas P.S: Before this thread, I thought updates were always updated by maintainers, and not by the security team. -- 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/521cacb4.8090...@debian.org
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 27/08/13 14:32, Pau Garcia i Quiles wrote: What do you do with the 1 year of support Debian currently gives to oldstable? It's also 1 year you stopped using that version, so no technical challenge either. There does need to be some amount of overlap, because people can't necessarily upgrade machines (particularly servers) instantaneously on release day. Even a year of overlap seems rather long, though. When there are serious bugs in my packages, I backport fixes to stable, then weigh up the benefit of also backporting to oldstable vs. the time I expect it to take and the risk of regressions. For things that didn't merit a DSA (e.g. DoS via a remotely-triggerable NULL dereference in desktop software), my conclusion has often been the risk of regressions is too close to the expected benefit, I'm not going to bother. After all, if I accidentally introduce a crash bug, that's a DoS that applies to everyone, not just people whose IM contacts were actively trying to exploit a vulnerability. Sorting out security vulnerabilities is something I do because I feel responsible for packages, rather than something I do because it's fun - doubly so for oldstable, where a diminishing number of people actually care about the vulnerability. S -- 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/521cb06b.2050...@debian.org
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Pau Garcia i Quiles pgqui...@elpauer.org writes: IMHO the Security Team should not act as fixers themselves but more as proxies, passing information about a security issue to the maintainer of the package. And what happens then if the maintainer doesn't respond? If we're going to offer meaningful security support, we have to have a bug-fixer of last resort, and that's the party most stressed by extending security support. Particularly since that for every year we extend it, more maintainers will be uninterested in doing so for their own packages. Alternately, we could be far more aggressive about removing packages from oldstable, I suppose, but I don't think that's a good idea; that just leaves our users with exactly the sorts of choices that we're trying to avoid. I think it's much cleaner and better for our users to offer full security support and then retire the whole distribution at the same time. It makes planning considerably easier, among other things. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ppszjblu@windlord.stanford.edu
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Russ Allbery writes (Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)): If we're going to offer meaningful security support, we have to have a bug-fixer of last resort, and that's the party most stressed by extending security support. Particularly since that for every year we extend it, more maintainers will be uninterested in doing so for their own packages. This is for the the key point. In practice fairly few maintainers are going to be willing to put in extra effort for longer support - and particularly not in the cases where this is most difficult. So any proposal to do an LTS involves almost all of the extra security effort falling on the LTS security team. That we don't have an LTS security team composed of people willing to shoulder that burden is the reason we don't have an LTS. Statements that maintainers should help out are not encouraging. If it turns out that there are people who _do_ want to do that work, with a minimum of concrete help from maintainers, then of course that is to be encouraged. Alternately, we could be far more aggressive about removing packages from oldstable, I suppose, but I don't think that's a good idea; that just leaves our users with exactly the sorts of choices that we're trying to avoid. I think it's much cleaner and better for our users to offer full security support and then retire the whole distribution at the same time. It makes planning considerably easier, among other things. Worse: in practice, removing packages is invisible to the users and their package manager. The `removed' packages just remain, vulnerable, on the users' systems. 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/21020.58018.931259.723...@chiark.greenend.org.uk
Re: Dreamhost dumps Debian
Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. I don't think the problem here is with Large hosting companies not having made their scripts etc. good enough. I don't think it has anything to do with size, or the type of company, or even the activity. I believe that the short life cycles of our stable releases is a problem for *MANY* companies. Dreamhost is the tree hiding the forest. I can't see how it can be such a problem if they have well written scripts. Run it on a new system, update the script or files to cater for any fallout, deploy and larger companies deploy to more systems so it is less taxing or more systems are deployed for the same effort. Do they need to get some kind of long drawn out certification like out of date Android images. OTOH towards the end of a debian stable life cycle (ignoring extended security support) you already find software that is problematic to run atleast for desktops due to requiring newer QT to compile etc., meaning it's often easier to use a chroot of Ubuntu etc. to run the latest kdevelop or ffmpeg with webm support (I admit I haven't delved into the backports yet as I only knew they existed recently, but would still be wary of any packages with far reaching dependencies). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/575000.76357...@smtp104.mail.ir2.yahoo.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Alternately, we could be far more aggressive about removing packages from oldstable, I suppose, but I don't think that's a good idea; that just leaves our users with exactly the sorts of choices that we're trying to avoid. I think it's much cleaner and better for our users to offer full security support and then retire the whole distribution at the same time. It makes planning considerably easier, among other things. I don't really understand it myself as server packages and their dependencies tend to be stable and I tend to want the latest versions of dovecot, unbound etc.. However perhaps there is a divide here between servers which want longer support for few packages and desktops which want stable but secure yet as featureful as is sensible desktops. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/52116.2947...@smtp149.mail.ir2.yahoo.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Le 27 août 2013 19:32, Ian Jackson ijack...@chiark.greenend.org.uk a écrit : Russ Allbery writes (Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)): If we're going to offer meaningful security support, we have to have a bug-fixer of last resort, and that's the party most stressed by extending security support. Particularly since that for every year we extend it, more maintainers will be uninterested in doing so for their own packages. This is for the the key point. In practice fairly few maintainers are going to be willing to put in extra effort for longer support - and particularly not in the cases where this is most difficult. So any proposal to do an LTS involves almost all of the extra security effort falling on the LTS security team. That we don't have an LTS security team composed of people willing to shoulder that burden is the reason we don't have an LTS. Statements that maintainers should help out are not encouraging. If it turns out that there are people who _do_ want to do that work, with a minimum of concrete help from maintainers, then of course that is to be encouraged. Alternately, we could be far more aggressive about removing packages from oldstable, I suppose, but I don't think that's a good idea; that just leaves our users with exactly the sorts of choices that we're trying to avoid. I think it's much cleaner and better for our users to offer full security support and then retire the whole distribution at the same time. It makes planning considerably easier, among other things. Worse: in practice, removing packages is invisible to the users and their package manager. The `removed' packages just remain, vulnerable, on the users' systems. Why not un this case creating an empty package depending of an non existing package ? 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/21020.58018.931259.723...@chiark.greenend.org.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 7:18 PM, Russ Allbery r...@debian.org wrote: IMHO the Security Team should not act as fixers themselves but more as proxies, passing information about a security issue to the maintainer of the package. And what happens then if the maintainer doesn't respond? Then, and only then, as a last resort, the Security Team / LTS Team takes care of the problem -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
Clint Byrum spam...@debian.org writes: Perhaps you missed the blog post [1] details? About ten months ago, we realized that the next installation of Debian was upcoming, and after upgrading about 20,000 machines since Debian 6 (aka Squeeze) was released, we got pretty tired. Even if the script is _PERFECT_ and handles all of the changes in wheezy, just scheduling downtime and doing basic sanity checks on 20,000 machines would require an incredible effort. If you started on release day, and finished 2-3 machines per hour without taking any weekend days off, you would just barely finish in time for oldstable to reach EOL. I understand that they won't be done in a linear fashion, and some will truly be a 5 minute upgrade/reboot, but no matter how you swing it you are talking about a very expensive change. A few comments here from an enterprise administration perspective: First, if you have 20,000 machines, it's highly unlikely that each system will be a special snowflake. In that environment, you're instead talking about large swaths of systems that are effectively identical. You therefore don't have to repeat your sanity checking on each individual system, just on representives of the class, while using your configuration management system to ensure that all the systems in a class are identical. And in many cases you won't have to arrange downtime at all (because the systems are part of redundant pools). Second, with 20,000 machines, there is no way that I would upgrade the systems. Debian's upgrade support is very important for individual systems, personal desktops, and smaller-scale environments, but even when you're at the point of several dozen systems, I would stop doing upgrades. At Stanford, we have a general policy that we rebuild systems from FAI for new Debian releases. All local data is kept isolated from the operating system (or, ideally, not even on that system, which is the most common case -- data is on separate database servers or on the network file system) so that you can just wipe the disk, build a new system on the current stable, and put the data back on (after performing whatever related upgrade process you need to perform). There's up-front development required for your new service model for the new operating system release, which you validate outside of production, and then the production rollout is mechanical system rebuilds (which usually take under 10 minutes with FAI and are parallelizable). My personal opinion is that if someone is scripting an upgrade to 20,000 systems and running it on those systems one-by-one, they're doing things at the wrong scale and with the wrong tools for that sort of environment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8738pu6euy@windlord.stanford.edu
Re: Dreamhost dumps Debian
Excerpts from Kevin Chadwick's message of 2013-08-27 11:45:34 -0700: Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. I don't think the problem here is with Large hosting companies not having made their scripts etc. good enough. I don't think it has anything to do with size, or the type of company, or even the activity. I believe that the short life cycles of our stable releases is a problem for *MANY* companies. Dreamhost is the tree hiding the forest. I can't see how it can be such a problem if they have well written scripts. Run it on a new system, update the script or files to cater for any fallout, deploy and larger companies deploy to more systems so it is less taxing or more systems are deployed for the same effort. Do they need to get some kind of long drawn out certification like out of date Android images. OTOH towards the end of a debian stable life cycle (ignoring extended security support) you already find software that is problematic to run atleast for desktops due to requiring newer QT to compile etc., meaning it's often easier to use a chroot of Ubuntu etc. to run the latest kdevelop or ffmpeg with webm support (I admit I haven't delved into the backports yet as I only knew they existed recently, but would still be wary of any packages with far reaching dependencies). Perhaps you missed the blog post [1] details? About ten months ago, we realized that the next installation of Debian was upcoming, and after upgrading about 20,000 machines since Debian 6 (aka Squeeze) was released, we got pretty tired. Even if the script is _PERFECT_ and handles all of the changes in wheezy, just scheduling downtime and doing basic sanity checks on 20,000 machines would require an incredible effort. If you started on release day, and finished 2-3 machines per hour without taking any weekend days off, you would just barely finish in time for oldstable to reach EOL. I understand that they won't be done in a linear fashion, and some will truly be a 5 minute upgrade/reboot, but no matter how you swing it you are talking about a very expensive change. This is one of the things driving people to the more cloud/IaaS model where individual machines are not precious and comprehensive testing is intrinsic to the whole process. For people who already are in that model, wheezy's release is a couple of days of test/fix/push and then yaaay! we can remove all of our hacks to work around 3 year old bugs in squeeze. [1] http://www.dreamhost.com/dreamscape/2013/06/03/change-is-in-the-air-dreamhost-upgrades/ -- 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/1377633770-sup-2...@fewbar.com
Re: Dreamhost dumps Debian
Russ Allbery r...@debian.org schrieb: Pau Garcia i Quiles pgqui...@elpauer.org writes: On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery r...@debian.org wrote: My experience is that I can just barely manage to convince upstreams to look over my backports of security patches to packages in oldstable What makes you think Ubuntu, Red Hat, etc ask upstream to look at their security patches for old versions or even approve them? Well, I suppose they might not, but I would find that even more disturbing. Red Hat hat upstream developers for almost all core code they support. From my experience these developers are involved in non-trivial RHEL backports (e.g. Bind) for older security releases. Cheers, Moritz -- 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/slrnl1q812.596@inutil.org
Re: Dreamhost dumps Debian
Steve Langasek vor...@debian.org schrieb: I understand the motivation (like everyone else they have more to do than they have time to do it in), but I think the outcome, whereby the security team denies use of the security update channel for non-critical security bugs and redirects maintainers to stable-updates instead, is unfortunate. We don't deny anything here, the current implementation of the security release process simply doesn't allow more fine-grained control on who/how security updates can be released. There were some internal discussions in the past and that's certainly an agenda topic on a future security team sprint. As far as I'm concerned, a security fix that isn't worth being pushed to security.debian.org is also not worth me spending time on as a maintainer to push to stable-updates. Pushing minor issues through point updates is the same process other enterprise distros use as well; SLES and RHEL also pile up minor issues for point updates instead of sending out a security update. In the past such minor issues were simply left unfixed in stable. Since a few years we've established a process to systematically keep the maintainers informed (Jonathan Wiltshire runs a notification bot for that). Cheers, Moritz -- 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/slrnl1q7rc.596@inutil.org
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Michael Meskes mes...@debian.org schrieb: Which brings up the interesting question how it works for stable now. How often do bigs get fixed by the security team and how often by maintainers themselves? No hard numbers, but I'd suppose half and half (i.e. cases, where the maintainer prepared the update, which of course still needs to be reviewed/tested by the person releasing it). Cheers, Moirtz -- 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/slrnl1q87r.596@inutil.org
Re: Dreamhost dumps Debian
On Tue, Aug 27, 2013 at 11:51:40PM +0200, Moritz Mühlenhoff wrote: Steve Langasek vor...@debian.org schrieb: I understand the motivation (like everyone else they have more to do than they have time to do it in), but I think the outcome, whereby the security team denies use of the security update channel for non-critical security bugs and redirects maintainers to stable-updates instead, is unfortunate. We don't deny anything here, the current implementation of the security release process simply doesn't allow more fine-grained control on who/how security updates can be released. Your answer doesn't match my experience as a maintainer. I have had non-critical security bugs answered by the security team with a request for upload to stable-updates, *not* to the security queue. If I were to upload those fixes to the security queue (which has been possible for years AFAIK, since the current security embargoed/unembargoed upload queues went into effect), what would the security team do with them? To me, being redirected to stable-updates constitutes a refusal/denial by the security team to use the security updates channel. Again, if it's a security issue that's not important enough to be an official security update, it's not important enough for me to spend time on it as a stable update either. And if the security team doesn't want a particular update as a DSA, I don't think they should be encouraging maintainers to spend time on a non-security stable update for the issue (which is what I've seen in the past). As far as I'm concerned, a security fix that isn't worth being pushed to security.debian.org is also not worth me spending time on as a maintainer to push to stable-updates. Pushing minor issues through point updates is the same process other enterprise distros use as well; SLES and RHEL also pile up minor issues for point updates instead of sending out a security update. In the past such minor issues were simply left unfixed in stable. Since a few years we've established a process to systematically keep the maintainers informed (Jonathan Wiltshire runs a notification bot for that). Well, I don't think that's a very good policy. I don't see why, if the bug is worth fixing in a stable release for security reasons, it should go through the stable-updates channel instead of the security channel. If the argument is that there are multiple low-urgency security bugs that are not worth individual uploads but that we should do roll-up uploads for once per point release, I don't think the current mechanism is doing a very good job of encouraging that. Maybe instead of pushing this over to the SRMs, if the security team thinks these bugs warrant a single update per package for the point release, it would be better to have these staged in the security queue and only released by the security team when it's point release time? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Hi Charles, On Di 20 Aug 2013 02:04:40 CEST Charles Plessy wrote: Altogether, it is a lot of work, but if we have enough people for doing it, think that it would be very positive for us. /me raises his hand for giving his work for longer maintainance of former Debian stable releases. For customer sites 2.5yrs + 1yr stable/oldstable does not suffice. Regards, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp3d52nUu7hL.pgp Description: Digitale PGP-Unterschrift
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Hi All, On 08/26/2013 09:31 AM, Mike Gabriel wrote: Hi Charles, On Di 20 Aug 2013 02:04:40 CEST Charles Plessy wrote: Altogether, it is a lot of work, but if we have enough people for doing it, think that it would be very positive for us. /me raises his hand for giving his work for longer maintainance of former Debian stable releases. For customer sites 2.5yrs + 1yr stable/oldstable does not suffice. Me too. I think we should match the five years Ubuntu LTS offers for at least part of the packages like Ubuntu does with main/universe [1] distinction. Cheers, Balint [1] https://help.ubuntu.com/community/Repositories signature.asc Description: OpenPGP digital signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Mon, Aug 26, 2013 at 11:14:25AM +0200, Balint Reczey wrote: Hi All, On 08/26/2013 09:31 AM, Mike Gabriel wrote: Hi Charles, On Di 20 Aug 2013 02:04:40 CEST Charles Plessy wrote: Altogether, it is a lot of work, but if we have enough people for doing it, think that it would be very positive for us. /me raises his hand for giving his work for longer maintainance of former Debian stable releases. For customer sites 2.5yrs + 1yr stable/oldstable does not suffice. Me too. I think we should match the five years Ubuntu LTS offers for at least part of the packages like Ubuntu does with main/universe [1] distinction. I'm hoping that these raising of hands are also offers to help do the work to make it happen. Neil -- signature.asc Description: Digital signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 08/26/2013 07:33 AM, Neil McGovern wrote: I'm hoping that these raising of hands are also offers to help do the work to make it happen. i offer help, we are interested on longer maintenance for some packages. i think we should start to coordinate, if is anybody else willing to help with the work maybe l...@lists.debian.org? if is not possible i can host a mailing list thanks -- 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/521b5166.80...@zumbi.com.ar
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
gustavo panizzo gfa schrieb am Monday, den 26. August 2013: On 08/26/2013 07:33 AM, Neil McGovern wrote: I'm hoping that these raising of hands are also offers to help do the work to make it happen. i offer help, we are interested on longer maintenance for some packages. i think we should start to coordinate, if is anybody else willing to help with the work maybe l...@lists.debian.org? if is not possible i can host a mailing list If there is really interest, a list on l.d.o wouldn't be a problem. Just follow http://www.debian.org/MailingLists/HOWTO_start_list.en.html and get a few seconders for the new list. Alex - with his Listmaster hat on -- 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/20130826132854.gc21...@hawking.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 26/08/13 at 10:00 -0300, gustavo panizzo gfa wrote: On 08/26/2013 07:33 AM, Neil McGovern wrote: I'm hoping that these raising of hands are also offers to help do the work to make it happen. i offer help, we are interested on longer maintenance for some packages. i think we should start to coordinate, if is anybody else willing to help with the work maybe l...@lists.debian.org? if is not possible i can host a mailing list Hi, Long-term support of stable releases was one of the reasons for the debian-companies@ initiative. I'm Ccing Michael Meskes, who is interested in coordinating this initiative. Lucas -- 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/20130826133040.ga1...@xanadu.blop.info
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Lucas Nussbaum schrieb am Monday, den 26. August 2013: On 26/08/13 at 10:00 -0300, gustavo panizzo gfa wrote: On 08/26/2013 07:33 AM, Neil McGovern wrote: I'm hoping that these raising of hands are also offers to help do the work to make it happen. i offer help, we are interested on longer maintenance for some packages. i think we should start to coordinate, if is anybody else willing to help with the work maybe l...@lists.debian.org? if is not possible i can host a mailing list Hi, Long-term support of stable releases was one of the reasons for the debian-companies@ initiative. I'm Ccing Michael Meskes, who is interested in coordinating this initiative. JFTR Coordination of LTS support should not go through a closed list. Alex -- 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/20130826141100.gd21...@hawking.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Long-term support of stable releases was one of the reasons for the debian-companies@ initiative. I'm Ccing Michael Meskes, who is interested in coordinating this initiative. JFTR Coordination of LTS support should not go through a closed list. And I don't think anyone suggested that. The debian-companies list is closed so that the companies can discuss where they want to go before going public with it. LTS is certainly something companies can and should help with, but more importantly something involving Debian as a whole. So this discussion should be public. Michael P.S.: Expect an email about the debian-companies initiative in the next couple days. -- Dr. Michael Meskes, Geschäftsführer/CEO Tel.: +49 (0)2161 / 46 43 0 E-Mail: michael.mes...@credativ.com IM: m...@jabber.credativ.com credativ international GmbH, HRB Moenchengladbach 15543, Hohenzollernstr. 133, 41061 Moenchengladbach, Germany Geschaeftsfuehrung: Dr. Michael Meskes, Joerg Folz = Global: http://credativ.com Canada: http://credativ.ca Germany: http://credativ.de India: http://credativ.in UK: http://credativ.co.uk USA: http://credativ.us = -- 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/521b65e9.8030...@credativ.com
Re: Dreamhost dumps Debian
Excerpts from Thomas Goirand's message of 2013-08-25 16:36:48 -0700: On 08/21/2013 05:45 PM, Kevin Chadwick wrote: Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. I don't think the problem here is with Large hosting companies not having made their scripts etc. good enough. I don't think it has anything to do with size, or the type of company, or even the activity. I believe that the short life cycles of our stable releases is a problem for *MANY* companies. Dreamhost is the tree hiding the forest. On 08/21/2013 07:08 PM, Clint Byrum wrote: It also doesn't hurt that OpenStack does all commit gating on Ubuntu, thus making Ubuntu the preferred platform (RHEL/CentOS will likely join Ubuntu in the gate someday soon). We asked Debian to be added. I hope that Debian will be added as a non-voting gating one day. I'll try to push for that to happen. I think doing will work out better than asking. The OpenStack infrastructure team is large, but they are also busy. Let me know if I can help guide you toward doing any of this work. I'm not on the team but I work closely with them quite a bit. DreamHost is a player in OpenStack, so it may be that the momentum of Ubuntu plus OpenStack is just too great to ignore with the added pain of the 2 year upgrade treadmill. I will ask them when I visit their offices at the next OpenStack LA meetup. :) Well, yes. But also OpenStack release cycles are even shorter than Debian! Only a year, then the old stable is not supported anymore. It doesn't make sense that Dreamhost is complaining about 2 years of security support, when they are now in the upgrade every 6 months OpenStack stuff... If they join me and become supporters of a kind of LTS for OpenStack, that'd be great, and I would be very supportive of it. It makes perfect sense. Most organizations I have worked for draw a clear line between things that make money and things that cost money. Your server OS is almost never a thing that makes you money, so you want to minimize it as a cost center. Because of that, an organization will think twice before any investment. Dreamhost is building a business on top of OpenStack, so they're happy to contribute to it and keep upgrading along with it. The investment they put in has a direct correlation to how much they can pull back out. The OS will have diminishing returns, so they'd like to reduce that footprint. It would be almost totally insane to try and build a public cloud with Essex or Folsom and expect that you can just install it and leave it alone for 1 year. Think about the advances in Grizzly. We should see some impressive advances in Havana as well. So building your direct business based on a dead duck stable release is just not a winning proposal. -- 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/1377533820-sup-1...@fewbar.com
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Mon, Aug 26, 2013 at 09:31:06AM +0200, Mike Gabriel wrote: Hi Charles, On Di 20 Aug 2013 02:04:40 CEST Charles Plessy wrote: Altogether, it is a lot of work, but if we have enough people for doing it, think that it would be very positive for us. /me raises his hand for giving his work for longer maintainance of former Debian stable releases. For customer sites 2.5yrs + 1yr stable/oldstable does not suffice. Regards, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb Depends: it's quite feasible to move between Debian stable releases without a problem. That gives you 2 years + a year to switch over + 2 years + a year - then your hardware's five year lifecycle is up and you're throwing it away. Red Hat Enterprise Linux will give you 10 years fully supported - but relatively little software and you end up having to use EPEL / Repoforge / RPMForge all unsupported repositories just to get software that's there out of the box in Debian. Ubuntu LTS - five years support but presumes nothing changes and you then find huge problems moving to the next LTS because the intervening releases have disappeared ... Debian's not so bad at all - especially considering that it's an all volunteer organisation: it's certainly stable enough to use anywhere for any purpose. AndyC -- 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/20130826181428.ga4...@galactic.demon.co.uk
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 26.08.2013 20:14, Andrew M.A. Cater wrote: Ubuntu LTS - five years support but presumes nothing changes and you then find huge problems moving to the next LTS because the intervening releases have disappeared ... You don't need the intervening releases, Ubuntu recommends doing LTS-LTS upgrades. e.g. 10.04 - 12.04 14.04. signature.asc Description: OpenPGP digital signature
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On 08/26/2013 12:33 PM, Neil McGovern wrote: I'm hoping that these raising of hands are also offers to help do the work to make it happen. Neil Which is why there's only a single person that replied to my workflow proposal ... to criticize my idea to do it on a separate infrastructure, but giving no idea how to solve the pb. Guys, if you want it to happen, raise your hands *now* like Gustavo did. Otherwise, please everyone: let this thread die and never raise the topic again in this list. Thomas -- 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/521beecc.9060...@debian.org
Re: Dreamhost dumps Debian
On 08/21/2013 05:45 PM, Kevin Chadwick wrote: Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. I don't think the problem here is with Large hosting companies not having made their scripts etc. good enough. I don't think it has anything to do with size, or the type of company, or even the activity. I believe that the short life cycles of our stable releases is a problem for *MANY* companies. Dreamhost is the tree hiding the forest. On 08/21/2013 07:08 PM, Clint Byrum wrote: It also doesn't hurt that OpenStack does all commit gating on Ubuntu, thus making Ubuntu the preferred platform (RHEL/CentOS will likely join Ubuntu in the gate someday soon). We asked Debian to be added. I hope that Debian will be added as a non-voting gating one day. I'll try to push for that to happen. DreamHost is a player in OpenStack, so it may be that the momentum of Ubuntu plus OpenStack is just too great to ignore with the added pain of the 2 year upgrade treadmill. I will ask them when I visit their offices at the next OpenStack LA meetup. :) Well, yes. But also OpenStack release cycles are even shorter than Debian! Only a year, then the old stable is not supported anymore. It doesn't make sense that Dreamhost is complaining about 2 years of security support, when they are now in the upgrade every 6 months OpenStack stuff... If they join me and become supporters of a kind of LTS for OpenStack, that'd be great, and I would be very supportive of it. Thomas -- 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/521a9510.6060...@debian.org
Re: Dreamhost dumps Debian
On 21/08/13 19:08, Clint Byrum wrote: Excerpts from Kevin Chadwick's message of 2013-08-21 08:45:27 -0700: My point of view is that Debian Stable should be aiming for whatever they believe the sweet point between stable and so usable without having problems is and maximising security. Aka maximising productivity and safety with no other concerns or compromises. Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. In fact they are best positioned man power wise to be able to set up a test rig and then deploy compared to small hosting companies. Does anyone even know for sure what the decision to switch was actually based upon? IIRC, the blog post cites exactly that, too short releases. There have been many comments about the 5 year security updates, but some people (sadly) don't think about that anyway, there are plenty of other decision making factors: For many users, the server is under warranty for 3 years, they are sometimes willing to risk or purchase another 1-2 years, total 5 years useful life for the server. They pick Ubuntu LTS or RHEL because it appears to be aligned with that. At the beginning, they chose the server and OS together. Unless there is a compelling reason, they don't want to risk upgrading the server half way through its useful life, risking any changes to hardware driver compatibility. They only want to spend time on those issues once: when they buy the server. Many commercial products also support legacy users and upgrades from (current-2) or (current-3) rather than just upgrading from the last major release. If Debian followed this model, then it would mean: a) security updates for squeeze would continue until jessie + 1 year b) a direct upgrade from squeeze to jessie (skipping wheezy) would be desirable (though not essential) Users who don't need or want bleeding edge stuff typically prefer to progress at that pace -- 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/52161386.5040...@pocock.com.au
Re: Dreamhost dumps Debian
Wookey woo...@wookware.org writes: +++ Ian Jackson [2013-08-20 16:05 +0100]: The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? Ideally it would be the people that want releases supported longer - e.g this dreamhost outfit, and presumably many organisations like them. Security support is a very parallelisable task, so a small amout of work by a lot of interested people ought to be do-able, but for whatever reason this never seems to have prospered as a model. It would be interesting to know why those entities that would like the LTS don't choose to do this. Is it just because we don't make it easy for them or because of free-loader aspects? I have always thought that there was room for a business selling longer-term Debian support. Maybe someone does? Quite. Perhaps we just need to have a long-term-support page with pointers to those willing to provide that service to others, as well as resources for those who would rather co-operate on providing it for themselves. Doing that sort of long term support is not an exciting task that volunteers can be expected to flock to -- especially if one knows that the people demanding it are often tight-fisted parasitical middle managers that have not even bothered to inform themselves that Debian is not just another competitor to the commercial distros. It seems to me that doing things to keep these people cheerful should attract a financial reward. If that made the somewhat more enlightened companies band together to share the LTS workload amongst themselves somehow (possibly by having a limited distribution model of some sort, restricted to members of the mutual-support-club) then that would be no bad thing either. I suppose it would be nice if we could provide this long term support, but really it's going to consume scarce volunteer effort which will almost certainly have a negative impact on the progress of Debian proper. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpkx4smiBR72.pgp Description: PGP signature
Re: Dreamhost dumps Debian
On Wed, Aug 21, 2013 at 1:48 AM, Ben Hutchings b...@decadent.org.uk wrote: Ubuntu uses a combination of driver backports and newer kernel versions in LTS releases. As Clint, Philipp and you say, I was wrong. However, I don't see that as an insurmountable argument against Debian LTSs. It just means the kernel and X/Wayland/nouveau/radeon teams need more people. Either that, or we just do not support new hardware for LTSs and let that to the vendor (not ideal but better have Debian LTS with no new hardware support than no Debian LTS, IMHO). The fact that I had never needed an LTS dot release made me think. I've been installing Ubuntu on servers and desktops since 4.10 at three companies and dozens of customers and never noticed/required a dot release for LTS: - On the desktop, it makes sense: we've almost always gone for the latest Ubuntu release, LTS or not (the only cases where we have used LTS for desktop was for military use and in that case the hardware was so old it was already old and well supported when LTS was released :-) ) - On the server, we always gone for very standard hardware and always installed the latest LTS. I guess the 2-year gap between LTSs is small enough to support newer hardware and the 5-year support term is big enough to justify the investment. Maybe we don't even need to make alternate Debian releases LTS but keep releasing every ~2 years and make every release a 5-year support LTS. Whatever we do, IMHO we need to do something. Debian is losing relevance as an installation release and it's becoming more and more an upstream for distributions (Ubuntu, Mint, etc), like SourceForge or GitHub are for us :-( -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
+++ Philip Hands [2013-08-21 10:35 +0100]: Wookey woo...@wookware.org writes: I have always thought that there was room for a business selling longer-term Debian support. Quite. It seems to me that doing things to keep these people cheerful should attract a financial reward. If that made the somewhat more enlightened companies band together to share the LTS workload amongst themselves somehow (possibly by having a limited distribution model of some sort, restricted to members of the mutual-support-club) then that would be no bad thing either. Right. Nothing stops security updates only going to those that paid, (although I'd expect them to be made available to all after some appropriate delay) although of course anyone who paid is free to re-distribute further, which could make the business fragile. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20130821102244.gn24...@stoneboat.aleph1.co.uk
Re: Dreamhost dumps Debian
Russ Allbery writes (Re: Dreamhost dumps Debian): Yeah, I know. But the number of such exceptions is relatively limited, enough so that we can issue security advisories saying they're not supported any more. It's not a comfortable compromise, but it seems to be a workable one. The LTS security policy is quite a bit broader in its implications. I think we need to do more than that. We need to arrange to automatically disable affected software (by default). (And that has to be done in a way that allows an affected user to re-enable it, and which is sorted out properly on upgrade.) 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/21012.42837.594440.318...@chiark.greenend.org.uk
Re: Dreamhost dumps Debian
Ian Jackson writes (Re: Dreamhost dumps Debian): I think we need to do more than that. We need to arrange to automatically disable affected software (by default). (And that has to be done in a way that allows an affected user to re-enable it, and which is sorted out properly on upgrade.) How about: Package: security-support Conflicts: iceweasel (= latest version in squeeze), ... And a hideous warning in the prerm. 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/21012.43645.971525.754...@chiark.greenend.org.uk
Re: Dreamhost dumps Debian
On Wed, Aug 21, 2013 at 10:35:34AM +0100, Philip Hands wrote: Wookey woo...@wookware.org writes: +++ Ian Jackson [2013-08-20 16:05 +0100]: The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? Ideally it would be the people that want releases supported longer - e.g this dreamhost outfit, and presumably many organisations like them. Security support is a very parallelisable task, so a small amout of work by a lot of interested people ought to be do-able, but for whatever reason this never seems to have prospered as a model. It would be interesting to know why those entities that would like the LTS don't choose to do this. Is it just because we don't make it easy for them or because of free-loader aspects? I have always thought that there was room for a business selling longer-term Debian support. Maybe someone does? Quite. Perhaps we just need to have a long-term-support page with pointers to those willing to provide that service to others, as well as resources for those who would rather co-operate on providing it for themselves. If that's all we provide, I think it's inevitable that businesses will continue to seek more turnkey solutions for long-term OS support. I believe that if Debian really wants to address the support gap, it's going to require some kind of officially-blessed security support service, and not just a web page telling users that they have options. It seems to me that doing things to keep these people cheerful should attract a financial reward. If that made the somewhat more enlightened companies band together to share the LTS workload amongst themselves somehow (possibly by having a limited distribution model of some sort, restricted to members of the mutual-support-club) then that would be no bad thing either. I agree that this is not something that's going to happen on a volunteer basis and realistically it needs to be funded somehow. I don't know what the right model for funding that would be, though I think it would be better for Debian as a whole if the end product could be made public. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Dreamhost dumps Debian
My point of view is that Debian Stable should be aiming for whatever they believe the sweet point between stable and so usable without having problems is and maximising security. Aka maximising productivity and safety with no other concerns or compromises. Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. In fact they are best positioned man power wise to be able to set up a test rig and then deploy compared to small hosting companies. Does anyone even know for sure what the decision to switch was actually based upon? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/887559.77544...@smtp140.mail.ir2.yahoo.com
Re: Dreamhost dumps Debian
On Wed, Aug 21, 2013 at 5:45 PM, Kevin Chadwick ma1l1i...@yahoo.co.ukwrote: Does anyone even know for sure what the decision to switch was actually based upon? Not really, but I have seen Debian rejected at several companies (customers) due to too-short support of old releases and too-far away releases. Both are real problems, regardless of why DreamHost decided to give up on Debian. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Wed, 21 Aug 2013 17:58:55 +0200, Pau Garcia i Quiles pgqui...@elpauer.org wrote: On Wed, Aug 21, 2013 at 5:45 PM, Kevin Chadwick ma1l1i...@yahoo.co.ukwrote: Does anyone even know for sure what the decision to switch was actually based upon? Not really, but I have seen Debian rejected at several companies (customers) due to too-short support of old releases and too-far away releases. Both are real problems, regardless of why DreamHost decided to give up on Debian. And if they switch to Ubuntu, they at least keep the solid technical base. If I have to see them go, it is good that they don't go to RHEL. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- 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/e1vcbpt-0004ef...@swivel.zugschlus.de
Re: Dreamhost dumps Debian
Excerpts from Kevin Chadwick's message of 2013-08-21 08:45:27 -0700: My point of view is that Debian Stable should be aiming for whatever they believe the sweet point between stable and so usable without having problems is and maximising security. Aka maximising productivity and safety with no other concerns or compromises. Large hosting companies not having made their scripts etc. good enough to ride out upgrades well should have nothing to do with any decision. In fact they are best positioned man power wise to be able to set up a test rig and then deploy compared to small hosting companies. Does anyone even know for sure what the decision to switch was actually based upon? IIRC, the blog post cites exactly that, too short releases. It also doesn't hurt that OpenStack does all commit gating on Ubuntu, thus making Ubuntu the preferred platform (RHEL/CentOS will likely join Ubuntu in the gate someday soon). DreamHost is a player in OpenStack, so it may be that the momentum of Ubuntu plus OpenStack is just too great to ignore with the added pain of the 2 year upgrade treadmill. I will ask them when I visit their offices at the next OpenStack LA meetup. :) -- 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/1377104733-sup-3...@fewbar.com
Re: Dreamhost dumps Debian
❦ 20 août 2013 02:04 CEST, Charles Plessy ple...@debian.org : Just to say that Debian usually has a 3 year support. Hi Vincent, this actually misleading for systems that have a long lifetime, where the turnover matters more, and in Debian it is 2 years. In some workplaces It means that every second year, some people would have to discuss and reach an agreement on whether it is doable to upgrade a service, how much it will cost, or should it be discontinued or not, etc. There, the 5-year or longer turnover in Ubuntu or CentOS is a winning point. I don't get the point. If we compare to 5-year, then Debian is 3-year. Ubuntu just defines its turnover to 5 years while we say next release plus one year which is usually 3 years. A long term support for core packages would definitely help me to advocate Debian in my workplace (and therefore use it on our servers instead of CentOS). Also, I do not think that it is relaxing our standards, since it is an additional service: there is no reduction in the current support. I would also welcome such a thing. But, we seem to not have the needed resources. -- Use debugging compilers. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Dreamhost dumps Debian
On Mon, 2013-08-19 at 23:48 -0400, Michael Gilbert wrote: [...] Plus, Ben Hutchings is putting together a plan to add support for newer hardware in stable releases: http://lists.debian.org/debian-boot/2013/08/msg00090.html Presumably, continuing to support newer hardware will improve the useful lifetime of releases. That's just what we need now to support new hardware for the current 2 years after release (or rather 2.5 years after freeze). I had no intention of enabling a longer release cycle; that just makes our job harder. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: Dreamhost dumps Debian
On Mon, Aug 19, 2013 at 10:50 PM, Russ Allbery wrote: ...change anything about their model. However, as a Debian Developer, I would be extremely uncomfortable about having tiers of security support for our packages were we to try to duplicate something like LTS. We are already no longer supporting iceweasel in squeeze: http://www.debian.org/security/2013/dsa-2735 At one point we stopped supporting clamav in oldstable: http://www.debian.org/security/2008/dsa-1497 At one point there was an experiment to express the lack of security support for specific packages using debtags. This seems to have been dropped but you can see that sql-ledger and kfreebsd weren't supported at one point: http://debtags.alioth.debian.org/tagindex/secteam.html https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436161 -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6ECtg-3tOaBa4bZujtwJpXAuth2ui1_25PnmQJ0=7j...@mail.gmail.com
Re: Dreamhost dumps Debian
On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote: Russ already replied and I agree with its reply. Just to say that Debian usually has a 3 year support. This is the kind of misguiding that I usually hear when people promotes Ubuntu over Debian. I know already that this isn't a popular idea, but another option would be to release less often. If releases were every 3 years, then the support window would be 4 years, which almost gets to the apparent sweet spot of 5. I think the more useful option would be for Debian to figure out how to lengthen its security support window instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Dreamhost dumps Debian
There are also a number of packages that have no support or limited support in squeeze/wheezy: http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=markup -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6GJYae5f=9ej-=8ytwqeuu2s91spujrd66g6iw7mdr...@mail.gmail.com
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 12:46 PM, Steve Langasek vor...@debian.org wrote: On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote: Russ already replied and I agree with its reply. Just to say that Debian usually has a 3 year support. This is the kind of misguiding that I usually hear when people promotes Ubuntu over Debian. I know already that this isn't a popular idea, but another option would be to release less often. If releases were every 3 years, then the support window would be 4 years, which almost gets to the apparent sweet spot of 5. I think the more useful option would be for Debian to figure out how to lengthen its security support window instead. Agreed. I know many companies that see Ubuntu's non-LTS releases as release candidates with real-world testing and LTS's as stable releases. That's why Ubuntu is successful: when a company picks an LTS, they perceive it as something that has been properly stabilized (although often times it's not true, e. g. Mir in the next LTS). Maybe we should adopt a similar model: - Stable release every 12-18 months to avoid shipping rotten software - Alternate releases are LTS - LTS releases get 4-5 years support (to determine) - Non-LTS releases get 6 months support after the release of the next LTS version - LTS overlap in support for at least 1 year to give users ample time to move to the next LTS E. g: - In January 2014 we release Debian 8.0. We make this an LTS release, meaning it would get updates for, say 3 years (until January 2017), and security updates for 5 years (until January 2019). - In February 2015 we release Debian 9.0. Non-LTS release. It will get at least 1 year of support (because we won't release the next version until at least 1 year later) + 6 months - In April 2016 we release Debian 10.0. LTS release. It will get again 3 years of updates and 5 years of security updates. This means support for Debian 9.0 will end in October 2016 (LTS release date + 6 months) - ... /ideastorm -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
Paul Wise p...@debian.org wrote: ... At one point we stopped supporting clamav in oldstable: http://www.debian.org/security/2008/dsa-1497 ... That, at least, is unlikely to be repeated. Upstream does a much better job of maintaining a consistent API and ABI compatibility these days. Scott K -- 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/7a8f320e-9d15-4707-aec7-b27cef978...@email.android.com
Re: Dreamhost dumps Debian
Charles Plessy writes (Re: Dreamhost dumps Debian): However, one difficulty that was not mentionned in this thread is that if we aim at both long term support and frequent releases, then we need to support users skipping releases or upgrading multiple releases in a row. I have done skip upgrades on multiple occasions. The fallout was always manageable. (The most recent one was etch-squeeze IIRC.) 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/21011.32310.864168.568...@chiark.greenend.org.uk
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 03:33:26PM +0100, Ian Jackson wrote: Charles Plessy writes (Re: Dreamhost dumps Debian): However, one difficulty that was not mentionned in this thread is that if we aim at both long term support and frequent releases, then we need to support users skipping releases or upgrading multiple releases in a row. I have done skip upgrades on multiple occasions. The fallout was always manageable. (The most recent one was etch-squeeze IIRC.) Why wouldn't you instead: sed -i s/etch/lenny/ /etc/apt/sources.list apt-get dist-upgrade sed -i s/lenny/squeeze/ /etc/apt/sources.list apt-get dist-upgrade This costs some machine time, yeah, but to solve that fallout costs human time which is in most cases far more expensive. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20130820145339.ga2...@angband.pl
Re: Dreamhost dumps Debian
Adam Borowski writes (Re: Dreamhost dumps Debian): On Tue, Aug 20, 2013 at 03:33:26PM +0100, Ian Jackson wrote: I have done skip upgrades on multiple occasions. The fallout was always manageable. (The most recent one was etch-squeeze IIRC.) Why wouldn't you instead: sed -i s/etch/lenny/ /etc/apt/sources.list apt-get dist-upgrade sed -i s/lenny/squeeze/ /etc/apt/sources.list apt-get dist-upgrade This costs some machine time, yeah, but to solve that fallout costs human time which is in most cases far more expensive. Well, what I mean is that the fallout could be fixed by fixing upgrade bugs in the packaging. Most of the core packages already have the right metadata and upgrade support. That the fallout is manageable shows (I think) that this isn't an unreasonable thing for Debian to do - we're already nearly there. The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? 2. How are we going to deal with drivers for new hardware - upgrade the kernel to LTS+1's ? 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/21011.34255.48484.270...@chiark.greenend.org.uk
Re: Dreamhost dumps Debian
Excerpts from Pau Garcia i Quiles's message of 2013-08-20 04:15:12 -0700: On Tue, Aug 20, 2013 at 12:46 PM, Steve Langasek vor...@debian.org wrote: On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote: Russ already replied and I agree with its reply. Just to say that Debian usually has a 3 year support. This is the kind of misguiding that I usually hear when people promotes Ubuntu over Debian. I know already that this isn't a popular idea, but another option would be to release less often. If releases were every 3 years, then the support window would be 4 years, which almost gets to the apparent sweet spot of 5. I think the more useful option would be for Debian to figure out how to lengthen its security support window instead. Agreed. I know many companies that see Ubuntu's non-LTS releases as release candidates with real-world testing and LTS's as stable releases. That's why Ubuntu is successful: when a company picks an LTS, they perceive it as something that has been properly stabilized (although often times it's not true, e. g. Mir in the next LTS). I think the term used there, properly stabilized, implies there is a definite process that one can use to stabilize an operating system and all of its integrated software. I think it is reasonable for a company to expect that Ubuntu would be more conservative with the LTS release, as it is in Ubuntu's best interest given the cost of supporting a radical release for 5 years. Debian is expected to be conservative as well. For a long time, with stable being alive for much longer than 2 years, I think users didn't have to make the kind of choice Dreamhost did. The release was an uncommon event that would kick off a year of decisions. However, with squeeze and wheezy coming so close together, I'm certain that the Dreamhost engineers were still weary from the squeeze transition when they were asked to evaluate wheezy. Maybe we should adopt a similar model: - Stable release every 12-18 months to avoid shipping rotten software - Alternate releases are LTS - LTS releases get 4-5 years support (to determine) - Non-LTS releases get 6 months support after the release of the next LTS version - LTS overlap in support for at least 1 year to give users ample time to move to the next LTS E. g: - In January 2014 we release Debian 8.0. We make this an LTS release, meaning it would get updates for, say 3 years (until January 2017), and security updates for 5 years (until January 2019). - In February 2015 we release Debian 9.0. Non-LTS release. It will get at least 1 year of support (because we won't release the next version until at least 1 year later) + 6 months - In April 2016 we release Debian 10.0. LTS release. It will get again 3 years of updates and 5 years of security updates. This means support for Debian 9.0 will end in October 2016 (LTS release date + 6 months) - ... /ideastorm All great ideas. I'm more inclined to just suggest that Debian keep oldstable security patched for an extra year. That is easy for users and developers to remember, and would give big server users a chance to slow down the treadmill a little. Of course, it also would put more burden on DD's. -- 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/1377011275-sup-1...@fewbar.com
Re: Dreamhost dumps Debian
The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? The same people that maintain the packages in sid and stable: the maintainer(s) for each package. For orphaned packages, NMUs by other developers or even a new maintainer team (foster-car...@debian.org). Providing fixes, security or not, is our part of our duty as Debian developers. Sure, packaging new upstream versions is always more exciting than fixing a broken version/package but it needs to be done. 2. How are we going to deal with drivers for new hardware - upgrade the kernel to LTS+1's ? AFAIK Ubuntu does not add drivers for new hardware to any version save for, maybe, some exceptional cases (that I cannot remember, frankly). Quite the opposite: it's the hardware manufacturers themselves who are compelled to provide drivers for RHEL, SLES and Ubuntu LTS due to customers asking. That's why there is an option to load drivers from disk at the very beginning of installation (isolinux prompt) on RHEL, SLES and Ubuntu. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
Pau Garcia i Quiles writes (Re: Dreamhost dumps Debian): [Ian Jackson] The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? The same people that maintain the packages in sid and stable: the maintainer(s) for each package. [...] That is not the case. At the moment most of this is done by the Debian security team. Of course some package maintainers do help. For orphaned packages, NMUs by other developers or even a new maintainer team (foster-car...@debian.org). Providing fixes, security or not, is our part of our duty as Debian developers. Sure, packaging new upstream versions is always more exciting than fixing a broken version/package but it needs to be done. You seem to be saying this is an important thing to do - will you all please go and do it. That's not how things work. In summary, unless and until we have people who volunteer to do the security support for an LTS, we won't have an LTS. 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/21011.39023.898706.120...@chiark.greenend.org.uk
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 6:25 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? The same people that maintain the packages in sid and stable: the maintainer(s) for each package. [...] That is not the case. At the moment most of this is done by the Debian security team. Of course some package maintainers do help. IMHO that should be turned around: package maintainers should be the ones responsible for updates and the Security Team should help with that (e. g. by providing tips and/or reviewing the fixes) For orphaned packages, NMUs by other developers or even a new maintainer team (foster-car...@debian.org). Providing fixes, security or not, is our part of our duty as Debian developers. Sure, packaging new upstream versions is always more exciting than fixing a broken version/package but it needs to be done. You seem to be saying this is an important thing to do - will you all please go and do it. Exactly. That's what I do for my packages (in fact I backport newer versions of some of my packages to every Debian and Ubuntu which is still supported). That's not how things work. In summary, unless and until we have people who volunteer to do the security support for an LTS, we won't have an LTS. Maybe I'm wrong but I fail to see why security support for LTS should be a different team than security support for stable. To me, it should be the same team, and maintainers and packages should be #1 in the list of people to work on fixes, as I said above. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
Paul Wise p...@debian.org writes: We are already no longer supporting iceweasel in squeeze: http://www.debian.org/security/2013/dsa-2735 At one point we stopped supporting clamav in oldstable: http://www.debian.org/security/2008/dsa-1497 At one point there was an experiment to express the lack of security support for specific packages using debtags. This seems to have been dropped but you can see that sql-ledger and kfreebsd weren't supported at one point: http://debtags.alioth.debian.org/tagindex/secteam.html https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436161 Yeah, I know. But the number of such exceptions is relatively limited, enough so that we can issue security advisories saying they're not supported any more. It's not a comfortable compromise, but it seems to be a workable one. The LTS security policy is quite a bit broader in its implications. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/878uzws2nq@windlord.stanford.edu
Re: Dreamhost dumps Debian
Quoting Pau Garcia i Quiles (pgqui...@elpauer.org): That is not the case. At the moment most of this is done by the Debian security team. Of course some package maintainers do help. IMHO that should be turned around: package maintainers should be the ones responsible for updates and the Security Team should help with that (e. g. by providing tips and/or reviewing the fixes) I'm afraid you probably think that all packages are better maintained than they really are The Security Team is indeed very opened to package maintainers doing most of the update work.when there is really someone maintaining the package and not a ghost. signature.asc Description: Digital signature
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 06:35:08PM +0200, Pau Garcia i Quiles wrote: On Tue, Aug 20, 2013 at 6:25 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? The same people that maintain the packages in sid and stable: the maintainer(s) for each package. [...] That is not the case. At the moment most of this is done by the Debian security team. Of course some package maintainers do help. IMHO that should be turned around: package maintainers should be the ones responsible for updates and the Security Team should help with that (e. g. by providing tips and/or reviewing the fixes) That's not the understanding that was in place when I joined Debian. Certainly there seems to be a move by the security team to push more and more responsibility onto the package maintainers lately; I understand the motivation (like everyone else they have more to do than they have time to do it in), but I think the outcome, whereby the security team denies use of the security update channel for non-critical security bugs and redirects maintainers to stable-updates instead, is unfortunate. As far as I'm concerned, a security fix that isn't worth being pushed to security.debian.org is also not worth me spending time on as a maintainer to push to stable-updates. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Dreamhost dumps Debian
Ian Jackson ijack...@chiark.greenend.org.uk writes: Pau Garcia i Quiles writes (Re: Dreamhost dumps Debian): The same people that maintain the packages in sid and stable: the maintainer(s) for each package. [...] That is not the case. At the moment most of this is done by the Debian security team. Of course some package maintainers do help. I consider it part of my responsibility as a package maintainer to provide security support for my packages for as long as Debian does. If I felt like I couldn't do that, I would orphan the package or look at having it removed from Debian. I don't think there's any way that one team can scale to providing security support for the entire archive; it's hard for them to even track the existence of issues for the entire archive. But even apart from manpower, I think there are some real challenges to providing security support for any longer than we do, to the degree that I feel like the security support that Ubuntu and Red Hat claim to provide is partly illusory. My experience is that I can just barely manage to convince upstreams to look over my backports of security patches to packages in oldstable; another two years would be so far out of upstream's willingness to even consider the package that Debian would be entirely on its own for quite a lot of packages. Frequently, the version in oldstable is already past upstream's official end of life announcement. And it's rare to see much involvement of Red Hat or Ubuntu security folks in those conversations. I don't want to be unfair to Red Hat's and Ubuntu's security teams, who do a lot of hard and excellent work, and I realize that both have paid employees doing this and therefore more resources available. But even given that, I suspect that, towards the end of that five year cycle, the number of security fixes that are actually backported is fairly limited, and quite a lot of triage is being done, even beyond the core versus universe distinctions. They'd be working without any assistance from the upstream maintainers in many cases. Two year upgrade cycles are uncomfortable for a lot of production IT organizations, including the one I work for. But even if Debian claimed to support software for longer, I personally would be quite leery about relying on that given my experience with talking to upstream projects about security vulnerabilities. I'm painfully aware of the steep cliff dropoff of upstream support for security fixes once you go beyond two years after the release of the software. Beyond that point, even if you do get security fixes, you're probably getting fixes that have been backported by people with only a vague knowledge of the code, fixes that often have not been thoroughly tested or tested by someone who uses the software in question and that upstream has never looked at and will disclaim any knowledge of or support for. As painful as it is, if you are worried about security in a production environment, falling more than a couple of years behind current distribution releases is probably not in your best interests no matter what security support you supposedly have. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87txikqkxf@windlord.stanford.edu
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery r...@debian.org wrote: The same people that maintain the packages in sid and stable: the maintainer(s) for each package. [...] That is not the case. At the moment most of this is done by the Debian security team. Of course some package maintainers do help. I consider it part of my responsibility as a package maintainer to provide security support for my packages for as long as Debian does. If I felt like I couldn't do that, I would orphan the package or look at having it removed from Debian. I don't think there's any way that one team can scale to providing security support for the entire archive; it's hard for them to even track the existence of issues for the entire archive. That's exactly how I see it, glad to see I'm not alone :-) My experience is that I can just barely manage to convince upstreams to look over my backports of security patches to packages in oldstable What makes you think Ubuntu, Red Hat, etc ask upstream to look at their security patches for old versions or even approve them? When I backport something, I send it to upstream as a courtesy, in case they want to release a patch version, not because I expect them to give me the OK -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Tue, August 20, 2013 19:40, Steve Langasek wrote: On Tue, Aug 20, 2013 at 06:35:08PM +0200, Pau Garcia i Quiles wrote: IMHO that should be turned around: package maintainers should be the ones responsible for updates and the Security Team should help with that (e.g. by providing tips and/or reviewing the fixes) That's not the understanding that was in place when I joined Debian. Certainly there seems to be a move by the security team to push more and more responsibility onto the package maintainers lately; I understand the motivation (like everyone else they have more to do than they have time to do it in), Division of labour is very important to sustain the security support for the full breadth of the archive, but an important part of the shift in responsibility is that the package maintainers are in better contact with upstream and much more used to the intricacies of the software and its packaging, and on top are probably in a well suited position to test the changes. Having the maintainers involved in creating updated packages is therefore a much more preferable MO than the security team preparing the updates on their own. but I think the outcome, whereby the security team denies use of the security update channel for non-critical security bugs and redirects maintainers to stable-updates instead, is unfortunate. As far as I'm concerned, a security fix that isn't worth being pushed to security.debian.org is also not worth me spending time on as a maintainer to push to stable-updates. And that is a very fair position. Everything that smells like security regardless of impact and seriousness gets a CVE id and is called a security issue. The security team triages issues and decides what is not critical enough for a DSA. Perhaps a good way to see those issues as bugs of severity up to important: where it's arguable that may improve Debian by putting it into a spu, but can equally well be argued that there are better ways to spend your time. 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/0327d20c814d27da6a3e0b5fbc9e0658.squir...@aphrodite.kinkhorst.nl
Re: Dreamhost dumps Debian
On 08/20/2013 02:04 AM, Charles Plessy wrote: However, one difficulty that was not mentionned in this thread is that if we aim at both long term support and frequent releases, then we need to support users skipping releases I don't see why. or upgrading multiple releases in a row. Don't we support that already? Thomas -- 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/5213c10f.4070...@debian.org
Re: Dreamhost dumps Debian
Pau Garcia i Quiles pgqui...@elpauer.org writes: On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery r...@debian.org wrote: My experience is that I can just barely manage to convince upstreams to look over my backports of security patches to packages in oldstable What makes you think Ubuntu, Red Hat, etc ask upstream to look at their security patches for old versions or even approve them? When I backport something, I send it to upstream as a courtesy, in case they want to release a patch version, not because I expect them to give me the OK Well, I suppose they might not, but I would find that even more disturbing. It's very easy to not actually fix the problem or to add new security holes in the process of fixing another problem, and the few times when I've had to fix security holes without any upstream review, it's made me very nervous. I'd really like security fixes to be vetted by people who are experts in that code base. Now, if the distribution packagers are experts, that's great; at that point, I consider them as something akin to part of upstream. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874nakqifh@windlord.stanford.edu
Re: Dreamhost dumps Debian
On 08/20/2013 05:05 PM, Ian Jackson wrote: The bigger problem for a Debian LTS is this: 1. who is going to do security support for it ? My answer is: anyone who cares (and *not* necessarily the package maintainer) in a free-for-all way, with peer review if possible (not necessarily by the security team if they are already busy), for the packages we care about (example: bind9 ...). Also, this could be done by backporting old-stable packages to very-old-stable in a few cases, if we can't (because of lack of time?) do otherwise. That would still be better, IMO, than just dropping security support. Let's try and see if that works when Squeeze is EOL... 2. How are we going to deal with drivers for new hardware - upgrade the kernel to LTS+1's ? IMO, that's not the problem. What maters is maintaining existing setups, not allowing people to use very-old-stable with new hardware. Thomas -- 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/5213c685.8030...@debian.org
