Date: Sun, 5 Nov 1995 04:00:25 -0600 From: rkw@dataplex.net (Richard Wackerbarth) To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@freefall.FreeBSD.org Subject: Re: 2.1.0-951104-SNAP is now available. Message-ID: <v02130501acc226ec20f9@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
At 12:13 AM 11/5/95, Jordan K. Hubbard wrote: >As part of my ongoing efforts [...] >8. Because I felt like it. The very best reason of all :-) >What still remains to be done for 2.1-RELEASE: > >1. I need to bring the new commerce distribution (which is now completed) > off my own machine and into the release distribution. This SNAP still > points to the 2.0.5 commercial dist. I'll probably also add a submenu > for the commercial distributions so that you don't have to load all of > the commercial demos to get just one of them. > >2. Unless I get substantial input on this in the next couple of days, the > "experimental" distribution will remain unchanged for 2.1. I got a > grand total of zero contributions for this in response to my last > solicitation for such contributions, so I guess there aren't any new > experimental bits! I may put a compressed copy of the 2.2-CURRENT > source tree on the CD for the Bold Adventurers among us, but that's > still under consideration. As unstable as -current has been, I would be inclined to discourage it. If it were to be there, I would suggest that as a minimum, you can do a "make world" for the system and boot the resulting system. >3. Any other truly critical things people may point out to me in the next > few days (hopefully none). We need to make a decision about support for this Release. In particular, I would like to suggest that an appropriate means of supporting patches would be CTM. Rather than encouraging users to poll the central site for changes, we would be able to have a mailing list to which the changes get automatically distributed. I bring this up now because such a service shuold be documented on the CD if it is going to exist. Collectively, we do have the resources to generate it, even if there is "no room at the inn" on freefall, etc. I'm sure that either Poul or Mark will soon get around to helping me set up the generation of the updates at either my site or in South Africa. _*_*_*_ Soapbox _*_*_*_ While I am on the topic of Release support. I suggest that the support for -stable be dropped. In its place, I look for support for FreeBSD 2.1. By avoiding designations that suddenly change out from under everyone, the transition is much cleaner. IMHO, only the development tree is an ongoing evolution. (And -current is a poor name for it.) I would suggest that if you are going to use -stable, -current, etc. labels, that the -current label might best describe the release under development/testing/shakeout. Thus... The "stable" release is one that is rock solid, but still supported. The "current" release is one that is somewhere in its evolution between "alpha" and post-"release". There might be times that "current" and "stable" are the same because the latest release is so good that it is declared stable, but the next release is not yet ready for release testing. If you concur with this naming approach, one way to get there is to cause the next split to carry the "bleeding edge" developers off the -current branch and into the -future, -development, -experimental, or whatever branch thus leaving -current to become a real release tree. _*_*_*_*_ Stepping down _*_*_*_*_ ---- Richard Wackerbarth rkw@dataplex.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02130501acc226ec20f9>