I've been trying to stay out of this discussion for the most part, but their are a few points that either aren't being brought up or need to be repeated. Since Ian's post is the most current and touches on everything I want to say, I'll pick on it. :-)
> Clearly we need both a `stable' and an `experimental' system. That seems to be what I'm hearing. > However, bugs in the `stable' system will continue to be found, and > will have to be fixed. We must therefore not cast the `stable' system > in stone. > > We should therefore make the stable vs. experimental distinction on a > per-package level too. > > Packages should initially be released into the experimental system, > and then when the particular version has proved stable we can move it > into the stable system. > > This will not, of course, deal with interdependencies between > different versions of different packages. However, that problem can't > be solved by snapshotting the release, either: a snapshot would simply > have all the bugs that were present at a particular time. > > We should deal with version dependencies by having package maintainers > think carefully about interrelationships before asking for a version > to be moved into the stable tree. I don't think there is any way we > can arrange for this problem to solve itself: we will have to put > thought into these issues every time they occur. How many of you have done release management? The classic way I've always done it is to freeze features, test it, fix bugs, test it again and then release it. After it's released, the only changes you make are to fix serious bugs. That means absolutely NO NEW FEATURES are introduced into the released version except under extreme circumstances. That also means that some bugs go unfixed until the next release. All new features go into the working, development version for inclusion with the next release. In our case, we are very close (I hope) to the initial release. After we release, we need to use restraint (something we have yet to master) and only fix bugs in the released versions of packages. All other changes go into the working, development versions only. Now, I know our cause is complicated by the fact that we are largely dependent on upstream packages that don't always come in nice, clean, bug-fix versions, but we need to at least try to stick to only fixing bugs. > The worst disadvantage is that neither would be suitable for use - the > frozen tree would be full of bugs that were fixed in the updates > tree, and the updates tree would be full of broken packages with good > versions in the stable tree. This is why you try to restrict yourself to only fixing bugs in the released version -- you minimize the risk of introducing new bugs with new features. BTW, most reasonable customers/users can accept minor bugs, especially if they are documented with suggested work-arounds. It is only the serious bugs which need to fixed immediately. > I was under the impression that debian-0.93 (aka debian-current) was > going to be the stable copy, and that debian-1.0 was going to be the > experimental version (which would presumably start out with a.out > versions of everything and gradually move to ELF). > > Perhaps we need three trees, a stable a.out, an experimental a.out > and an ELF ? I really only see a need for two trees -- one stable a.out and one experimental ELF. IMO, the experimental a.out tree should only be a short-term repository for bug fixes to be checked out by developers or beta testers before going into the stable tree. BTW, I've been very patient and tried not to complain about how long this a.out release is taking. However, has anyone else noticed that Debian is now the only major Linux distribution that has not converted to ELF? I haven't seen it publicized much, but even Linus has switched to ELF! > We have a very powerful modular approach to system integration - let's > not throw that out of the window by insisting on arbitrary flag days > and snapshots and the like. I think it's great that Debian can be upgraded incrementally and frequently. In fact, it's one of the reasons I switched to Debian as I like staying close to the bleeding edge. However, I'm hearing that there are a good number of users who don't want to keep checking for new packages every day or week. They only want to upgrade everything at infrequent intervals, say every 3 to 6 months. I think we can satisfy both classes of users. David -- David Engel Optical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
