75 messages in org.freebsd.freebsd-hackersRe: The -stable problem: my view| From | Sent On | Attachments |
|---|---|---|
| Greg Lehey | Jun 7, 1996 3:15 am | |
| Jordan K. Hubbard | Jun 7, 1996 6:29 am | |
| Nate Williams | Jun 7, 1996 8:29 am | |
| Karl Denninger, MCSNet | Jun 7, 1996 8:41 am | |
| Nate Williams | Jun 7, 1996 10:02 am | |
| Terry Lambert | Jun 7, 1996 11:22 am | |
| Angelo Turetta | Jun 7, 1996 11:48 am | |
| Marc G. Fournier | Jun 7, 1996 12:05 pm | |
| Nate Williams | Jun 7, 1996 12:53 pm | |
| Terry Lambert | Jun 7, 1996 12:53 pm | |
| Nate Williams | Jun 7, 1996 1:07 pm | |
| Terry Lambert | Jun 7, 1996 2:12 pm | |
| Nate Williams | Jun 7, 1996 2:26 pm | |
| Terry Lambert | Jun 7, 1996 2:58 pm | |
| Nate Williams | Jun 7, 1996 3:07 pm | |
| Terry Lambert | Jun 7, 1996 3:15 pm | |
| Nate Williams | Jun 7, 1996 3:24 pm | |
| Jordan K. Hubbard | Jun 7, 1996 4:00 pm | |
| Nate Williams | Jun 7, 1996 4:06 pm | |
| Jordan K. Hubbard | Jun 7, 1996 4:27 pm | |
| Jordan K. Hubbard | Jun 7, 1996 4:40 pm | |
| Terry Lambert | Jun 7, 1996 4:42 pm | |
| Jordan K. Hubbard | Jun 7, 1996 4:56 pm | |
| Justin T. Gibbs | Jun 7, 1996 5:35 pm | |
| Jordan K. Hubbard | Jun 7, 1996 5:59 pm | |
| Jordan K. Hubbard | Jun 7, 1996 6:07 pm | |
| Nate Williams | Jun 7, 1996 6:13 pm | |
| Scott Blachowicz | Jun 7, 1996 7:03 pm | |
| Michael Hancock | Jun 7, 1996 7:08 pm | |
| Nate Williams | Jun 7, 1996 7:21 pm | |
| Michael Hancock | Jun 7, 1996 7:25 pm | |
| Michael Hancock | Jun 7, 1996 7:30 pm | |
| David Greenman | Jun 7, 1996 9:06 pm | |
| Nate Williams | Jun 7, 1996 9:07 pm | |
| Terry Lambert | Jun 7, 1996 9:10 pm | |
| Nate Williams | Jun 7, 1996 9:18 pm | |
| Terry Lambert | Jun 7, 1996 9:39 pm | |
| Terry Lambert | Jun 7, 1996 9:58 pm | |
| Jordan K. Hubbard | Jun 7, 1996 10:13 pm | |
| Jordan K. Hubbard | Jun 7, 1996 10:24 pm | |
| Terry Lambert | Jun 7, 1996 10:24 pm | |
| Nate Williams | Jun 7, 1996 10:26 pm | |
| Jordan K. Hubbard | Jun 7, 1996 10:33 pm | |
| Nate Williams | Jun 7, 1996 10:34 pm | |
| David Greenman | Jun 7, 1996 10:40 pm | |
| Terry Lambert | Jun 7, 1996 11:03 pm | |
| John Birrell | Jun 7, 1996 11:18 pm | |
| Justin T. Gibbs | Jun 7, 1996 11:22 pm | |
| Rodney W. Grimes | Jun 8, 1996 1:24 am | |
| Jordan K. Hubbard | Jun 8, 1996 2:28 am | |
| Narvi | Jun 8, 1996 2:33 am | |
| Narvi | Jun 8, 1996 2:53 am | |
| Narvi | Jun 8, 1996 3:05 am | |
| Heiko Blume | Jun 8, 1996 4:29 am | |
| Michael Hancock | Jun 8, 1996 8:22 am | |
| Garrett Wollman | Jun 8, 1996 11:18 am | |
| Justin T. Gibbs | Jun 8, 1996 1:52 pm | |
| M.R.Murphy | Jun 8, 1996 2:10 pm | |
| Terry Lambert | Jun 8, 1996 2:52 pm | |
| M.R.Murphy | Jun 8, 1996 3:40 pm | |
| Jordan K. Hubbard | Jun 8, 1996 4:08 pm | |
| Julian H. Stacey | Jun 9, 1996 3:54 am | |
| Randy Terbush | Jun 9, 1996 7:21 am | |
| Bob Willcox | Jun 9, 1996 7:54 am | |
| Chuck Robey | Jun 9, 1996 8:34 am | |
| Randy Terbush | Jun 9, 1996 8:40 am | |
| Ollivier Robert | Jun 9, 1996 12:56 pm | |
| Bob Willcox | Jun 9, 1996 2:32 pm | |
| Andrew V. Stesin | Jun 10, 1996 1:45 am | |
| Narvi | Jun 10, 1996 6:54 am | |
| Andrew V. Stesin | Jun 10, 1996 7:40 am | |
| Narvi | Jun 10, 1996 8:48 am | |
| Michael Robinson | Jun 14, 1996 2:38 am | |
| Amancio Hasty | Jun 14, 1996 3:00 am | |
| Terry Lambert | Jun 17, 1996 11:32 am |
| Subject: | Re: The -stable problem: my view | |
|---|---|---|
| From: | Marc G. Fournier (scra...@ki.net) | |
| Date: | Jun 7, 1996 12:05:12 pm | |
| List: | org.freebsd.freebsd-hackers | |
On Fri, 7 Jun 1996, Karl Denninger, MCSNet wrote:
If STABLE goes away, and I cannot get a known-to-build-and-run version at a given point in time, FreeBSD goes away here.
-RELEASE is 'known-to-build-and-run'...and, I believe, so are -SNAPs, so you build all yuor machines with -RELEASE, and if you feel you need to upgrade, through -SNAP on one of your machines, run it for a week so that you are confident with it, and then upgrade the rest of your machines. I believe you do have several PCs running FreeBSD now, don't you?
I don't have a full-time engineer at present to devote to this, nor can I afford the single mistake that destroys our environment. I can put someone on this with a 4-10 hour per week commitment, but that's about it.
Sounds like the time to get a -SNAP installed...
Somehow, the -STABLE intent must remain. I don't care *how* it is accomplished, but it has to be accomplished. An example of the problems is the difficulty in running nntplink on -STABLE; sometime a couple of months ago something in the select() call broke, has not been fixed, and nntplink won't run any longer (and yes, we have been asking infrequently and did report this when it happened). This means that one particular machine that could *really* use the recent VM fixes can't have them, because if I load that kernel on our main news system it stops talking to anyone.
*scratch head* if something in the select() call broke several months ago (and I *am* running -STABLE and -CURRENT machines), why wouldn't it affect everything that uses select()? I've been using innfeed here (much better then nntplink, IMHO) for the past month or so with absolutely no problems, or, no problems related to select()
2. -current goes through periods of greater and less stability. It's not practical for somebody who wants to run a stable system to track -current. On the other hand, the more stable periods of -current work very well.
Correct as well.
Not *really* correct...that is what the -SNAPs are for...someone (Jordan?) determines that the *current* state of -current is stable enough to package as an install kit...similar to how someday, someone will decide that 2.2 is ready for release.
Or, better yet, -current *is* 2.2 and the SNAPs are 2.2.x, and
What we need are shorter branches: say, we start a -stable branch at a point on the -current branch where things are relatively stable. Then we update it with bug fixes only for a relatively short period (say 4 to 8 weeks). *Then we ditch it and start again at a new point on the -current tree*. These branches could be called things like 2.2.1-stable, 2.2.2-stable, etc. Like this, we could have our relative stability while keeping the -stable branches more up to date.
This will work if it is *clearly* documented when and if these things happen, and what you can (and cannot) keep at a given time (ie: if I must reload all the shared libraries then that effectively requires that I dump the machine and reload; this is a MAJOR problem if you're trying to track incremental improvements).
Again, isn't this what Jordan is doing with his -SNAPs...stating that at this point in time, it is felt that -current has proven to be stable enough to make an install kit out of?