Date: Sun, 17 Sep 1995 13:35:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: paul@FreeBSD.ORG Cc: jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@root.com, current@FreeBSD.ORG Subject: Re: Which SUP files are available and where ? Message-ID: <199509172035.NAA06633@phaeton.artisoft.com> In-Reply-To: <199509171844.TAA04538@server.netcraft.co.uk> from "Paul Richards" at Sep 17, 95 07:44:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
After a release based on a "stable" branch, all patches should be applied to the next release, not to the stable branch post-release. The only exception to this should be a rerelease of the stable branch to correct a gross error in usability (install, etc.). That would bump the minor rev to 2.1.1 (for instance) and is only likely to be done in the first little while after the release (perhaps as a way of tracking release candidates?). The point being that once it is on CDROM, any subsequent changes should go into a different branch tag and the branch tag of the RELEASE frozen. Period. It's *got* to be possible to recover the CDROM image from the CVS tree. After a release there is no "ongoing maintenance" only "new release work". This has to be true because the work that went into making the "stable" branch "stable" in the first place can not be duplicated in the rolling in of a quick patch. By doing ongoing maintenance without equivalently long cycle times, you compromise the meaning of the "stable" tag. > > That sounds OK in theory, but it both assumes that 2.2 is going to be > > ready in a timeframe congruent with when people are expecting "their > > bugs to be fixed" and that those bugs *will* be fixed in 2.2. Well, you can either have a test release or you can have untested code that probably fixes your bugs. Depending on how long you take to complain about a bug after a release, then you may have to accept some destabilizing patches along with the path that fixes your bug, even though they are not logically related ares because of patch overlap (this is incidently why the original patchkit had to centralize patch ordering: to ensure ordered overlap in patches. The current CVS tree enforces this in a much more automatic way, but you are crazy if you think it isn't enforced somewhere). > > I see experimental changes > > going into there for awhile yet, and that doesn't translate to the > > kind of "incrementally debugged" release that 2.1.1 would represent. What's an "experimental change"? Either the experiment fails (and it is removed) or the experiment succeeds (and it becomes part of the main line code). You can't keep an experimental label on something in the main line source tree, only in your personal source tree. This isn't to say that you don't have the ability to use the code revision mechanisms, especially if you are hacing on a tree-accessable machine, by tagging the tree and then working on your own branch. Just that your branch will not be the main line code until you prove your changes. > Who's going to be maintaing 2.1? There may well be a long list of > bugs that have surfaced in 2.1 but you're going to have to sit down > and work out solutions for most of them independantly of current since > it's almost always the case that the bugs we find these days are > conceptual problems that are fixed by completely redesigning portions of > the system. It's certainly never been easy in the past to retrofit fixes > in current to older releases for this very reason. Definitely agree. > 2 releases a year is probably enough. People just don't want to upgrade > much more often than that. 6 months should be more than enough time > to get all but the most uncommon bugs out of a release. The problem has > always been in the past that no-one is willing to clamp down on current > and if people are stilling adding experimental code in 3-5 moths then > it'll never converge to a stable state. Definitely disagree. The quarterly schedule was much more ambitious, but results in a much better pay-off. This was preterbed by the large Net/2 to BSD 4.4-Lite transition problems, but those problems are in the past and there's no reason to not resume quarterly releases. > If we could stick to a 6 month release cycle then there'd be no need for > a 2.1.1 release, and if the 6 months is used to properly test the next > release then there wouldn't be the continual screw-ups that require > point release days after the cdrom ships. As long as the actual task of > cutting the cdrom doesn't introduce any bugs then I doubt that 2.1 will have > any serious bugs that *require* a point release, since this is the first > release in a long time that's had a decent period of testing. If there > are no serious bugs then people can wait 6 months until the next release. I agree that there is probably no need for a 2.1.1, but mostly because of the maintenance issues involve in moving the release base away from a release tag level. I believe that "fixed in the next release" is an adequate answer to any non-fatal bugs. For fatal bugs, the patch can be made, and tested on the problem system *prior* to its inclusion in the source tree. Then it becomes "fixed in the next release" in any case, and people who want it badly enough can do a CVS diff vs. tags before and after the integration to get the changes. > Would a 2.1.1 release go through the same vigourous testing as 2.1 did, > if not I wouldn't consider it an upgrade. Defintely the problem with doing this sort of post-release backpedalling. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509172035.NAA06633>