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