Re: A "progressive" distribution
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 <knghtbrd@debian.org> 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
Reply to: