Re: A "progressive" distribution
Jacob Kuntz wrote:
> the production branch should always work. a system could be put in place
> where you could always get an iso image of the production branch that is
> recent to within a few days. i imagine that we would need to get pools in
> place before we could even attempt this. this type of system could probably
> work along side of whatever else we decide to to about release cycles.
This "production" branch presents a few problems to package maintainers
unless some extra procedure is detailed. If the packages are being
constantly updated, and a library (a dependency of package "foo", which
I package) is changed so that it is no longer link-compatable with "foo",
I have to rebuild and upload "foo." While this would not normally be
a problem, say I'm working on "foo2" in the "devel" branch. With
Debian's current "stable" / "unstable", I only have to worry about building
packages against "unstable" (while I'm adding more features, fixing
bugs, etc.). With "production" / "devel", I would need to track two
branches. As it is now, I can pretty much leave "foo" in "stable" and
not touch it (unless someone discovers security problems, etc.).
This message wasn't really intended as a critique of your idea,
Jacob. Rather, I wanted to take a little time to ask the Debian community
to pay attention to what the FreeBSD guys do with their distributions.
Please don't immitate FreeBSD's release practices.
The FreeBSD guys tag a release "RELEASE" when they feel it's ready for
lots of people to download, compile, and use. The "RELEASE" branch
is usually of very high quality, but like all software, it has problems.
Instead of continually releasing new "RELEASE" branches, they have a
"CURRENT" branch of their distribution. This branch is the "RELEASE"
branch plus fixes to things that had problems in the original release.
So far, this plan works very well.
Now comes the tricky part. FreeBSD offers a "STABLE" branch which is
usually anything BUT stable. I followed this branch on two machines
(just a few months ago), and I was subscribed to the "STABLE" mailing
lists. "STABLE" is similar to what Jacob calls "production". The
FreeBSD handbook (at http://www.freebsd.org/handbook/stable.html):
If you are a commercial user or someone who puts maximum stability
of their FreeBSD system before all other concerns, you should consider
tracking stable. This is especially true if you have installed the
most recent release (3.4-RELEASE at the time of this writing) since
the stable branch is effectively a bug-fix stream relative to the
previous release.
"STABLE" breaks just about every day (a cvsup to their source trees and
a "make world" will fail). Sometimes you can build a kernel that
does very odd things (a friend of mine built a "STABLE" kernel off the
recent RELENG3 tree, and the first time his machines would run out of
RAM, they would handle the situation (killing the offending process),
but the second time, it refused to allow any more malloc() until the
kernel gave out). Of course one could choose to not continually
update and build from the "STABLE" tree, but then what's the use of
having updated code?
Picking on FreeBSD's kernel probably isn't the best way to make
a point about Debian's packaging policies, so here's my simple
suggestion:
Keep the "stable" and "unstable" (with the "frozen" step towards
releases), but release more often. A year between releases is
very painful, when I need to install somewhat recent software on
a new host. Maybe double the release rate (aim for once every 6 months)?
--
Shaw Terwilliger
Reply to: