> Guy> I'm in favor of much more rapid revisions. > > Seconded. > > Rapid, and transparent, revisions are actually an advantage. People just > have to understand that it is better for them to get a CD covering several > hundred MB _and_ being able to semiautomatically upgrade the few newer files > from a Website. Anytime they want. They can always be current. Even a book > vendor could press that on the title. Just so everybody thinks about this a bit more - I'll disagree (sortof). Point releases should just be for security fixes and critical bugs - and nothing more. They should be small, and infrequent. The whole Linux development model (see Eric Raymond's "The Cathedral and the Bazaar") is an extremely effective model for rapidly evolving or growing a system. The effect of this is that there are relatively few really serious bugs, but lots of little ones. Unfortunately, small bugs tend to interact in any system - so their effect becomes quite magnified. This is why our 'unstable' distribution, which changes daily, lives up to it's name. Every once in a while, something gets upgraded, which affects something else -- and WHAMMO! -- you're system gets flattened. That's OK for us, since we're developers and we can take it. Plus it's a part of the whole debugging process. Since we don't want to expose our users to that (or our own production systems) - we have a 'stable' distribution. We spend months testing it to make sure there aren't any major glitches in it. The result is that we get the best of both worlds - few really serious bugs + most of the small systematic ones are worked out too. Fred Brooks, in the "Mythical Man-Month" writes: Lehman and Belady offer evidence that quanta should be very large and widely spaced or else very small and frequent. The latter strategy is more subject to instability, according to their model. My experience confirms it: I would never risk that strategy in practice. Well, he wrote that in 1975, but I think it applies very well to the Linux model of development. If you run the 'unstable' distribution, (or even worse, are using the latest 2.1.x kernels) -- the "quanta" (releases) will be never small and frequent. This tends to maximize the evolutionary growth of the software. However, the developers will pay the price in terms of instability of their development platform. On the other hand, the 'stable' distribution has "quanta" that are large and widely spaced. We only make a major release every 4 to 6 months. Each release is reasonably well tested and known to work together - so it is in fact stable. This is a good thing. :-) It's important to realize that we are still quite a small organization, and we don't have that many actual testers. Most of the bug reports are generated by the developers (200 of us) most of whom are running the unstable distribution (with over 1000 packages). The packages that are introduced into the 'stable' minor releases do not have to run the gauntlet of testing that happens to packages that were introduced into 'unstable' first, and only became a part of 'stable' at the time of a major release. A package that is tested in 'unstable' isn't being tested against the same packages that it would be living with when it is introduced into 'stable' via a minor 1.3.x release. There are probably very few people running (and testing) 'bo + bo-updates'. So we should avoid putting things into bo-updates as much as possible. So I think it's best to expose the users of 'stable' to as few minor releases as possible (with very few packages in each). We should save our "good stuff" for the major releases. Of course, security fixes are a must - those can't wait for a major release. And there may be some packages that are so broken that it's better to fix them. How about this - let's do releases like this: 1.3 - major release 1.3.x - minor releases with critical security bugs fixed (stable users should upgrade) 1.3.x.y - minor releases with minor bug fixes and adjustments (primarily to fix up screw-ups in minor releases) Of course, we can't control when critical security bugs will pop up, but I'd like to see the number of 1.3.x releases limited to 3-4 between major releases. We should avoid 1.3.x.y releases - except when we screw-up and making another minor release would be too embarrassing. Adding xfree86 3.3 into the release to fix security bugs was certainly worthy of a 1.3.1 release. It was a big change. There is now so much stuff in bo-updates that it is probably worth making a 1.3.2 release. Frankly, it looks like there's an awful lot more there than necessary - but that might be a function of how we did our testing prior to the 1.3 major release. (I've got some simple ideas that could really help us out next time) We should space the minor releases (1.3.x) far enough apart so that any one time, most of the stable users have a clue what the current version is. Minor version numbers shouldn't be too much of a problem to CD vendors and book sellers - the actual difference between Linux 2.0.23 and Linux 2.0.30 isn't that great - so they would just refer to it as Linux 2.0 or Linux 2.0.x. The same thing would probably work for them when they are selling Debian CD's. (my apologies for the length of this diatribe) Cheers, - Jim
Attachment:
pgpzEeb6Q6pP1.pgp
Description: PGP signature