Re: Proposed change to debian release system
Hi, I think a problem is the difference between stable software and stable distro... i.e.: perl 5.8 is the stable release of perl, but it isn't into the stable distro, because managing a distro to be stable requires packages not to being upgraded... I think the idea of the Current release would be good if it is automatic, just like testing... but that would require maintainers to inform the upstream status (unstable/stable) of the software and a dynamic distro with all the software that is upstream-stable would fit... I don't know if this is too hard to do, but certainly It would be nice to people that doesn't like to have unstable software, but like having recent software... In this way, Current would be never released, but would have the most recent stable software (but it wouldn't be a stable distro after all). Em Sáb, 2003-12-13 às 19:41, Henning Makholm escreveu: Scripsit Arnaud Vandyck [EMAIL PROTECTED] Scott Minns [EMAIL PROTECTED] writes: Stable - released when the software is rock sold and very mature Current - This is software that has been in testing for six months and experienced no critical bugs, floors or dependency problems. A new version is released every six This is nearly impossible. I don't know if other developers will agree but IMHO, it's like having two `stable' releases! I concur. In particular, the process is already such that if we get even near something that fits this description of current, a big party will be thrown and that something will be frozen to become the next stable within a short timeframe. Everybody seems to agree that new stable versions *should* be out about every 6 months. The problem of getting testing into a freezeable state is not going to go away simply by calling the goal current instead of stable. -- Henning Makholm What has it got in its pocketses?
Re: Proposed change to debian release system
On Sun, 14 Dec 2003, Scott Minns wrote: Hiya all, Thanks for your replys, I like the idea of making some packages perishable the trouble is where would you draw the line? I could do with some of the new features in proftpd, but that would not be perishable so the problem is still there. The main problem is that software is moving on so damn fast atm. From my point of view one of the main issues is that new packages are never built for the stable release, so there are loads of packages in testing that I need or want to use, but they are not in stable - Perhaps an official debian subproject that attempts to provide some backports such that adding an additional line to sources.list would enable them to be available. Perhaps this is already the aim of the flavours idea that has been discussed?
Re: Proposed change to debian release system
On Sun, 14 Dec 2003 20:02:54 -0700, Joel Baker [EMAIL PROTECTED] wrote: Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much more invasive than a dist-upgrade, every six months. This has largely to do with the fact that most upgrades are very smooth, and don't require, say, a complete reinstall. Oddly enough, nobody at me ex-orkplace (having about 20 FreeBSD boxes in productive use) dared to touch any of the BSD boxes. We had productive Servers running FreeBSD 2.x, and I believe that this hasn't changed. In this regard, Debian actually resembles the *BSDs much more closely than most other Linux distributions (and that isn't a bad thing). NACK. Debian is much easier to upgrade since we keep older versions around. Updating older FreeBSD base systems should work fine, but compiling new ports is a nightmare if you can't step up one release at a time. The only thing you can safely do is to build new systems and slowly migrate. Debian is much better in that regard. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Proposed change to debian release system
On Sun, 14 Dec 2003 15:41:13 -0600, Chad Walstrom [EMAIL PROTECTED] wrote: I like the Debian is ready when it's ready argument. Two years between releases may be a bit long for my taste. A year would be nice, and six months is highly optimistic. Once debian-installer is polished, things should move quicker. After taking a look at the RC bug count, I don't see debian-installer holding up things at the moment. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
RE: Proposed change to debian release system
Sorry, you are correct. I apologize for the error. Lucas, not only did you horribly misquote my statement as coming from Scott, but you also seem to not having read my mail thoroughly. Nowhere did I suggest that installed packages stop working when expired, did I? Please re-read my suggestion.
Re: Proposed change to debian release system
* Andrew Pollock ([EMAIL PROTECTED]) wrote: On Sat, Dec 13, 2003 at 03:20:27PM +, Scott Minns wrote: Hiya all, First of all let me introduce myself, my name is Scott Minns, i'm a debian user, not a developer. That most likely makes you question why i'm using thins mailing list at all, let alone having the gall to propose altering a well established testing and release system. Here is my proposal and I would like to hear your thoughts on it, In addition to the present releases- stable, testing and unstable. We add a release called current. [snip] What you propose is probably technically difficult to actually achieve, due to dependencies, and would, as has already been pointed out, effectively mean there are two stable distributions running around. I've been musing over a proposal for a while, which your email makes me want to raise now... I'd like to propose some changes to the stable release policy (ps it would be nice if the policy is linked from http://www.debian.org/releases/stable/). I'd like for certain packages to be classed as perishable, i.e. they become more or less useless with age. How packages should be classsed as such, I'm not 100% sure on yet (-devel+maintainer+SRM consenus, perhaps?), but to provide some examples: * spamassassin * snort could be considered perishable because their effectiveness is reduced over time. Such classed packages should be allowed to be updated in stable, I feel. Of course, it could be argued that any package is perishable, and thus this whole thing becomes a moot point... We always have to be careful with things like that, since stable is *stable*... it should not really change, except to address critical issues. Not that I disagree with your proposal. I think that some value in updating these packages, and for packages such as spamassassin and snort the case could be made that updating them would be security updates, particularly in the case of snort. Also those two packages really contain rule sets that could be packaged separately and updated, while leaving the core code unchanged. That would probably be the least surprising thing, and the least likely to cause bugs, but would still be a lot of work and testing. Another package I think would be on the list might be gaim. If msn or yahoo changes their protocol then it becomes rather broken. This one would be very difficult to handle in most cases... new version could introduce new bugs, and backports could be really tough. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Proposed change to debian release system
On Mon, Dec 15, 2003 at 08:57:45AM +0100, Marc Haber wrote: On Sun, 14 Dec 2003 20:02:54 -0700, Joel Baker [EMAIL PROTECTED] wrote: Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much more invasive than a dist-upgrade, every six months. This has largely to do with the fact that most upgrades are very smooth, and don't require, say, a complete reinstall. Oddly enough, nobody at me ex-orkplace (having about 20 FreeBSD boxes in productive use) dared to touch any of the BSD boxes. We had productive Servers running FreeBSD 2.x, and I believe that this hasn't changed. This isn't my experience, or that of any of the other FreeBSD admins I (yes, know I do admin some FreeBSD boxes, for various reasons, even though n't my it ispreferred platform in any sense). In this regard, Debian actually resembles the *BSDs much more closely than most other Linux distributions (and that isn't a bad thing). NACK. Debian is much easier to upgrade since we keep older versions around. Updating older FreeBSD base systems should work fine, but compiling new ports is a nightmare if you can't step up one release at a time. The only thing you can safely do is to build new systems and slowly migrate. Debian is much better in that regard. Mmmm. I rarely have problems with such, but I suppose I also don't, as a rule, allow my systems to get terribly out of date. Though I have my doubts as to how 'safe' trying to upgrade from Debian 1.0 (which I don't recall the codename for, and I'm too lazy to go look it up) to Sarge would work well, even with release-by-release upgrades. Stipulated, it would be far more likely to work, because one can (at least, in theory) find the entirety of the old releases, rather than just the core. However, my point stands: most Linux releases - at least, those not based on Debian's core - *don't support upgrading over a major version change*. The BSDs do, and Debian does; thus, saying that Debian does so better puts it on the far side of the BSDs from, say, RedHat. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpCN0aWDtYW7.pgp Description: PGP signature
Re: Proposed change to debian release system
On Mon, Dec 15, 2003 at 08:55:03AM +0100, Marc Haber wrote: After taking a look at the RC bug count, I don't see debian-installer holding up things at the moment. Never the less, it has been one of those must do items, one of the milestones that needs to be reached before a release is even considered. RC bugs continue to accumulate as long as people feel they have time to fix them and as long as testing is unfrozen. When the release manager makes the announcement that a release is approaching, our attentions are diverted from our own personal projects and packages to those that have received less care. The announcement for release preparation is made, and the cry for help goes out. Hopefully it is heard. Organize some BSP's, people! They are sorely needed. We found out on Saturday's Minneapolis BSP that many of the RC bugs were quick fixes. The 0-day NMU is a blessing (personally, I think this should be a 365-day, full-time policy). Let's take advantage of it. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp0eyCRqtLk1.pgp Description: PGP signature
Re: Proposed change to debian release system
Eric Dorland [EMAIL PROTECTED] writes: * spamassassin * snort could be considered perishable because their effectiveness is reduced over time. Such classed packages should be allowed to be updated in stable, I feel. Of course, it could be argued that any package is perishable, and thus this whole thing becomes a moot point... We always have to be careful with things like that, since stable is *stable*... it should not really change, except to address critical issues. Not that I disagree with your proposal. I think that some value in updating these packages, and for packages such as spamassassin and snort the case could be made that updating them would be security updates, particularly in the case of snort. Also those two packages really contain rule sets that could be packaged separately and updated, while leaving the core code unchanged. That would probably be the least surprising thing, and the least likely to cause bugs, but would still be a lot of work and testing. Perhaps the rule-sets could be handled outside of the debian package system, like clamav does (clamav runs a daemon that fetches new rulesets as they become availle on the Net). Andy -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Packages should build-depend on what they should build-depend.
Re: Proposed change to debian release system
Hiya all, Thanks for your replys, I like the idea of making some packages perishable the trouble is where would you draw the line? I could do with some of the new features in proftpd, but that would not be perishable so the problem is still there. The main problem is that software is moving on so damn fast atm. From my point of view one of the main issues is that new packages are never built for the stable release, so there are loads of packages in testing that I need or want to use, but they are not in stable - probably for good reason. However all its doing is forcing be to end up maintaining 2 different platforms one for newer or more up to date packages, and one for my must be stable servers. However the time will come when I need features even on my stable server that debian can not provide and I will be forced to switch. The administrative load of mixing package from different releases and keeping track of it to ensure you dont break anything simply gets to high after you reach 400-500 hundred servers! Now I have to say, all that does is tempt me to switch all my servers over to say bsd, as its not a lot harder to maintain, but it means I can once again have only one system to admin rather than two. Obviously this isnt what I want to do, or I would not have mailed this list in the first place! However there are economic factors at play which means that my boss will force me to run a distro that can handle the latest/newer packages and run in a stable state Best Regards Scott
RE: Proposed change to debian release system
Scott Minns wrote: Thanks for your replys, I like the idea of making some packages perishable the trouble is where would you draw the line? We could add an optional control field Expires: $date to packages, so package maintainers could decide for themselves. After a package has expired, it would only be installed with a warning or even with the admin explicitly confirming he wants to install it anyway. I know this is no panacea, since in many cases, the maintainer cannot know whether a package will perish at all (like when all spammers promptly give up advancing their software, so a given version of spamassassin would stay useful forever)... ;-)
Re: Proposed change to debian release system
On Sat, Dec 13, 2003 at 10:41:22PM +, Henning Makholm wrote: Everybody seems to agree that new stable versions *should* be out about every 6 months. I don't think that is true. I think developers (and users) have a wide range of opinions as to how often there should be a new Debian release. -- gram signature.asc Description: Digital signature
RE: Proposed change to debian release system
My friend has a high volume mail server running spamassassin 2.31 Oops the spamassassin stopped working. Now I have 12,000 people angry with me. Take that to the bank. --luke Scott Minns wrote: I know this is no panacea, since in many cases, the maintainer cannot know whether a package will perish at all (like when all spammers promptly give up advancing their software, so a given version of spamassassin would stay useful forever)... ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed change to debian release system
On Sun, Dec 14, 2003 at 03:29:10PM -0600, Graham Wilson wrote: I don't think that is true. I think developers (and users) have a wide range of opinions as to how often there should be a new Debian release. I like the Debian is ready when it's ready argument. Two years between releases may be a bit long for my taste. A year would be nice, and six months is highly optimistic. Once debian-installer is polished, things should move quicker. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpwRp5O6SbzO.pgp Description: PGP signature
Re: Proposed change to debian release system
Henning Makholm [EMAIL PROTECTED] wrote: [...] Everybody seems to agree that new stable versions *should* be out about every 6 months. [...] No. cu andreas
RE: Proposed change to debian release system
Lucas Albers wrote: Julian Mehnle wrote: I know this is no panacea, since in many cases, the maintainer cannot know whether a package will perish at all (like when all spammers promptly give up advancing their software, so a given version of spamassassin would stay useful forever)... ;-) My friend has a high volume mail server running spamassassin 2.31 Oops the spamassassin stopped working. Now I have 12,000 people angry with me. Take that to the bank. Lucas, not only did you horribly misquote my statement as coming from Scott, but you also seem to not having read my mail thoroughly. Nowhere did I suggest that installed packages stop working when expired, did I? Please re-read my suggestion.
Re: Proposed change to debian release system
Scripsit Andreas Metzler [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: Everybody seems to agree that new stable versions *should* be out about every 6 months. No. I stand corrected, apparently. (But I have yet to imagine which arguments would be used against doing a release if we happen to find testing in a freezeable state 6 months after sarge releases). -- Henning Makholm Jeg forstår mig på at anvende sådanne midler på folks legemer, at jeg kan varme eller afkøle dem, som jeg vil, og få dem til at kaste op, hvis det er det, jeg vil, eller give afføring og meget andet af den slags.
Re: Proposed change to debian release system
On Mon, Dec 15, 2003 at 10:49:20AM +0800, Isaac To wrote: Henning == Henning Makholm [EMAIL PROTECTED] writes: Henning I stand corrected, apparently. (But I have yet to imagine which Henning arguments would be used against doing a release if we happen to Henning find testing in a freezeable state 6 months after sarge Henning releases). Perhaps because you'd be either forcing busy sys-admins to dist-upgrade every 6 months, or forcing maintainers to keep security updates for two stable versions? Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much more invasive than a dist-upgrade, every six months. This has largely to do with the fact that most upgrades are very smooth, and don't require, say, a complete reinstall. In this regard, Debian actually resembles the *BSDs much more closely than most other Linux distributions (and that isn't a bad thing). Oh, and as for security? They're already supporting 'oldstable' for, oh... about 6 months, or more. So tell me again why this is supposed to be a bad idea? (One that may take some practice to achieve, sure, and not one I expect us to hit next release, though I'd be happy to get it below the steadily expanding history of Debian - and the current RM's goals appear to be a strong step in that direction). -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpPjs5928mzD.pgp Description: PGP signature
Re: Proposed change to debian release system
Henning == Henning Makholm [EMAIL PROTECTED] writes: Henning I stand corrected, apparently. (But I have yet to imagine which Henning arguments would be used against doing a release if we happen to Henning find testing in a freezeable state 6 months after sarge Henning releases). Perhaps because you'd be either forcing busy sys-admins to dist-upgrade every 6 months, or forcing maintainers to keep security updates for two stable versions? Regards, Isaac.
Proposed change to debian release system
Hiya all, First of all let me introduce myself, my name is Scott Minns, i'm a debian user, not a developer. That most likely makes you question why i'm using thins mailing list at all, let alone having the gall to propose altering a well established testing and release system. Here is my proposal and I would like to hear your thoughts on it, In addition to the present releases- stable, testing and unstable. We add a release called current. For my general servers stable is too old and lacks features and software that I need, I hate using back ports or software from other releases, it seems to always eventually cause problems. Yet for my web servers stable is perfect, its rock solid :) However I would not trust testing or unstable on a production server. My suggestion would be this Stable - released when the software is rock sold and very mature Current - This is software that has been in testing for six months and experienced no critical bugs, floors or dependency problems. A new version is released every six months - supported by a security team. After 1 year the current version becomes stable. Testing - Software in the queue to enter current otherwise as it is at present Unstable - new software, no testing for those that like to live dangerously - as it is at present My reason for suggesting this change is that I love using debian, but Im currently having to evaluate other distros and OS's such as slack and FreeBSD to get the features, stability and security that we need. I will be interested to hear you feedback and thought on the matter. Best regards Scott
Re: Proposed change to debian release system
Scott Minns [EMAIL PROTECTED] writes: [...] Stable - released when the software is rock sold and very mature Current - This is software that has been in testing for six months and experienced no critical bugs, floors or dependency problems. A new version is released every six This is nearly impossible. I don't know if other developers will agree but IMHO, it's like having two `stable' releases! months - supported by a security team. After 1 year the current version becomes stable. I don't think we have enough developers to follow security problems in stable, current and months! Testing - Software in the queue to enter current otherwise as it is at present Testing should be more stable and should have less RC bugs then it is at the moment. But this discussion has already take place here and on debian-release. Maybe search the archive and you'll see some other proposals. Unstable - new software, no testing for those that like to live dangerously - as it is at present Also, you must be aware that there is `experimental' and this is the pool to promote. This pool is intended for packages to `tests' and packages in this pool does not go automatically in unstable. This is an important point. The bad thing with this pool is that packages in main are not autobuild on different arches (IMHO). I think promote experimental with buildd would really be benefic to the project. My reason for suggesting this change is that I love using debian, but Im currently having to evaluate other distros and OS's such as slack and FreeBSD to get the features, stability and security that we need. Slackware?! Well, of course FreeBSD is great (even if I've never use it), I can tell you the Debian community and distribution is really great ;)... and surely the best choice ;) I will be interested to hear you feedback and thought on the matter. I'm not a senior network administrator but I'm really pleased with Debian (even with mixed pools!.. yes, not a good idea!). Best regards, -- .''`. Arnaud Vandyck : :' : http://people.debian.org/~avdyk/ `. `' `-
Re: Proposed change to debian release system
On Sat, Dec 13, 2003 at 03:20:27PM +, Scott Minns wrote: Hiya all, First of all let me introduce myself, my name is Scott Minns, i'm a debian user, not a developer. That most likely makes you question why i'm using thins mailing list at all, let alone having the gall to propose altering a well established testing and release system. Here is my proposal and I would like to hear your thoughts on it, In addition to the present releases- stable, testing and unstable. We add a release called current. [snip] What you propose is probably technically difficult to actually achieve, due to dependencies, and would, as has already been pointed out, effectively mean there are two stable distributions running around. I've been musing over a proposal for a while, which your email makes me want to raise now... I'd like to propose some changes to the stable release policy (ps it would be nice if the policy is linked from http://www.debian.org/releases/stable/). I'd like for certain packages to be classed as perishable, i.e. they become more or less useless with age. How packages should be classsed as such, I'm not 100% sure on yet (-devel+maintainer+SRM consenus, perhaps?), but to provide some examples: * spamassassin * snort could be considered perishable because their effectiveness is reduced over time. Such classed packages should be allowed to be updated in stable, I feel. Of course, it could be argued that any package is perishable, and thus this whole thing becomes a moot point... The exact policy on what and how they can be updated needs to be debated, and of course the whole thing would need the Stable Release Manager's blessing. It also makes for more work for both the Stable Release Manager and the Security Team though, as there would be multiple versions of a package that could potentially require a security update. This makes the proposal unattractive, but coming back to the Social Contract, our first priority should be to our users, so if an 18 month old stable distribution is not serving our users needs adequately, and we can't (in the short term) shorten our release cycle, then perhaps this is a middle ground that can be explored further... This proposal is a tad premature in that I hadn't thought it through in as much depth as I'd have liked to have before floating it, but I felt the original email was a good catalyst for getting it out there... Andrew
Re: Proposed change to debian release system
Scripsit Arnaud Vandyck [EMAIL PROTECTED] Scott Minns [EMAIL PROTECTED] writes: Stable - released when the software is rock sold and very mature Current - This is software that has been in testing for six months and experienced no critical bugs, floors or dependency problems. A new version is released every six This is nearly impossible. I don't know if other developers will agree but IMHO, it's like having two `stable' releases! I concur. In particular, the process is already such that if we get even near something that fits this description of current, a big party will be thrown and that something will be frozen to become the next stable within a short timeframe. Everybody seems to agree that new stable versions *should* be out about every 6 months. The problem of getting testing into a freezeable state is not going to go away simply by calling the goal current instead of stable. -- Henning Makholm What has it got in its pocketses?
