David Z Maze <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: >> I agree. I think stable should be able to get more fixes and updates >> than just security fixes. It's well known that much of the software in >> stable is quite buggy and years behind the upstream source (Mozilla M18, >> for example) but cannot be fixed until a security hole is found in that >> software. I think regular points releases, every month or two, >> containing new software and updates to older software, would be great. >> No major changes would be permitted of course, but there's no reason >> most desktop software couldn't be updated in stable. > > This came up on debian-devel not too long ago. Someone proposed a > "point release" to woody that would have gcc-3.1, GNOME 2.0, new KDE, > and "no major changes to the distribution" -- even though this would > require recompiling everything with a relatively untested compiler, > and presenting a relatively untested desktop environment to new > users. Sure, it's good PR to have a "release" with ooh-new-and-shiny > components, but it's less clear that it'll actually *work*, which > should be the point.
I saw that post, but I didn't think it was well thought-out. > (There's also the problem that each of the developers has their own > personal pet packages that they'd really like to make the "point > release", but it can't happen for everyone's packages, and someone > needs to make the decision. Hypothetically, to pick one of my > packages, there could be a new lm-sensors release. I say, "it's > important because it supports 17 new temperature sensor chips!" But, > it includes libsensors2, which replaces libsensors1 and affects three > or four other packages; is it a "major change" or not?) I would define a major change to be something like the jump to gcc-3.1 or a libc6 version change, ie. something the affects nearly everything in the archive. I wouldn't consider a library that affects 3 or 4 other packages a major change. Why not just have point releases work in a similar manner to the testing->stable procedure, but on a smaller scale? For example, a new testing pool based on the stable pool (called proposed-updates or whatever) could be opened for a month or so, during which updates and new packages could be uploaded. After a month it could be frozen, and then for the next 2 months bugs could be worked out. If something like the upgrade to libsensors2 broke too many things, it could be backed out. Then, after 3 months (theoretically, of course), a point release with newer packages could be available. -- Brian Nelson <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
