Re: New stable version after Sarge
Jose Carlos Garcia Sogo wrote: Which will mean that people will skip at least one distribution if we released each 6 months, even two. That would put the burden on us of needing to have security support for even 2 more distributions older than current stable, which could not be possible. ACK to this (and most other things you wrote). Most software projects and distributions - commercial and OSS/GPL - typically have only 2-3 versions under active development or maintainance. More is not possible. That's why I think that a 18 months release is the best compromise between server and desktop users. This can be too long for both - servers and desktop. On servers it is IMHO a less important problem, as mostly only a few packages with newest features are needed. Other option could be make a splitted release. For example, release base+server each 18 months and make a debian-desktop release each 6, but this has also other side effects and implications which are not easily handled. This would mean, that the 3 archives (stable, testing, unstable) move to 4 archives. Instead of an extra desktop release I would like an idea like this: - unstable - testing - pre-stable - stable For unstable the role is the same: a kind of sanity check, and a package moves to testing after 10-20 days, if no critical or important bugs known. For the move from testing to pre-stable different rules can apply. E.g. for new major (=redesign) releases of server/essential/important packages the minimum testing time should be 3 months (or more - to be defined). Typical examples are Apache 1.x -> 2.x, kernel 2.4 -> 2.6, DRBD 0.6 -> 0.7, or the upcoming release of heartbeat 2.0. Desktop or utilty packages, where a crash would be less important, can have softer quality rules. E.g. I always experienced crashes with Netscape/Mozilla/Thunderbird, independant if they where included in stable, testing or whatelse - who cares. Pre-stable would be nearly the same, what Sarge now _temporarly_ is - the place for preparation of a stable release. To avoid the split into 4 archives, the only alternative seems IMHO stronger rules for the move from unstable to testing. The rules could be like these rules, which apply for Sarge now in pre-release state. - A well known date for the freeze. About a year from Sarge release if we want to release in 18 months. ACK. The installer should be ready when the freeze, having some months then to check and polish. [...] - "Release essential" packages should be kept mostly free of RC bugs. [...] - For other packages, discourage maintainers to make hughe changes if not needed, but evolve them. [...] Of course I know that all we are voluteers, and that it is a bit difficult to enforce a calendar as if we were a corporation, Major releases (=redesigns) of complex software need a minimum of time to develop (~1 year), test and polish (~6 months and more). Knowing both cultures there is IMHO no essential difference between volunteers and corporations in the minimum time to reach stable quality. Helmut Wollmersdorfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
Jose Carlos Garcia Sogo schreef: El jue, 06-01-2005 a las 13:43 -0800, Will Lowe escribiÃ: Is that really true? I would love to run "apt-get dist-upgrade" every half a year. Currently it doesn't get me much. :) Now, for production systems, don't you do some testing *before* you upgrade the OS? Sure I do. But I run a production environment with several hundred machines in it. We package our in-house software in .deb format to make rollouts easy. I don't look forward to regressing all of that software, and it's packaging, every six months on a new OS release. It's hard to do that even every 18 months. Which will mean that people will skip at least one distribution if we released each 6 months, even two. That would put the burden on us of needing to have security support for even 2 more distributions older than current stable, which could not be possible. That's why I think that a 18 months release is the best compromise between server and desktop users. Other option could be make a splitted release. For example, release base+server each 18 months and make a debian-desktop release each 6, but this has also other side effects and implications which are not easily handled. IMHO we should focus on these points: - Having a clear roadmap for stuff we want to include or change before releasing etch. This roadmap should include things that are possible to be made in about one year from the release of sarge. Release managers should agree with that at make it "official". I think when you start a new version, we must make some agreements. Like "everything must be conform LSB 2.0". I am not sure we need a complete roadmap. - A well known date for the freeze. About a year from Sarge release if we want to release in 18 months. I would say: a well known date for the freeze, and after that the release as fast as possible (= no date). - A working installer. Now we have one in very good shape. People working on it should also draw a roadmap of the functions they want to add in that period of time. The installer should be ready when the freeze, having some months then to check and polish. I think the installer could be a "normal package". We use the latest release. I think also there could be more then one installer. - Keep infraestructure working. What do we need to fix or to improve? What do we want to change? What do we need when we want to freeze etch? Waiting for security "to be ready" is a bit discouraging. I normally work in testing, and that seems to work OK most of the time. I don't see a big problem to declare testing as "frozen", to remove the latest problems, and then call it "stable". But maybe I see it to easy... With regards, Paul van der Vlis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
On 10-Jan-05, 16:47 (CST), Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > On the other hand -- we need to decide whether we want time-based > releases. Other projects have had great successes with them, but they > might not be right for Debian. Of course, those other projects don't have worry about 15 *other* project release schedules. Which is just to say that if we did do something like "Freeze May 1, Release July 31" (to pick dates completely out of the air), there's bound to be some projects that release major upgrades on June 1, and who will miss the boat for that year's Debian. If we're not willing to be completely hard-ass about that kind of situation, then there's no point in even attempting to go down that road. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
Patrzę w ekran, a to William Ballard pisze do mnie: > .1 Releases aren't for adding functionality which was created after > the .0 release. It's for finishing the stuff you postponed doing > so you could ship. So why is the Sarge to be 3.1? I think that it differs so much from Woody (take only the installer) that it would make much more sense to call it already 4.0. Maciej -- M.Sc. Maciej Dems [EMAIL PROTECTED] - C o m p u t e r P h y s i c s L a b o r a t o r y Institute of Physics,Technical University of Lodz ul. Wolczanska 219, 93-005 Lodz, Poland, +48426313649
Re: New stable version after Sarge
* "Marcelo E. Magallon" | Are you thinking of say, the installer? I certainly *hope* that the | installer is going to stay in the current status for at least another | release! Another "whoos, let us restart from scratch" won't be | welcome by anyone. And my hope is based on the fact that the new | installer is *good* (instead of just adequate, like b-f). | | Or is it the next big thing going on with the archive? | | We don't have to go from X.0 to (X+1).0 in 6 months. It's perfectly ok | to go from X.0 to X.1. Since you're mentioning X: we might want to move to X.org after sarge. That'll probably take a little time to work itself out. We'll lose apache 1.3 and switch to apache 2.x, that might take a little time. PostgreSQL 8 would be nice. PHP5, possibly. I would be surprised if we didn't move to Python 2.4 (or 2.5 or whatever the current version is then). A lot of those applications doesn't necessarily take a long time by themselves, but together, they form a large, complex OS which takes time to stabilize. | Ok, 6 months may be too fast for some people (and I still want to know | about concrete examples where this is true and why), how about 9 | months? I work at something between an online publisher and an ISP -- we develop our own solutions and aren't really interested in what is «at the bottom». It's a fairly standard LAMP setup and we want it to be stable. Having to upgrade twice a year would take up significant resources and certainly not be something we're interested in. Nine months would be a bit too much, twelve to eighteen months would be nice, probably closer to twelve than eighteen. (This is just intended as one example where six months would be too frequent releases, but 30-odd, which we're looking at for Sarge, is too much.) On the other hand -- we need to decide whether we want time-based releases. Other projects have had great successes with them, but they might not be right for Debian. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
Florian Weimer wrote: > > Re: Paul van der Vlis in <[EMAIL PROTECTED]> > >> You will understand that my most important point is security-support. > > > > ...which Debian provides for its stable distribution at any time, even > > if the last stable release was ages ago. > > Where is the security support for woody's version of Mozilla, Samba > and PHP? Mozilla is a nightmare nobody can support - sadly. Samba is security-supported, the fix is pending though, but will be released soon. PHP is security supported and Debian is not vulnerable to the real vulnerabilities (CAN-2004-1019 and CAN-2004-1065), problems caused by faulty scripts are not considered an issue (and we'd have to issue a PHP updated every second day otherwise). I can only hope that the situation with Mozilla, Firefox, Galeon, Thunderbird and $whatnot will be better in sarge, but I have doubts. Regards, Joey PS: http://www.debian.org/security/nonvulns-woody#CAN-2004-1019 http://www.debian.org/security/nonvulns-woody#CAN-2004-1065 -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
Hi, On Saturday 08 January 2005 07:45, Christian Perrier wrote: > So, if we imagine we release sarge at February 1st (ahah), just > immediately announce that etch will enter the first freeze stages > (base packages frozen, testing-security checked, d-i frozen) on August > 1st. > > This will give all developers a good idea of the way they can organise > their work. So, even if respecting this schedule may be difficult, we > would probably give us better chances... AOL :-) (Seconded) I wanted to add this to http://wiki.debian.net/index.cgi?ReleaseProposals but as the wiki is read-only at the moment (because migration to a new server) I'll leave this as a reminder for me to try to do it tomorrow... regards, Holger
Re: New stable version after Sarge
On Fri, Jan 07, 2005 at 08:22:47PM -0600, Marcelo E. Magallon wrote: > Thing> has a release cycle that's not compatible with a 6 month release > period"? Say GNOME or KDE? Well, gets in the next > release. So simple. We are known for missing upstream releases by a > hair (sarge is almost certainly going to miss the next upgrade to > GNOME, perhaps to KDE, it's already missing X.org, gcc 3.4 is subject > to debate) so this wouldn't put us in a worse situation than now. And it's two version for the kernel late, not to mention the glibc from stoneage.
Re: New stable version after Sarge
On Sat, Jan 08, 2005 at 12:46:00PM -0500, William Ballard wrote: > On Fri, Jan 07, 2005 at 08:22:47PM -0600, Marcelo E. Magallon wrote: > > We don't have to go from X.0 to (X+1).0 in 6 months. It's > > perfectly ok to go from X.0 to X.1. > > .1 Releases aren't for adding functionality which was created after > the .0 release. It's for finishing the stuff you postponed doing so > you could ship. Well, traditionally we've never decided before hand that the next release is going to be 4.0 or 3.2 or the like. We work on whatever comes our way, and when it's ready someone decides if it's 4.0 or just 3.2. Some people are of course feel strongly about calling the next thing 3.2 and others would rather see 4.0 -- because got in -- even if Debian as a system isn't seeing any big leap. Since we try not to develop software ourselves it is sometimes hard to assess what makes a major release and what a minor one. Marcelo
Re: New stable version after Sarge
* Thomas Zimmerman: > Is that really true? I would love to run "apt-get dist-upgrade" every > half a year. Currently it doesn't get me much. :) Now, for production > systems, don't you do some testing *before* you upgrade the OS? Testing costs time and therefore money. Debian's secret corporate users really like the long release circles (although it's getting a bit excessive by now).
Re: New stable version after Sarge
On Fri, Jan 07, 2005 at 08:22:47PM -0600, Marcelo E. Magallon wrote: > We don't have to go from X.0 to (X+1).0 in 6 months. It's perfectly ok > to go from X.0 to X.1. .1 Releases aren't for adding functionality which was created after the .0 release. It's for finishing the stuff you postponed doing so you could ship. Does Debian postpone fixing things so it can ship? Big things?
Re: New stable version after Sarge
On Fri, Jan 07, 2005 at 12:50:04AM -0800, Steve Langasek wrote: > Yes, I don't think the release team has any intention of working > itself ragged to get a second release out 6 months after sarge. I > also don't think there's any consensus among developers (or users) > that we *want* to release Debian that frequently. Well, the development model in Linux (Free Software, OSS, whatever) is such that new hardware is supported in new releases. A commercial OS vendor does introduce support for newer hardware in older releases of their OS (I remember several cases of this on IRIX for example) via patch revisions or point releases or whatever they might want to call that. But this is a time-consuming task and most upstreams prefer to just release a new version. This is not always true of the kernel, that's right, but it's common in XFree86 and I have to assume that it's also the case for X.org. It's also true of things like GPhoto, or Gimp Print. Upstream does not want to waste time doing point releases of older software. People might argue that you "just" need to shift the load to the Debian maintainer. For security updates, yes, I can agree with that, but for "normal" updates, no, sorry. That means I do think that *users* have some interest in this kind of thing. Backports.org? No, that doesn't cut it. It's got to be officially supported by a release and on the install CD. Branching stable for this purpose (just like security updates) is not an option IMO. I don't think we have the manpower for this. > A 6-month period honestly doesn't allow us much time for new > development anyway. It depends on what you call development. Are you thinking of " has a release cycle that's not compatible with a 6 month release period"? Say GNOME or KDE? Well, gets in the next release. So simple. We are known for missing upstream releases by a hair (sarge is almost certainly going to miss the next upgrade to GNOME, perhaps to KDE, it's already missing X.org, gcc 3.4 is subject to debate) so this wouldn't put us in a worse situation than now. Are you thinking of say, the installer? I certainly *hope* that the installer is going to stay in the current status for at least another release! Another "whoos, let us restart from scratch" won't be welcome by anyone. And my hope is based on the fact that the new installer is *good* (instead of just adequate, like b-f). Or is it the next big thing going on with the archive? We don't have to go from X.0 to (X+1).0 in 6 months. It's perfectly ok to go from X.0 to X.1. > If all we wanted was a point release of sarge, that'd be fine; but I > think most people would like to see etch be an improvement over sarge > in more respects than just hardware driver count, and we have to be > realistic that this means a period of heavy changes followed by a > period to stabilize everything again. And *that* was our mistake with sarge. By introducing *many* heavy changes we burned ourselves out. These changes are very welcome, don't get me wrong. But I say it again: this is pushing our testing users away. Thanks to broadband there are many who are happy with "testing", but let's face it: for a very long time, it was a major risk to use testing and it had a _load_ of software that was either buggy or suboptimal, and the fixes were already present in unstable for a long time. I dumped testing on the machine I used to use on a daily basis around 2002 because it was a pain. Some people say this has improved since then, but if the kind of big changes that stalled testing back then happen again, well, it's back to square one. Ok, 6 months may be too fast for some people (and I still want to know about concrete examples where this is true and why), how about 9 months? How about 1 year? My point is: set a goal and try to accomplish it. Marcelo
Re: New stable version after Sarge
> A 6-month period honestly doesn't allow us much time for new development > anyway. If all we wanted was a point release of sarge, that'd be fine; but > I think most people would like to see etch be an improvement over sarge in > more respects than just hardware driver count, and we have to be realistic > that this means a period of heavy changes followed by a period to stabilize > everything again. I mostly agree with this analysis. We could however give us a better chance to reach this goal by putting a delay for the end of the "heavy changes" period, immediately, instead of just open the gates again and wait until someone feels it is time to think about the release..:-) So, if we imagine we release sarge at February 1st (ahah), just immediately announce that etch will enter the first freeze stages (base packages frozen, testing-security checked, d-i frozen) on August 1st. This will give all developers a good idea of the way they can organise their work. So, even if respecting this schedule may be difficult, we would probably give us better chances...
Re: New stable version after Sarge
On Fri, 7 Jan 2005 00:50:04 -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: >Yes, I don't think the release team has any intention of working itself >ragged to get a second release out 6 months after sarge. I also don't think >there's any consensus among developers (or users) that we *want* to release >Debian that frequently. We should, however, concentrate all available effort on keeping etch's release time _well_ below 24 months. 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
Re: New stable version after Sarge
El vie, 07-01-2005 a las 20:34 +1000, Anthony Towns escribiÃ: > Someone should patch Thunderbird so it handles M-F-T:. Grump. > > Wouter Verhelst wrote: > >>Packages qualify to be enter prestable after residing in testing for > >>ten days and having NO RC BUGS. The idea is to keep prestable in a > >>highly stable state at all times, a rolling stable if you will. > > That's how testing started off. We stopped doing this because > > Err, no, we didn't stop doing anything of the sort. > > > a) it at one point stalled glibc; as a result, nothing moved to testing > >anymore, and when it finally did, the changes were so dramatic that > >testing was broken for quite some time. > > Everytime glibc gets RC bugs, glibc gets stalled. It was stalled pretty > continuously for something like 8-10 months (iirc) in late 2002, > early-mid 2003. That is to say that at that point we couldn't produce a > releasable gibc in less than eight months. At the point that got fixed, > something was broken about at least KDE, and a whole range of other > interdependencies had come up. Outside of KDE, I don't recall any overly > major issues though. > > Fixing bugs early and often while still doing development is a tricky > task. In particular it involves both an attitude change from the way > many people tend to work (viz, "I'll fix all my RC bugs now, not wait > for someone to tell me to, or after I've implemented these few > features") and a different set of skills and techniques to actually > achieve (such as better pre-release testing so you don't release some > features that turn out to be horribly buggy and unfixable, but also so > useful that you don't want to rip them out from under people either). I think that this mind change could be accomplished better if we have a roadmap for important features and also a time for the freeze. But both have to be realistic, so people have the feeling that if they change a lot of things without testing those well before uploading to unstable, they can miss next release. > > The glibc team took a while to get a handle on those issues when they > took over the package; hopefully that's not an issue that'll come up > again. The KDE and Gnome folks are getting the hang of it now too, which > is why you can see major new versions of KDE and Gnome being accepted > now, and not causing significant disruptions to the release schedule > (such as it is). Yes, and IMO this is working pretty well. Mostly because there are coordination in those components like GNOME or KDE that involves a lot of components that should be uploaded in a short time to avoid problems, and in other teams like glibc or kernel one, bacause there is always some people wich can take the work when someone has other more important stuff eating their time (work, studies, ...) Perhaps we should try to push some other teams in other key areas of Debian (I can not think of any right now, but I am sure that they are), and also in the infraestructure part. Of course, installer team is also a key. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: New stable version after Sarge
El jue, 06-01-2005 a las 13:43 -0800, Will Lowe escribiÃ: > > Is that really true? I would love to run "apt-get dist-upgrade" every > > half a year. Currently it doesn't get me much. :) Now, for production > > systems, don't you do some testing *before* you upgrade the OS? > > Sure I do. But I run a production environment with several hundred > machines in it. We package our in-house software in .deb format to > make rollouts easy. > > I don't look forward to regressing all of that software, and it's > packaging, every six months on a new OS release. It's hard to do that > even every 18 months. Which will mean that people will skip at least one distribution if we released each 6 months, even two. That would put the burden on us of needing to have security support for even 2 more distributions older than current stable, which could not be possible. That's why I think that a 18 months release is the best compromise between server and desktop users. Other option could be make a splitted release. For example, release base+server each 18 months and make a debian-desktop release each 6, but this has also other side effects and implications which are not easily handled. IMHO we should focus on these points: - Having a clear roadmap for stuff we want to include or change before releasing etch. This roadmap should include things that are possible to be made in about one year from the release of sarge. Release managers should agree with that at make it "official". - A well known date for the freeze. About a year from Sarge release if we want to release in 18 months. - A working installer. Now we have one in very good shape. People working on it should also draw a roadmap of the functions they want to add in that period of time. The installer should be ready when the freeze, having some months then to check and polish. - Keep infraestructure working. What do we need to fix or to improve? What do we want to change? What do we need when we want to freeze etch? Waiting for security "to be ready" is a bit discouraging. - "Release essential" packages should be kept mostly free of RC bugs. We cannot let those packages to pile up RC bugs. For this, comantainership and the different teams that have arose recently are good, so we should push them. They should follow published roadmap. - For other packages, discourage maintainers to make hughe changes if not needed, but evolve them. And if those changes are needed, they should be done earlier in the time. For this, having a "fixed" freeze date could be quite important. Also, a hard policy for removing from testing buggy packages should be followed, over all when the freeze starts. This will need perhaps a utility like "deborphan" but checking which installed packages are not anymore in Packages file, so people using testing/released etch could know which packages were removed. Of course I know that all we are voluteers, and that it is a bit difficult to enforce a calendar as if we were a corporation, but IMO having a clear roadmap and schedule make most people to behave following that, avoiding the free ride period that follow each release, which also means that a lot of people doesn't remember that release infraestructure has also te be kept in good shape. Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: New stable version after Sarge
On Thu, Jan 06, 2005 at 09:06:20AM +0100, Marc Haber wrote: > On Wed, 5 Jan 2005 09:31:41 +1100, Andrew Pollock > <[EMAIL PROTECTED]> wrote: > >That said, this (rather large) blocker shouldn't be the issue it has been > >for this release for the next one. The two biggest blockers to releasing any > >time soon have been the installer and the security infrastructure. I'm > >actually not abreast of what the issue is with the security infrastructure, > >so I don't know if it's likely to be a blocker all over again come etch > >release time. I'd like to think it's going to easier to release etch sooner. > > I am more pessimistic about this. Boot floppies and security > infrastructure have been delaying woody for multiple months as well, > and if we don't have security and installer delaying etch, I am pretty > convinced that there will other stoppers this time. Like the big blob of GFDL issues and other things related to that. > We have been talking about a "release nightmare" with potato and > woody, and that sarge is an even bigger one is as clear as one can > see. I suspect a tendency here. Unfortunatly me too. If we want to release more often we need two branches. A regular development branch like this one and one that only update packages that do not affect anything (?) else. Like the point releases but with little more relaxed rules. Regards, // Ola > 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 > > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: New stable version after Sarge
Someone should patch Thunderbird so it handles M-F-T:. Grump. Wouter Verhelst wrote: Packages qualify to be enter prestable after residing in testing for ten days and having NO RC BUGS. The idea is to keep prestable in a highly stable state at all times, a rolling stable if you will. That's how testing started off. We stopped doing this because Err, no, we didn't stop doing anything of the sort. a) it at one point stalled glibc; as a result, nothing moved to testing anymore, and when it finally did, the changes were so dramatic that testing was broken for quite some time. Everytime glibc gets RC bugs, glibc gets stalled. It was stalled pretty continuously for something like 8-10 months (iirc) in late 2002, early-mid 2003. That is to say that at that point we couldn't produce a releasable gibc in less than eight months. At the point that got fixed, something was broken about at least KDE, and a whole range of other interdependencies had come up. Outside of KDE, I don't recall any overly major issues though. Fixing bugs early and often while still doing development is a tricky task. In particular it involves both an attitude change from the way many people tend to work (viz, "I'll fix all my RC bugs now, not wait for someone to tell me to, or after I've implemented these few features") and a different set of skills and techniques to actually achieve (such as better pre-release testing so you don't release some features that turn out to be horribly buggy and unfixable, but also so useful that you don't want to rip them out from under people either). The glibc team took a while to get a handle on those issues when they took over the package; hopefully that's not an issue that'll come up again. The KDE and Gnome folks are getting the hang of it now too, which is why you can see major new versions of KDE and Gnome being accepted now, and not causing significant disruptions to the release schedule (such as it is). OTOH, over half the open RC bugs were filed over three months ago, so it's not like this is a solved problem. But we are getting somewhere. b) Some RC bugs are only discovered when they migrate to testing. If the promise of 'prestable' would be that it would contain NO RC BUGS, then we would have to throw those out. That would likely result in prestable being a very incomplete system. If the promise were "NO BUGS" in any shape or form, we'd never be able to include any software. A new stable version gets released when we've got some new software that essentially has no RC bugs that we know about, not when it has no bugs at all. Trying to hold testing or some 'prestable' or whatever else to a higher standard isn't reasonable, let alone feasible. Also, adding yet another distribution that is even harder to update than testing is doesn't seem like a good idea to me. We're already having issues with testing and security; $DEITY forbid that we would make it worse. One of the reasons presented for not having security support for testing is that it changes too much. I suspect that argument would still be made for anything that changes more often than stable though. Cheers, aj
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 08:08:05PM -0600, Marcelo E. Magallon wrote: > On Tue, Jan 04, 2005 at 03:34:20PM +0100, Martin Schulze wrote: > > > One of the biggest disadvantages of Debian for me is the long time > > > it takes for a new stable version. > > > What about saying something like: the next stable release comes in > > > the beginning of 2006? > > The release date for a Debian release is not set by a calendar but by > > quality. At least that's been the case including sarge. Hence, such > > a sentence would not mean anything. > Then let's accept the premise behind the whole testing idea and target > Sarge+1 for Sarge+6 months. > Or does the team have plan that will stall that release for > another year? Yes, I don't think the release team has any intention of working itself ragged to get a second release out 6 months after sarge. I also don't think there's any consensus among developers (or users) that we *want* to release Debian that frequently. A 6-month period honestly doesn't allow us much time for new development anyway. If all we wanted was a point release of sarge, that'd be fine; but I think most people would like to see etch be an improvement over sarge in more respects than just hardware driver count, and we have to be realistic that this means a period of heavy changes followed by a period to stabilize everything again. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Thu, 6 Jan 2005 10:00:32 +0100, Jan Niehusmann <[EMAIL PROTECTED]> wrote: > Good point. But that problem can be solved by some program checking that > all installed packages are actually available from the selected > distribution(s). > > That could be integrated into apt (e.g. apt-get upgrade warning about > packaged without a current installation canditate, or where the most > recent version from the archives is older than the installed one), or it > could be a separate tool. Perhaps it can even be done with existing > tools? Aptitude already does this to some extent - packages which aren't available from a source in sources.list are placed in the "Obsolete and Locally Created Packages" section. Having a systematic warning would be annoying for people who have lots of locally-created packages, e.g. kernel packages... Stephen
Re: New stable version after Sarge
> Is that really true? I would love to run "apt-get dist-upgrade" every > half a year. Currently it doesn't get me much. :) Now, for production > systems, don't you do some testing *before* you upgrade the OS? Sure I do. But I run a production environment with several hundred machines in it. We package our in-house software in .deb format to make rollouts easy. I don't look forward to regressing all of that software, and it's packaging, every six months on a new OS release. It's hard to do that even every 18 months. -- thanks, Will
Re: New stable version after Sarge
Marc Sherman wrote: > Roberto Sanchez wrote: > > > >That makes me wonder. I know that there are tools like cron-apt that > >will perform apt-related tasks through cron jobs. Is there a way to > >make it (or another tool) download the changelogs and email you any > >new ones? > > I just filed a wishlist on cron-apt about that same thing this morning: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 > > If you have any suggestions on how to implement that, I'm all ears. apticron does exactly that: http://www.sage-ie.org/slides/case_study/automation/ A Debian package is available on apt.heanet.ie Frederic
Re: New stable version after Sarge
Ken Bloom([EMAIL PROTECTED])@2005-01-05 09:10: . > There's a discussion of release proposals ongoing at > http://wiki.debian.net/?ReleaseProposals > Please look around there to see what's going on and understand the ideas > that have been proposed. Thanks for the pointer ... reading through it now.. Steve
Re: New stable version after Sarge
On Thu, Jan 06, 2005 at 09:51:21AM +0100, Marc Haber wrote: > That would leave testing users who happen to have such a package > installed alone because they wouldn't notice their package vanishing > from the mirrors, continuing to use a potentially vulnerable package. Good point. But that problem can be solved by some program checking that all installed packages are actually available from the selected distribution(s). That could be integrated into apt (e.g. apt-get upgrade warning about packaged without a current installation canditate, or where the most recent version from the archives is older than the installed one), or it could be a separate tool. Perhaps it can even be done with existing tools? Jan
Re: New stable version after Sarge
On Wed, 5 Jan 2005 14:31:06 +0100, Bas Zoetekouw <[EMAIL PROTECTED]> wrote: >You wrote: >> ahh .. I take your point. What about the idea of identifying a list of >> release essential (RE) packages? > >I like that idea. We could even have a system to automagically throw >buggy non-RE packages out of testing. That would leave testing users who happen to have such a package installed alone because they wouldn't notice their package vanishing from the mirrors, continuing to use a potentially vulnerable package. 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
Re: New stable version after Sarge
On Wed, 05 Jan 2005 14:18:37 +0100, Florian Weimer <[EMAIL PROTECTED]> wrote: >* Joey Hess: >> I think we've taken this "security bugs arn't fixed in testing as well >> as in stable" thing as gospel a little too long without verifying it >> lately. I've been checking and if testing is lagging stable at all, it's >> doing so by a much smaller amount than we've traditionally thought. > >I think that's because of the pending release, in particular frozen >base packages, and not representative for the whole release cycle. Additionally, Maintainers refrain from updating unstable because they need unstable to update testing. See exim4, which has a grossly outdated version in unstable because there is no testing-proposed-updates yet. 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
Re: New stable version after Sarge
On Wed, 5 Jan 2005 09:31:41 +1100, Andrew Pollock <[EMAIL PROTECTED]> wrote: >That said, this (rather large) blocker shouldn't be the issue it has been >for this release for the next one. The two biggest blockers to releasing any >time soon have been the installer and the security infrastructure. I'm >actually not abreast of what the issue is with the security infrastructure, >so I don't know if it's likely to be a blocker all over again come etch >release time. I'd like to think it's going to easier to release etch sooner. I am more pessimistic about this. Boot floppies and security infrastructure have been delaying woody for multiple months as well, and if we don't have security and installer delaying etch, I am pretty convinced that there will other stoppers this time. We have been talking about a "release nightmare" with potato and woody, and that sarge is an even bigger one is as clear as one can see. I suspect a tendency here. 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
Re: New stable version after Sarge
On 05-Jan 09:30, Jose Carlos Garcia Sogo wrote: > El mié, 05-01-2005 a las 04:16 -0800, Stephen Birch escribió: > > Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: > > > Hello, > > > > > > One of the biggest disadvantages of Debian for me is the long time it > > > takes for a new stable version. > > > > I guess one man's meat is another man's poison. > > > > Since I administer a large number of distant computers I view the long > > time between stable releases as a feature not a bug. > > > > > What about saying something like: the next stable release comes in the > > > beginning of 2006? > > > > Once a year works for me, but any more frequent would be a pain in the > > neck. Frankly a release every 18 months seems about right. > > I agree with you on this. People using stable can not cope with > upgrades each 6 months or so. Is that really true? I would love to run "apt-get dist-upgrade" every half a year. Currently it doesn't get me much. :) Now, for production systems, don't you do some testing *before* you upgrade the OS? When debian release on a much fast and predictable schedule, it might be nice to have longer security support. Maybe the security team would only really _track_ security related problems and "remind" maintainers that they needed to update thier debs in Stable-1, and Stable-2. Thomas
Re: New stable version after Sarge
On 04-Jan 09:45, Steve Greenland wrote: > On 04-Jan-05, 07:40 (CST), Paul van der Vlis <[EMAIL PROTECTED]> wrote: > > One of the biggest disadvantages of Debian for me is the long time it > > takes for a new stable version. > > If you want Ubuntu or Progeny, you know where[1] to find them. :-) > > Seriously. There's just no way you're going to change the way Debian > makes releases, or rather, doesn't. It's too big, and there are just > too damn many people involved, many of whom simply don't care about > releases. As long as we maintain our current release criteria (which I > don't necessarily think we should change) we will get slower and slower > as we get bigger and bigger. > > Steve > > [1] Okay, just in case you don't: http://www.ubuntu.com/, > http://www.progeny.com How large of a change would it be to switch to a goal based releases? More along the lines of "new installer for sarge" and once all release goals have been met tag a release and only accept new packages that fix RC bugs. or Use popularity-contest results to find a "core" set of packages and make a release more time based, but only count RC bugs from those "core" packages (Maybe those packages that would fit on 2 CDs?) Debian is a great distro, but I can't really use it anywhere other than a static server (and even then woody's SpamAssassin is much too out of date to be usefull.) If an organization _needs_ the security and stability of hopefully^W historic debian release, than there is Progeny or decent admins to keep things running. It would be nice if testing really was "Testing" a whole set of packages where with every new release it was quickly switched to a new snapshot of Sid, or Sid when some major release goals where met. Thomas
Re: New stable version after Sarge
On Tue, 2005-01-04 at 20:25 -0600, Marcelo E. Magallon wrote: > Marcelo > > [0] Besides learning that there is still people in this world who seem > to think that feminism is actually a solution to something. I am > still amazed by that one. Not trying to start a subthread, but problem was legal paternalism, the solution was ?
Re: New stable version after Sarge
El miÃ, 05-01-2005 a las 23:13 +, Matthew Garrett escribiÃ: > Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> wrote: > > > I agree with you on this. People using stable can not cope with > > upgrades each 6 months or so. > > The issue isn't the frequency of new stable releases - the issue is how > long a given stable release will be supported for. Releasing every 6 > months wouldn't be a problem if we could support the previous two > releases as well. That's probably excessive, but the optimal release > length depends on how much support we can provide. Yes, but I think that we are not going to be able to support more than one release (or one and a half, if testing security team works) at a time, with perhaps supporting two for some time after the release of a new stable. This is not only an infraestructure problem, but a problem of DD time and DD effort and knowledge, which for some tasks can be a bit reduced. Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: New stable version after Sarge
Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> wrote: > I agree with you on this. People using stable can not cope with > upgrades each 6 months or so. The issue isn't the frequency of new stable releases - the issue is how long a given stable release will be supported for. Releasing every 6 months wouldn't be a problem if we could support the previous two releases as well. That's probably excessive, but the optimal release length depends on how much support we can provide. -- Matthew Garrett | [EMAIL PROTECTED]
Re: New stable version after Sarge
El miÃ, 05-01-2005 a las 04:16 -0800, Stephen Birch escribiÃ: > Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: > > Hello, > > > > One of the biggest disadvantages of Debian for me is the long time it > > takes for a new stable version. > > I guess one man's meat is another man's poison. > > Since I administer a large number of distant computers I view the long > time between stable releases as a feature not a bug. > > > What about saying something like: the next stable release comes in the > > beginning of 2006? > > Once a year works for me, but any more frequent would be a pain in the > neck. Frankly a release every 18 months seems about right. I agree with you on this. People using stable can not cope with upgrades each 6 months or so. > > > I can understand something like "Debian releases when it's ready", but > > many people have to work together. Maybe it's better to say: "a package > > releases when it's ready, but the deadline for the next Debian release > > is a fixed date". > > Also the concept of "releases when it's ready" seems to be a little > contrived. When *what* is ready exactly? The current system of > defining a release seems to involve identifying a number is arbitrarily > characteristics that will define the new version. The release occurs > when they are complete and the RC bug list is low. > > Perhaps a date based release mechanism could be built using a new > distribution, call it prestable. > > Packages qualify to be enter prestable after residing in testing for > ten days and having NO RC BUGS. The idea is to keep prestable in a > highly stable state at all times, a rolling stable if you will. > > So a package follows the following path: > > unstable --> testing --> prestable --(approx. 12 months)--> stable > > People running servers (like myself) will stick with stable. Those > wanting a reasonably stable system but want the latest features run > prestable. Those wanting the very latest but don't care about RC bugs > run testing. Developers normally run unstable. > > In some ways prestable would resemble the current stable when the > release manager has begun freezing it. But here lacks how packages migrate from testing to prestable. Is this a snapshot of testing at, lets say 12 months with 6 months for checking it, or does packages migrate following soe guidelines as they do right now from unstable to testing? > > Of course one would not want prestable to be released with critical > components missing. To prevent such a thing a number of packages are > identified as release essential (RE). Every RE package > has to have migrated from testing to prestable for the annual release > to take place. > > Any non-RE packages with RC bugs at release time simply do not make it > into the stable release for that year. If it looks like a critical > package will be ommited the release manager can always make that > package RE. Ok, that is nice for RE packages. But how other packages would be handled? Without an aggressive removal policy, they can take longer for being ready that the release time. Of course, it is supposed that testing doesn't have RC bugs, but you know that is not always true. > > Although the target is for an annual release to occur, the proposed > mechanism also permits the project to identify a set of features for > the new release. For example, had prestable existed for 3.1 the new > installer would have been listed as RE. > > So ... Debian would still release "when its ready" but everyone has a > better idea of what "ready" means simply by looking at the RE package > list. Why don't you put this idea in Debian Wiki? (http://wiki.debian.net/?ReleaseProposals) Thanks. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 02:18:37PM +0100, Florian Weimer wrote: > * Joey Hess: > > I think we've taken this "security bugs arn't fixed in testing as well > > as in stable" thing as gospel a little too long without verifying it > > lately. I've been checking and if testing is lagging stable at all, it's > > doing so by a much smaller amount than we've traditionally thought. > I think that's because of the pending release, in particular frozen > base packages, and not representative for the whole release cycle. > If a switch to a new upstream version of libc runs into problems, > testing and unstable will diverge again, maybe for weeks or months. > testing-security intends to solve this, though. If a switch to a new upstream version of libc runs into these kinds of problems again in unstable, we aren't learning from our mistakes, and it's questionable whether any amount of strategizing will put is in a position to do time-based releases. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 06:07:41AM -0800, Stephen Birch wrote: > Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: > > You should ask the release managers about that. > Wow!! You mean the decision process is not made public? I would have > thought it would be out in the open for all to see. Hmm, I would've thought that after 5 months of the Same Old Story, anyone reading d-d-a would know what the preconditions are for freezing sarge. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
Florian Weimer wrote: > I think that's because of the pending release, in particular frozen > base packages, and not representative for the whole release cycle. There's some truth to that, but of course many of our worst dependency knots do not involve base packages. -- see shy jo signature.asc Description: Digital signature
Re: New stable version after Sarge
Quoting Robert Lemmen <[EMAIL PROTECTED]>: > On Wed, Jan 05, 2005 at 12:30:52PM -0500, Marc Sherman wrote: > > >That makes me wonder. I know that there are tools like cron-apt that > > >will perform apt-related tasks through cron jobs. Is there a way to > > >make it (or another tool) download the changelogs and email you any > > >new ones? > > > > I just filed a wishlist on cron-apt about that same thing this morning: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 > > doesn't apt-listchanges do that? > apt-listchanges shows the changes since the version of the package that is currently installed. If I am running testing and only interested in upgrading packages in response to a security fix, the amount of info could get big really fast. It would need to implement something similar to logcheck. It only shows changes since the last time it showed you changes. apt-listchanges also shows all changelog entries. The first time you run apt-show-security-changelogs, it would essentially function like apt-listchanges in that it would show the changelogs since the currently installed versions, with the exception that it does a 'grep -i \[security\]' on the changelogs. After that, say if it is run in a cron job, it will show you the appropriate changelogs only if it has not already chown you that particular changelog entry. There would need to be some whay for it to track what changelog entries have and hove not already been shown. That way, if I install package foo, it knows to start showing me any security-related changelog entries for that package, but only from that point forward. -Roberto Sanchez This message was sent using IMP, the Internet Messaging Program.
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 12:30:52PM -0500, Marc Sherman wrote: > >That makes me wonder. I know that there are tools like cron-apt that > >will perform apt-related tasks through cron jobs. Is there a way to > >make it (or another tool) download the changelogs and email you any > >new ones? > > I just filed a wishlist on cron-apt about that same thing this morning: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 doesn't apt-listchanges do that? cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: New stable version after Sarge
Roberto Sanchez wrote: > That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? I just filed a wishlist on cron-apt about that same thing this morning: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 If you have any suggestions on how to implement that, I'm all ears. - Marc
Re: New stable version after Sarge
On Wed, 05 Jan 2005 04:16:49 -0800, Stephen Birch wrote: > Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: >> Hello, >> >> One of the biggest disadvantages of Debian for me is the long time it >> takes for a new stable version. > > I guess one man's meat is another man's poison. > > Since I administer a large number of distant computers I view the long > time between stable releases as a feature not a bug. > >> What about saying something like: the next stable release comes in the >> beginning of 2006? > > Once a year works for me, but any more frequent would be a pain in the > neck. Frankly a release every 18 months seems about right. > >> I can understand something like "Debian releases when it's ready", but >> many people have to work together. Maybe it's better to say: "a package >> releases when it's ready, but the deadline for the next Debian release >> is a fixed date". > > Also the concept of "releases when it's ready" seems to be a little > contrived. When *what* is ready exactly? The current system of defining a > release seems to involve identifying a number is arbitrarily > characteristics that will define the new version. The release occurs when > they are complete and the RC bug list is low. > > Perhaps a date based release mechanism could be built using a new > distribution, call it prestable. > > Packages qualify to be enter prestable after residing in testing for ten > days and having NO RC BUGS. The idea is to keep prestable in a highly > stable state at all times, a rolling stable if you will. > > So a package follows the following path: > > unstable --> testing --> prestable --(approx. 12 months)--> stable > > People running servers (like myself) will stick with stable. Those wanting > a reasonably stable system but want the latest features run prestable. > Those wanting the very latest but don't care about RC bugs run testing. > Developers normally run unstable. > > In some ways prestable would resemble the current stable when the release > manager has begun freezing it. > > Of course one would not want prestable to be released with critical > components missing. To prevent such a thing a number of packages are > identified as release essential (RE). Every RE package has to have > migrated from testing to prestable for the annual release to take place
Re: New stable version after Sarge
On Tuesday 04 January 2005 05:58 pm, Neil McGovern wrote: > Recently, I did have a box rooted. This was due to a user running phpbb > on the system, without me knowing, despite the policy of no software > without clearance from me. My I ask, how did the attacker get root? Did the user have root access that was used to install phpbb, or was a local exploit used once the user's account was compromised? Josh
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 06:07:41AM -0800, Stephen Birch wrote: > Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: > > > > You should ask the release managers about that. > > > > Wow!! You mean the decision process is not made public? I would have > thought it would be out in the open for all to see. No, I mean 'I dunno, but these are the people who probably will' ;-) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 08:11:44AM -0500, Greg Folkert wrote: > > OK, exactly what are YOU NOT DOING, now? Come on, I know you CAN'T be > that busy. You only maintain a few trivial packages... come on you could > NMU the kernel-source-2.[4|6] fixing all th issues. No need to MMU. The debian-kernel team is doing pretty regular uploads. Sending us diffs to fix bugs is of course highly welcome.
Re: New stable version after Sarge
Bas Zoetekouw([EMAIL PROTECTED])@2005-01-05 14:31: > > I like that idea. We could even have a system to automagically throw > buggy non-RE packages out of testing. > That wouldn't be a bad idea at all. In the recent DPL interview: http://www.newsforge.com/article.pl?sid=04/12/23/2023223 Martin indicated that Debian now contains over 10,000 packages. That is HUGE. I would think some culling has to happen at some point either using bug counts or, as has been suggested, an analysis of popcon results. Or both. Although zero package usage would also result in zero bug reports ;-) Steve
Re: New stable version after Sarge
Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: > > You should ask the release managers about that. > Wow!! You mean the decision process is not made public? I would have thought it would be out in the open for all to see. Mind you, Debian seems to be a hotbed of emotion at times so perhaps a less visible approach is necessary :-) Steve
Re: New stable version after Sarge
Hi Stephen! You wrote: > ahh .. I take your point. What about the idea of identifying a list of > release essential (RE) packages? I like that idea. We could even have a system to automagically throw buggy non-RE packages out of testing. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 05:12:57AM -0800, Stephen Birch wrote: > Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 13:46: > > That's how testing started off. We stopped doing this because > > a) it at one point stalled glibc; as a result, nothing moved to > > testing > >anymore, and when it finally did, the changes were so dramatic > >that > >testing was broken for quite some time. > > Hmmm .. I didnt know that testing was originally a non-RC distribution > although I have heard of the glibc pain. Again, I'm not entirely sure this is exactly what happened; but I am quite sure this is what /will/ happen if we go down that road. > > b) Some RC bugs are only discovered when they migrate to testing. If > > the > >promise of 'prestable' would be that it would contain NO RC BUGS, > >then we would have to throw those out. That would likely result > > in > >prestable being a very incomplete system. > > ahh .. I take your point. What about the idea of identifying a list of > release essential (RE) packages? Is that the mechanism actually used > to determine the relase point when testing is frozen? You should ask the release managers about that. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New stable version after Sarge
* Joey Hess: > I think we've taken this "security bugs arn't fixed in testing as well > as in stable" thing as gospel a little too long without verifying it > lately. I've been checking and if testing is lagging stable at all, it's > doing so by a much smaller amount than we've traditionally thought. I think that's because of the pending release, in particular frozen base packages, and not representative for the whole release cycle. If a switch to a new upstream version of libc runs into problems, testing and unstable will diverge again, maybe for weeks or months. testing-security intends to solve this, though.
Re: New stable version after Sarge
Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 13:46: > That's how testing started off. We stopped doing this because > a) it at one point stalled glibc; as a result, nothing moved to > testing >anymore, and when it finally did, the changes were so dramatic >that >testing was broken for quite some time. Hmmm .. I didnt know that testing was originally a non-RC distribution although I have heard of the glibc pain. > b) Some RC bugs are only discovered when they migrate to testing. If > the >promise of 'prestable' would be that it would contain NO RC BUGS, >then we would have to throw those out. That would likely result > in >prestable being a very incomplete system. ahh .. I take your point. What about the idea of identifying a list of release essential (RE) packages? Is that the mechanism actually used to determine the relase point when testing is frozen? Forgive me if I tread a well worn path, I was not involved with Debian when woody was released so this is my first experience with a release. Steve
Re: New stable version after Sarge
On Wed, 2005-01-05 at 10:45 +0100, Marco d'Itri wrote: > On Jan 04, Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > It shouldn't be forgotten that the biggest blocker after these things is > > probably a general failure to actually care all that much. How many > > people are actually behaving as if a release is just around the corner? > A very simple way would be to make them believe that this is true, and > this is going to be hard if it's not. > > Let's try a different approach: everybody should ask himself "is > something I am doing or not doing holding the release?". > And after fixing his own work then ask "who is left doing or not > something which is holding the release?", and start pointing fingers. > (Pointing fingers may not help speeding up the release, but will be an > useful distraction while we wait.) OK, exactly what are YOU NOT DOING, now? Come on, I know you CAN'T be that busy. You only maintain a few trivial packages... come on you could NMU the kernel-source-2.[4|6] fixing all th issues. To that extent, there is only a few hundred RC bugs. Me, You ask? I am already too busy to help out. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux P.S. Of course you hopefully realize, that this is a flippant remark. signature.asc Description: This is a digitally signed message part
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 04:16:49AM -0800, Stephen Birch wrote: > Perhaps a date based release mechanism could be built using a new > distribution, call it prestable. > > Packages qualify to be enter prestable after residing in testing for > ten days and having NO RC BUGS. The idea is to keep prestable in a > highly stable state at all times, a rolling stable if you will. That's how testing started off. We stopped doing this because a) it at one point stalled glibc; as a result, nothing moved to testing anymore, and when it finally did, the changes were so dramatic that testing was broken for quite some time. b) Some RC bugs are only discovered when they migrate to testing. If the promise of 'prestable' would be that it would contain NO RC BUGS, then we would have to throw those out. That would likely result in prestable being a very incomplete system. Also, adding yet another distribution that is even harder to update than testing is doesn't seem like a good idea to me. We're already having issues with testing and security; $DEITY forbid that we would make it worse. (not being a member of the release team, the above isn't guaranteed to be right in all details; but I don't think I'm way off base here) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New stable version after Sarge
Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: > Hello, > > One of the biggest disadvantages of Debian for me is the long time it > takes for a new stable version. I guess one man's meat is another man's poison. Since I administer a large number of distant computers I view the long time between stable releases as a feature not a bug. > What about saying something like: the next stable release comes in the > beginning of 2006? Once a year works for me, but any more frequent would be a pain in the neck. Frankly a release every 18 months seems about right. > I can understand something like "Debian releases when it's ready", but > many people have to work together. Maybe it's better to say: "a package > releases when it's ready, but the deadline for the next Debian release > is a fixed date". Also the concept of "releases when it's ready" seems to be a little contrived. When *what* is ready exactly? The current system of defining a release seems to involve identifying a number is arbitrarily characteristics that will define the new version. The release occurs when they are complete and the RC bug list is low. Perhaps a date based release mechanism could be built using a new distribution, call it prestable. Packages qualify to be enter prestable after residing in testing for ten days and having NO RC BUGS. The idea is to keep prestable in a highly stable state at all times, a rolling stable if you will. So a package follows the following path: unstable --> testing --> prestable --(approx. 12 months)--> stable People running servers (like myself) will stick with stable. Those wanting a reasonably stable system but want the latest features run prestable. Those wanting the very latest but don't care about RC bugs run testing. Developers normally run unstable. In some ways prestable would resemble the current stable when the release manager has begun freezing it. Of course one would not want prestable to be released with critical components missing. To prevent such a thing a number of packages are identified as release essential (RE). Every RE package has to have migrated from testing to prestable for the annual release to take place. Any non-RE packages with RC bugs at release time simply do not make it into the stable release for that year. If it looks like a critical package will be ommited the release manager can always make that package RE. Although the target is for an annual release to occur, the proposed mechanism also permits the project to identify a set of features for the new release. For example, had prestable existed for 3.1 the new installer would have been listed as RE. So ... Debian would still release "when its ready" but everyone has a better idea of what "ready" means simply by looking at the RE package list. Steve
Re: New stable version after Sarge
Jan Niehusmann wrote: > Unfortunately, testing does not guarantee security updates. Of course given the security+woody tagged RC bugs #237422, #246443, #274225, #278625, #278942, #284031, #192732, #196590, #198567, #199351, #202244, #223456, #244810, #244811, #250106, #260508, #260838, #268783, #273377, #279680, #279726, #279870, #280883, #281665, #281922, perhaps stable doesn't either. All of those bugs are > 1 month old and fixed in sarge. I think we've taken this "security bugs arn't fixed in testing as well as in stable" thing as gospel a little too long without verifying it lately. I've been checking and if testing is lagging stable at all, it's doing so by a much smaller amount than we've traditionally thought. It's not even lagging unstable too badly lately aside from kde, which was just resolved. And we do have the testing security team trying to work on improving it too. -- see shy jo signature.asc Description: Digital signature
Re: New stable version after Sarge
Marcelo E. Magallon wrote: [...] [0] Besides learning that there is still people in this world who seem to think that feminism is actually a solution to something. I am still amazed by that one. Thankyou for reminding us all, by demonstration, that the problems feminism tries to solve still exist within Debian :) I suspect that you are using a very narrow definition of "feminism" here. Your comment is insulting to people who are working to fix such problems as sexist language in Debian webpages and sexist behaviour on Debian IRC channels, let alone the more subtle and complex things that some of us, who identify as feminists, are trying to achieve. However I believe your comment is more likely to have been made in ignorance than with malice. If you are interested instead in helping us to solve some of the problems women face in their involvement with Debian (with associated benefits for Debian) drop by the Debian Women project someday and ask us what we are really doing. You are invited to be part of the solution... Helen.
Re: New stable version after Sarge
In article <[EMAIL PROTECTED]>, Otto Wyss <[EMAIL PROTECTED]> wrote: >Stopping releasing might be a good idea but there should be a better >way. IMO the problem is the stable release isn't updated on a regulare >basis. It might be a better idea to divide Debian into subsystems which >could be released much faster when needed. I agree with this. Traditional OS vendors also release "the OS" and "the applications" seperately, seems to work better.. Mike.
Re: New stable version after Sarge
On Jan 04, Matthew Garrett <[EMAIL PROTECTED]> wrote: > It shouldn't be forgotten that the biggest blocker after these things is > probably a general failure to actually care all that much. How many > people are actually behaving as if a release is just around the corner? A very simple way would be to make them believe that this is true, and this is going to be hard if it's not. Let's try a different approach: everybody should ask himself "is something I am doing or not doing holding the release?". And after fixing his own work then ask "who is left doing or not something which is holding the release?", and start pointing fingers. (Pointing fingers may not help speeding up the release, but will be an useful distraction while we wait.) -- ciao, Marco signature.asc Description: Digital signature
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 06:54:51PM -0500, William Ballard wrote: > On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: > > We've spent most of the past year thinking a release might be just round > > the corner. We can only cry wolf so many times before the world stops > > believing us and finds an option that actually works. > > I started using Linux (and Debian) a couple months after Woody "came > out." Was woody due "any day now" for a year like this? To a large extent, yes. -- Colin Watson [EMAIL PROTECTED]
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: > We've spent most of the past year thinking a release might be just > round the corner. We can only cry wolf so many times before the world > stops believing us and finds an option that actually works. You ought to hear the jokes I get to hear once a month on the local LUG meetings. Oh dear, next meeting is this saturday. Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 03:34:20PM +0100, Martin Schulze wrote: > > One of the biggest disadvantages of Debian for me is the long time > > it takes for a new stable version. > > > > What about saying something like: the next stable release comes in > > the beginning of 2006? > > The release date for a Debian release is not set by a calendar but by > quality. At least that's been the case including sarge. Hence, such > a sentence would not mean anything. Then let's accept the premise behind the whole testing idea and target Sarge+1 for Sarge+6 months. Or does the team have plan that will stall that release for another year? > What if the installer is broken at that time? debian-installer is good as it is now. Sarge+6 months should be able to use more or less the same installer, plus new drivers. And a cursory look at the debian installer code gives me the impression that adding new drivers should be relatively easy. > What if the buildd network is busted at that time? Well, I surely hope the buildd network won't be busted for x time (where x is much larger than a couple of weeks). Do you have something concrete in mind (like, say, one half of an arch builders bailing out because people can't seem to talk to each other or something like that?) > What if n library transitions are in progress at that time? Well... according to the testing delus^Widea, this should not happen. Or, if it happens, it should be not so difficult to handle... Oh... hi, reality... nice to make your acquaintance. > What if our archive suite lacks an important improvement which is a > requirement for being able to maintain the new stable release? Come on. This one really feels like a cheap excuse. First, are any such important-can't-wait-a-second-longer improvements scheduled? Second, there's such a thing as testing. No, not that part of the archive. Real testing. Calling for people to upload real packages to a testing archive. Doing real work with the testing archive. Bouncing real uploads from the real archive to the testing archive. Such things. Third, there's also planning ahead. If Bar wants to absolutely have that important improvement before sarge+1, Bar should allot something like 3-4 *months* before the target release date for the in-archive testing phase and be ready to commit some time for urgent fixes. If that can't be done because all this is volunteer work and all those things (that I can fully relate to and I'm not downplaying one iota!), then sorry, we can't have that important improvement. IOW, don't stall the whole project because of your pet peeve. > Sure, you could still release, but would you really like to have such > a release? I would like to get rid of the "Debian can't make timely releases" and "Debian stable is a bunch of out-of-date software" stigmas. In fewer words: I want to have the cake and eat it, too. Debian stable without the 2 year lapsus in between. > What if security support for a new release cannot be guaranteed at > that time? That is a show stopper. "We did our best, but we can't release Debian Sarge+1 at this time. New target date for release: ..." If you give people a target to work with, with enough time (and "enough" has to take into consideration that Debian is still mostly put together by volunteers), people can plan ahead. The current chaos does not give *developers* this. And users get frustrated each time they see a Debian 3.0rX come out, but no sarge in sight. I do get your point and I'm not saying that it is easy (or even possible!) to stick to a faster release schedule, but refusing it upfromt without trying does not help. Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 10:35:37PM +, Matthew Garrett wrote: > It shouldn't be forgotten that the biggest blocker after these things > is probably a general failure to actually care all that much. How > many people are actually behaving as if a release is just around the > corner? How can we fix this? Talk to your leader. He's a "persons" person (I recall some talk about motivating people and stuff like like during the elections). No, I don't really mean that seriously. At least not the part about going to talk to Martin. It's a motivation problem. Simple as that. There's no cohesion. I have the feeling there's too much "behind the scenes" talking taking place. This mailing list is not even the shadow of what it used to be. There are hardly any really technical discussions taking place here. I doubt someone can actually *learn* something from following d-d anymore[0]. That means this mailing list has become somewhat a burden, not something you can enjoy, which is the cornerstone of volunteer work. A release is a big motivation boost: it's something you can see, something you can point people to. Ride on that wave. Debian's problem, seen from the inside (you don't have to give a damn about what the Slashdot crowd says), is that we let that wave break, and there isn't another one coming behind it. Marcelo [0] Besides learning that there is still people in this world who seem to think that feminism is actually a solution to something. I am still amazed by that one.
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 03:41:41PM +0100, Christoph Berg wrote: > ...which Debian provides for its stable distribution at any time, > even if the last stable release was ages ago. How does a fixed > release date help there? Besides Florian's point, you have to consider that Debian needs people actually testing what's going to be released. And many of the people doing the testing, are doing it because they want to have something reliable that they can use at their "work"place (however "work" is defined here). But at some point they just can't take that "let's use a Desktop environment which is two years old and has significant usability bugs which were fixed a year ago" anymore and they go away. So Debian hurts itself at the end of the day. So, no, a fixed date doesn't help. A release schedule does. (And no "we will release in two years time" is not a release schedule in this context). Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 07:45:12PM -0500, Roberto Sanchez wrote: > >I subscribe to debian-security (+ d-s-announce) and get reports whenever > >there's anything released. > >I know what is installed on my boxes, so I know if this announcement > >affects me. > > > You are probably in the minority, then. > Yes, probably, but I'm using testing, which isn't supported by the standard security team. Therefore, it's now my sole reponsibility to look at security changes. > >Recently, I did have a box rooted. This was due to a user running phpbb > >on the system, without me knowing, despite the policy of no software > >without clearance from me. > > > That really sucks. > Yup. It's annoying to have to travel down to London because of it. The user was suitably 'chastised' :) > The only you did not address is when there is a security fix for which > there is not an announcement. If a package is not already in Woody, > then it is not receiving security team support and will go under the > radar. Additionally, some maintainers work closely with upstream and > fix the problems almost immediately. In both of those cases, you would > need to be monitoring the changelog for each of your packages and > watching for security-related changes to packages. > These normally crop up in either: * security list and/or * various irc channels However, it's not something that I would expect a normal user to do. But I woudn't be expecting a normal user to be using testing for a production system. > That makes me wonder. I know that there are tools like cron-apt that > will perform apt-related tasks through cron jobs. Is there a way to > make it (or another tool) download the changelogs and email you any new > ones? > Would be worth writing, but IMO a list with various people looking at different changelogs is just as reliable. Like various lists already out there :) Warm regards, Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 signature.asc Description: Digital signature
Re: New stable version after Sarge
Neil McGovern wrote: On Tue, Jan 04, 2005 at 02:58:42PM -0500, [EMAIL PROTECTED] wrote: I would strongly caution against using Sarge for a production system until there is security team support. See this message I posted to d-u when someone pointed out that they were running sarge on some servers: http://lists.debian.org/debian-user/2004/12/msg03846.html Interesting. Recently, I've started using testing on production servers. I subscribe to debian-security (+ d-s-announce) and get reports whenever there's anything released. I know what is installed on my boxes, so I know if this announcement affects me. You are probably in the minority, then. If it's been put into unstable, I'll backport the change myself. If it's not, Then I'll have a look at upstream's solution, and patch as required. This is good. Recently, I did have a box rooted. This was due to a user running phpbb on the system, without me knowing, despite the policy of no software without clearance from me. That really sucks. There's also not necesarrily a 10 day waiting period if the urgency is set high. Neil The only you did not address is when there is a security fix for which there is not an announcement. If a package is not already in Woody, then it is not receiving security team support and will go under the radar. Additionally, some maintainers work closely with upstream and fix the problems almost immediately. In both of those cases, you would need to be monitoring the changelog for each of your packages and watching for security-related changes to packages. That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? -Roberto Sanchez signature.asc Description: OpenPGP digital signature
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: > We've spent most of the past year thinking a release might be just round > the corner. We can only cry wolf so many times before the world stops > believing us and finds an option that actually works. I started using Linux (and Debian) a couple months after Woody "came out." Was woody due "any day now" for a year like this? For what it's worth Microsoft goes into feature freeze about a year before an OS ships. They fork the kernel then. About the only thing that changes after that is the icons and desktop colors.
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 10:35:37PM +, Matthew Garrett wrote: > Andrew Pollock <[EMAIL PROTECTED]> wrote: > > That said, this (rather large) blocker shouldn't be the issue it has > > been for this release for the next one. The two biggest blockers to > > releasing any time soon have been the installer and the security > > infrastructure. I'm actually not abreast of what the issue is with > > the security infrastructure, so I don't know if it's likely to be a > > blocker all over again come etch release time. I'd like to think > > it's going to easier to release etch sooner. > It shouldn't be forgotten that the biggest blocker after these things > is probably a general failure to actually care all that much. How many > people are actually behaving as if a release is just around the > corner? How can we fix this? We've spent most of the past year thinking a release might be just round the corner. We can only cry wolf so many times before the world stops believing us and finds an option that actually works. J. -- She's the one for me. She's all I really need, oh yeah. Bring some pragmatism back to Debian - mjg59 for DPL!
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 02:58:42PM -0500, [EMAIL PROTECTED] wrote: > > I would strongly caution against using Sarge for a production system > until there is security team support. See this message I posted to d-u > when someone pointed out that they were running sarge on some servers: > > http://lists.debian.org/debian-user/2004/12/msg03846.html > Interesting. Recently, I've started using testing on production servers. I subscribe to debian-security (+ d-s-announce) and get reports whenever there's anything released. I know what is installed on my boxes, so I know if this announcement affects me. If it's been put into unstable, I'll backport the change myself. If it's not, Then I'll have a look at upstream's solution, and patch as required. Recently, I did have a box rooted. This was due to a user running phpbb on the system, without me knowing, despite the policy of no software without clearance from me. There's also not necesarrily a 10 day waiting period if the urgency is set high. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3
Re: New stable version after Sarge
Andrew Pollock <[EMAIL PROTECTED]> wrote: > That said, this (rather large) blocker shouldn't be the issue it has been > for this release for the next one. The two biggest blockers to releasing any > time soon have been the installer and the security infrastructure. I'm > actually not abreast of what the issue is with the security infrastructure, > so I don't know if it's likely to be a blocker all over again come etch > release time. I'd like to think it's going to easier to release etch sooner. It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? How can we fix this? -- Matthew Garrett | [EMAIL PROTECTED]
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 04:25:00PM +0100, Martin Schulze wrote: > Paul van der Vlis wrote: > > >At least that's been the case including sarge. Hence, such > > >a sentence would not mean anything. > > > > > >>I can understand something like "Debian releases when it's ready", but > > >>many people have to work together. Maybe it's better to say: "a package > > >>releases when it's ready, but the deadline for the next Debian release > > >>is a fixed date". > > > > > >What if the installer is broken at that time? > > > > Normally a broken installer does not come into testing (ehm, I don't > > know for sure the installer is a normal package). > > During the preparation of sarge there was a long time where the > installer didn't work as it should have. Go read the archives. That said, this (rather large) blocker shouldn't be the issue it has been for this release for the next one. The two biggest blockers to releasing any time soon have been the installer and the security infrastructure. I'm actually not abreast of what the issue is with the security infrastructure, so I don't know if it's likely to be a blocker all over again come etch release time. I'd like to think it's going to easier to release etch sooner. regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten! signature.asc Description: Digital signature
Re: New stable version after Sarge
On Tue, 2005-01-04 at 14:58 -0500, [EMAIL PROTECTED] wrote: > Quoting Thomas Jollans <[EMAIL PROTECTED]>: > > Well, you could argue that debian branches are not perfectly named but: > > "stable" is best if you need *absolute* failsafety for critical jobs > > "testing" is best if you want a stable system with new(ish) software > > "unstable" is for everybody who needs the newest software, like me. > > > > honestly, I have never had problems (yet) with using sid for day-to-day > > stuff. If I needed something more production-ready, I'd use testing > > because you have (almost) garantee that the software will work and you > > will have security updates, too. (But not in the same quality as > > "stable", as I understand it. If I needed to run a always-needed > > very-important server on the internet, I would use "stable". > > > > I would strongly caution against using Sarge for a production system > until there is security team support. See this message I posted to d-u > when someone pointed out that they were running sarge on some servers: > > http://lists.debian.org/debian-user/2004/12/msg03846.html I also commented in the thread, if you recall. I stated I run SID/experimental for certain things, Testing with updates from SID if need be... etc. The thing is, that unless you *really* know how and what you are doing with pinning and preferences and the mighty good reasons for doing them, you should stick with Stable for servers. People that think "ahhh, what could happen" or "Bah, I'm only one IP addr" or even the penultimate "Dude, I am running SID with Experimental Preferred that is SOOO 31337!" Are just asking for their machine to be ummm... cracked/whacked or put out of its misery. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: New stable version after Sarge
Quoting Thomas Jollans <[EMAIL PROTECTED]>: > Paul van der Vlis wrote: > > > Hello, > > > > One of the biggest disadvantages of Debian for me is the long time it > > takes for a new stable version. > > > > What about saying something like: the next stable release comes in the > > beginning of 2006? > > > > I can understand something like "Debian releases when it's ready", but > > many people have to work together. Maybe it's better to say: "a > > package releases when it's ready, but the deadline for the next Debian > > release is a fixed date". > > > > You will understand that my most important point is security-support. > > > > With regards, > > Paul van der Vlis. > > > > > Well, you could argue that debian branches are not perfectly named but: > "stable" is best if you need *absolute* failsafety for critical jobs > "testing" is best if you want a stable system with new(ish) software > "unstable" is for everybody who needs the newest software, like me. > > honestly, I have never had problems (yet) with using sid for day-to-day > stuff. If I needed something more production-ready, I'd use testing > because you have (almost) garantee that the software will work and you > will have security updates, too. (But not in the same quality as > "stable", as I understand it. If I needed to run a always-needed > very-important server on the internet, I would use "stable". > I would strongly caution against using Sarge for a production system until there is security team support. See this message I posted to d-u when someone pointed out that they were running sarge on some servers: http://lists.debian.org/debian-user/2004/12/msg03846.html -Roberto Sanchez This message was sent using IMP, the Internet Messaging Program.
Re: New stable version after Sarge
[Mason Loring Bliss] > Ooh... This is arguably the most exciting Debian-related thing I've > heard of in some time! A security team for Sarge. Dreamy! Thank you. But it is not for sarge. It is for testing. When sarge is released, the team will move on to sarge+1. :) Joey Hess is the coordinator of the effort, funded by Debian Edu. We would hire more people if we had the funds. :)
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 06:15:30PM +0100, Petter Reinholdtsen wrote: > > This may change with a testing-security upload queue. > > Yes. The testing security team might help here too. > https://alioth.debian.org/projects/secure-testing/>. Ooh... This is arguably the most exciting Debian-related thing I've heard of in some time! A security team for Sarge. Dreamy! -- Mason Loring Bliss [EMAIL PROTECTED] They also surf who awake ? sleep : dream; http://blisses.org/ only stand on waves. pgpCLOxakqDxb.pgp Description: PGP signature
Re: New stable version after Sarge
Tim Cutts <[EMAIL PROTECTED]> wrote: > > Seriously. There's just no way you're going to change the way Debian > > makes releases, or rather, doesn't. It's too big, and there are just > > too damn many people involved, many of whom simply don't care about > > releases. As long as we maintain our current release criteria (which I > > don't necessarily think we should change) we will get slower and slower > > as we get bigger and bigger. > Which is a rather clear sign that the way Debian makes releases has outgrown its usefulness. > Which could be seen as a problem by some; but in some ways it's > probably the way to go. As far as my own use of Debian goes, almost > every machine I install runs testing, and has done for years. There's > a level of protection in there thanks to the rules that are in place, > and I rather like the incremental improvement approach as opposed to > release-based. > Me too, but it might be completely different if you do it for business critical systems. > With the trend as it is at the moment, the endpoint is that Debian will > eventually stop releasing altogether (some end users probably think > this has already happened!) and will essentially become an upstream, > developer-oriented, steadily evolving distribution from which the likes > of Ubuntu take regular snapshots for the masses to use. > Stopping releasing might be a good idea but there should be a better way. IMO the problem is the stable release isn't updated on a regulare basis. It might be a better idea to divide Debian into subsystems which could be released much faster when needed. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net
Re: New stable version after Sarge
On Tue, 2005-01-04 at 16:17 +0100, Paul van der Vlis wrote: > Martin Schulze schreef: > > Paul van der Vlis wrote: [...] > > At least that's been the case including sarge. Hence, such > > a sentence would not mean anything. > > > >>I can understand something like "Debian releases when it's ready", but > >>many people have to work together. Maybe it's better to say: "a package > >>releases when it's ready, but the deadline for the next Debian release > >>is a fixed date". > > > > What if the installer is broken at that time? > > Normally a broken installer does not come into testing (ehm, I don't > know for sure the installer is a normal package). > > For me, installing was never a big problem. You can use an old installer > and update. And a special installation (e.g. on soft-raid) you can > install first somewhere else and then copy it. No, this not good enough. How many MORE e-mails do you want on both Debian User and Debian Devel? It would hugely magnify the amount. > > What if the buildd network is busted at that time? > > What if n library transitions are in progress at that time? > > What if our archive suite lacks an important improvement which > >is a requirement for being able to maintain the new stable > >release? > > When there is a fixed deadline you can plan such things better to be > ready for the new release. What part of "Volunteers" don't you understand? We can't force ANYONE to do anything at anytime. > > Sure, you could still release, but would you really like to have > > such a release? > > I agree, quality is more important then the release date. So, then if quality is what Debian is all about, why bother proposing a fixed date. We are progressing through stages already, just that to fix everything... well there's that "Volunteers" word again. > >>You will understand that my most important point is security-support. > > > > Oh I forgot: > > > > What if security support for a new release cannot be guaranteed at > >that time? > Same answer. This is only an incremental problem of the whole release staging design, control and planning . Quality and Security are by far Debian MOST important end-user needed features. We provide this by complying with the Debian Social Contract and the Debian Free Software Guide, both of which are the definition of Debian. You should read them. Debian: the Install once and update from there distro. So really why does it matter? If you want a distro that is based on timely releases, there are quite a few out there. The only one I would use is Ubuntu. Being Debian based, there are quite a few things to be said about its quality, "perfect" is not one, "way ahead of most others" IS one. But, still they demand a 6 month release schedule. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: New stable version after Sarge
[Jan Niehusmann] > Unfortunately, testing does not guarantee security updates. Sure, > one day the updates will promote from unstable to testing. But this > can take a long time, if, for example, some dependencies block the > new version from testing. > > This may change with a testing-security upload queue. Yes. The testing security team might help here too. https://alioth.debian.org/projects/secure-testing/>.
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 05:31:26PM +0100, Thomas Jollans wrote: > stuff. If I needed something more production-ready, I'd use testing > because you have (almost) garantee that the software will work and you > will have security updates, too. (But not in the same quality as Unfortunately, testing does not guarantee security updates. Sure, one day the updates will promote from unstable to testing. But this can take a long time, if, for example, some dependencies block the new version from testing. This may change with a testing-security upload queue. Jan
Re: New stable version after Sarge
Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? I can understand something like "Debian releases when it's ready", but many people have to work together. Maybe it's better to say: "a package releases when it's ready, but the deadline for the next Debian release is a fixed date". You will understand that my most important point is security-support. With regards, Paul van der Vlis. Well, you could argue that debian branches are not perfectly named but: "stable" is best if you need *absolute* failsafety for critical jobs "testing" is best if you want a stable system with new(ish) software "unstable" is for everybody who needs the newest software, like me. honestly, I have never had problems (yet) with using sid for day-to-day stuff. If I needed something more production-ready, I'd use testing because you have (almost) garantee that the software will work and you will have security updates, too. (But not in the same quality as "stable", as I understand it. If I needed to run a always-needed very-important server on the internet, I would use "stable". Regards, Thomas Jollans
Re: New stable version after Sarge
On 4 Jan 2005, at 3:45 pm, Steve Greenland wrote: On 04-Jan-05, 07:40 (CST), Paul van der Vlis <[EMAIL PROTECTED]> wrote: One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Which could be seen as a problem by some; but in some ways it's probably the way to go. As far as my own use of Debian goes, almost every machine I install runs testing, and has done for years. There's a level of protection in there thanks to the rules that are in place, and I rather like the incremental improvement approach as opposed to release-based. With the trend as it is at the moment, the endpoint is that Debian will eventually stop releasing altogether (some end users probably think this has already happened!) and will essentially become an upstream, developer-oriented, steadily evolving distribution from which the likes of Ubuntu take regular snapshots for the masses to use. The downside of this is that it will essentially bar Debian systems from being formally supported by independent software vendors, since stable releases are what they depend on. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Re: New stable version after Sarge
On 04-Jan-05, 07:40 (CST), Paul van der Vlis <[EMAIL PROTECTED]> wrote: > One of the biggest disadvantages of Debian for me is the long time it > takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Steve [1] Okay, just in case you don't: http://www.ubuntu.com/, http://www.progeny.com -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: New stable version after Sarge
Martin Schulze schreef: Paul van der Vlis wrote: At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like "Debian releases when it's ready", but many people have to work together. Maybe it's better to say: "a package releases when it's ready, but the deadline for the next Debian release is a fixed date". What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). During the preparation of sarge there was a long time where the installer didn't work as it should have. Go read the archives. What I saw was different: the new super-mega-new-installer was not ready. For me, installing was never a big problem. You can use an old installer and update. And a special installation (e.g. on soft-raid) you can install first somewhere else and then copy it. Installing an old version and upgrading to the current one is completely out of discussion for a release. You can always do that with stable and testing. If you can't install a stable release, it's broken. Or the feature is missing in the installer. (Not to compare this with a failed installation of a super-mega-new piece of hardware that isn't supported by the kernel yet). Some of these hardware is not super-mega-new anymore... What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? When there is a fixed deadline you can plan such things better to be ready for the new release. Go read the archives. All three issues have happened during the last 12 months altough sarge was supposed to "be released in December". Maybe a little bit of planning would help? Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Same answer. Go read the archives. That's something that has delayed the woody release and is delaying the release of sarge. Same answer. With regards, Paul van de Vlis.
Re: New stable version after Sarge
Paul van der Vlis wrote: > >At least that's been the case including sarge. Hence, such > >a sentence would not mean anything. > > > >>I can understand something like "Debian releases when it's ready", but > >>many people have to work together. Maybe it's better to say: "a package > >>releases when it's ready, but the deadline for the next Debian release > >>is a fixed date". > > > >What if the installer is broken at that time? > > Normally a broken installer does not come into testing (ehm, I don't > know for sure the installer is a normal package). During the preparation of sarge there was a long time where the installer didn't work as it should have. Go read the archives. > For me, installing was never a big problem. You can use an old installer > and update. And a special installation (e.g. on soft-raid) you can > install first somewhere else and then copy it. Installing an old version and upgrading to the current one is completely out of discussion for a release. You can always do that with stable and testing. If you can't install a stable release, it's broken. (Not to compare this with a failed installation of a super-mega-new piece of hardware that isn't supported by the kernel yet). > >What if the buildd network is busted at that time? > >What if n library transitions are in progress at that time? > >What if our archive suite lacks an important improvement which > > is a requirement for being able to maintain the new stable > > release? > > When there is a fixed deadline you can plan such things better to be > ready for the new release. Go read the archives. All three issues have happened during the last 12 months altough sarge was supposed to "be released in December". > >Oh I forgot: > > > >What if security support for a new release cannot be guaranteed at > > that time? > > Same answer. Go read the archives. That's something that has delayed the woody release and is delaying the release of sarge. Regards, Joey -- Life is a lot easier when you have someone to share it with. -- Sean Perry Please always Cc to me when replying to me on the lists.
Re: New stable version after Sarge
Martin Schulze schreef: Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? The release date for a Debian release is not set by a calendar but by quality. OK, I understand that. And it's good. At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like "Debian releases when it's ready", but many people have to work together. Maybe it's better to say: "a package releases when it's ready, but the deadline for the next Debian release is a fixed date". What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). For me, installing was never a big problem. You can use an old installer and update. And a special installation (e.g. on soft-raid) you can install first somewhere else and then copy it. What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? When there is a fixed deadline you can plan such things better to be ready for the new release. Sure, you could still release, but would you really like to have such a release? I agree, quality is more important then the release date. You will understand that my most important point is security-support. Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Same answer. With regards, Paul van der Vlis.
Re: New stable version after Sarge
* Christoph Berg: > Re: Paul van der Vlis in <[EMAIL PROTECTED]> >> You will understand that my most important point is security-support. > > ...which Debian provides for its stable distribution at any time, even > if the last stable release was ages ago. Where is the security support for woody's version of Mozilla, Samba and PHP?
Re: New stable version after Sarge
Re: Paul van der Vlis in <[EMAIL PROTECTED]> > You will understand that my most important point is security-support. ...which Debian provides for its stable distribution at any time, even if the last stable release was ages ago. How does a fixed release date help there? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: New stable version after Sarge
Paul van der Vlis wrote: > Hello, > > One of the biggest disadvantages of Debian for me is the long time it > takes for a new stable version. > > What about saying something like: the next stable release comes in the > beginning of 2006? The release date for a Debian release is not set by a calendar but by quality. At least that's been the case including sarge. Hence, such a sentence would not mean anything. > I can understand something like "Debian releases when it's ready", but > many people have to work together. Maybe it's better to say: "a package > releases when it's ready, but the deadline for the next Debian release > is a fixed date". What if the installer is broken at that time? What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? Sure, you could still release, but would you really like to have such a release? > You will understand that my most important point is security-support. Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Regards, Joey -- Life is a lot easier when you have someone to share it with. -- Sean Perry Please always Cc to me when replying to me on the lists.
Re: New stable version after Sarge
On Jan 04, Paul van der Vlis <[EMAIL PROTECTED]> wrote: > What about saying something like: the next stable release comes in the > beginning of 2006? Sure, here it is: "the next stable release comes in the beginning of 2006". Do you feel better now? HTH, HAND. -- ciao, Marco signature.asc Description: Digital signature
New stable version after Sarge
Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? I can understand something like "Debian releases when it's ready", but many people have to work together. Maybe it's better to say: "a package releases when it's ready, but the deadline for the next Debian release is a fixed date". You will understand that my most important point is security-support. With regards, Paul van der Vlis.
