On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote: > Well say that there are 3 releases a year. That gives say 3 months for > devel. With a freeze scheduled to start at the beginning of the 4th > month and a stable release at the end of a month of freeze. I think > that even the most drastic changes can be worked out in the course of 4 > months. Now if something _can't_ be completed in that time frame just > postpone it until the next freeze. Since the next stable would only be > 4 months off the penalty for not making it into the stable isn't that > severe.
I hate to be overly harsh, but you I haven't seen around much before this thread. As such, I'm going to assume that you haven't been around very long as far as following this list. Anybody who has been around awhile can tell you that people just like you (and even a large segment of the existing developer base) says every single release that we need to freeze sooner and release more often---however pools will only complicate things and make it harder. Well uh, here's where the above "you don't know what you're talking about yet because you're still new" angle comes in... We've tried it. We tried it with hamm, slink, and now with potato. Freeze as soon as someone thinks it can be released in a few weeks DOES NOT mean it can be done in a few weeks. Freeze early doesn't mean a sooner release, it just means a more stale release faster. The pool solution is more complex. It requires that we constantly maintain two trees, plus a pool of unstable packages that just never really get released as a whole. A package does not become a release candidate until it's ready to become so. Sure that means more overhead on a package to determine whether or not it is going to be released. It also makes it harder for Debian to ship with every single piece of free software that doesn't guaranteed pull the system down to its knees. It also means per developerer there is more time required to maintain ones packages properly (though I would argue that unless your name is Joey Hess the extra time required is not terribly significant.) What does this gain us though? For all these disadvantages, what's it really worth? A distribution that is maintained in the near-release state that we CAN simply release any time we feel it is necessary. It's also easier to update than the current system which involves releasing security revisions to stable. Not only this but it is easier to make upgrades because they would happen more often and be more upgrade than the current complete new OS scenerio. We're running out of options because freeze early doesn't work. The other two options are the dist and a half (which was done for slink by Joey Hess and Shaleh.) As it turns out, the pools system allows us to have more of a real upgrade. The dist and a half system allows us to have a more focused upgrade. Which is more beneficial to our users? Both can be done in a matter of a couple of weeks. Both are actual versioned releases. The pools have more overhead, but they provide a real upgrade rather than just the dist with a few big notables like kernel, X, and Apache. IMO, dist and a half is mostly fluff as far as press releases go. potato and a half would be a potato dist with a 2.4 kernel, possibly some new X stuff if it can be done and a new apache. It's still out of date potato otherwise. I want a REAL upgrade! > With only the 3 months of changes I don't think that a freeze will take > as long as it has with a 6 or even 12 month devel cycle. As I said, you haven't been around much yet have you? -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 First off - Quake is simply incredible. It lets you repeatedly kill your boss in the office without being arrested. :) -- Signal 11, in a slashdot comment