Re: Staying *really stable* in FreeBSD
This looks really good! Ship that baby! :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Staying *really stable* in FreeBSD
On Wed, Jun 27, 2001 at 13:13 -0600, Mike Porter wrote: > On Wednesday 27 June 2001 09:44, Bill Moran wrote: > > > > Is there a reason why you took this off the list? > > my mistake (or my mailer's depending on how you look at it). > If the majordomo config file for the list included the line > "reply-to: [EMAIL PROTECTED]" then all replies would by > defualt go back to the list. While this isn't ALWAYS > appropriate, it usually is Argh, no! Not again, please! Just do *one* search for "reply-to" and "harmful" in your favourite search engine and make sure you understand what's broken about this dumb down approach. This has been discussed recently (besides coming up again and again without getting any better by doing so). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Whence Stallion support for -Stable?
[Cc'd to stable and bugs. Please reply to bugs only] The driver for Stallion multiport cards in 4-Stable is quite old. It doesn't support many of the newer cards, in particular the EasyIO-PCI card, nor any card manufactured since about 1998, which have a newer and unsupported UART chip. The driver in -Current is much the same with a few current-isms, afaict. There is a newer driver in the unsupported section of the stallion FTP site: ftp://ftp.stallion.com/drivers/unsupported/FreeBSD/stalbsd-2.0.0.tar.gz This supports all the new hardware but seems to be written for old (3.x-vintage) kernels, because it doesn't go anywhere near compiling under 4-Stable. There is a PR (http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22967) submitted by Jan L. Peterson <[EMAIL PROTECTED]> which gives a new version of the above driver that does compile with 4-Stable, and seems to operate as expected (tho I haven't explored all the corner cases with flow control, modem control etc). But this PR is less than ideal. It contains a link to the new driver (fortunately still valid!) rather than the data itself, it requires bits from the original Stallion tarball, and doesn't update MAKEDEV or man pages. And the driver was written for 4.1.1 and will need updating for a few things that have changed since then (kqueue). It also "is using old-style compatibility shims" (whatever that means). This PR has been untouched since it was submitted 12 months ago. A related PR from the same period (http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19890) has been assigned to davidn but also remains otherwise untouched. I am willing (and I hope able!) to provide a jumbo patch to tie all these pieces together and update this driver in a manner that should be easy for a comitter to commit to -Stable. But I am running -Stable only, and have no experience in porting device drivers to -Current, and cannot test this driver in -Current. Is it worth me putting together such a comprehensive patch, or will the need to run it in -Current first mean my effort would be wasted? Any device writer / committer gurus care to offer some guidance? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildkernel and conventional kernel build fail
Paul <[EMAIL PROTECTED]> writes: > Is anyone else experiencing this problem? On two separate machines now, > cvsup'd to -STABLE, I get the following error when trying to compile. > Doesn't matter if it's GENERIC, or my customer kernel... i get the same > thing either way: Have you done a buildworld? Did it succeed? > > cc -c -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys > -I/usr/src/sys/../include -I/usr/src/sys/contrib/ipfilter -D_KERNEL > -include opt_global.h -elf -mpreferred-stack-boundary=2 > -fomit-frame-pointer /usr/src/sys/i386/i386/atomic.c > In file included from /usr/src/sys/i386/i386/atomic.c:47: > machine/atomic.h: In function `atomic_set_char': > machine/atomic.h:106: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_clear_char': > machine/atomic.h:107: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_add_char': > machine/atomic.h:108: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_subtract_char': > machine/atomic.h:109: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_set_short': > machine/atomic.h:111: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_clear_short': > machine/atomic.h:112: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_add_short': > machine/atomic.h:113: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_subtract_short': > machine/atomic.h:114: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_set_int': > machine/atomic.h:116: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_clear_int': > machine/atomic.h:117: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_add_int': > machine/atomic.h:118: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_subtract_int': > machine/atomic.h:119: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_set_long': > machine/atomic.h:121: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_clear_long': > machine/atomic.h:122: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_add_long': > machine/atomic.h:123: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_subtract_long': > machine/atomic.h:124: inconsistent operand constraints in an `asm' > *** Error code 1 > --snip-- > > I have tried with and without -march=pentiumpro, with and without > optimizations... am I alone here? > > Regards, > Paul > <[EMAIL PROTECTED]> > http://www.tribble.net/ > > "Supreme Court says pornography is anything without artistic merit that > causes sexual thought, that's their definition, essentially. No artistic > merit, causes sexual thought. Hmm. Sounds like... every commercial on > television, doesn't it?" -- Bill Hicks > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
make buildkernel and conventional kernel build fail
Is anyone else experiencing this problem? On two separate machines now, cvsup'd to -STABLE, I get the following error when trying to compile. Doesn't matter if it's GENERIC, or my customer kernel... i get the same thing either way: cc -c -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer /usr/src/sys/i386/i386/atomic.c In file included from /usr/src/sys/i386/i386/atomic.c:47: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:106: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_char': machine/atomic.h:107: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_char': machine/atomic.h:108: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_char': machine/atomic.h:109: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_short': machine/atomic.h:111: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_short': machine/atomic.h:112: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_short': machine/atomic.h:113: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_short': machine/atomic.h:114: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_int': machine/atomic.h:116: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_int': machine/atomic.h:117: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_int': machine/atomic.h:118: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_int': machine/atomic.h:119: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_long': machine/atomic.h:121: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_long': machine/atomic.h:122: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_long': machine/atomic.h:123: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_long': machine/atomic.h:124: inconsistent operand constraints in an `asm' *** Error code 1 --snip-- I have tried with and without -march=pentiumpro, with and without optimizations... am I alone here? Regards, Paul <[EMAIL PROTECTED]> http://www.tribble.net/ "Supreme Court says pornography is anything without artistic merit that causes sexual thought, that's their definition, essentially. No artistic merit, causes sexual thought. Hmm. Sounds like... every commercial on television, doesn't it?" -- Bill Hicks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Undesirable behaviour of burncd erase
Hi all, but particularly Soren, I run FreeBSD 4.3-STABLE #5: Sat Jun 16 11:45:32 EST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GURNEY on a CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x387f9ff real memory = 134152192 (131008K bytes) avail memory = 126504960 (123540K bytes). Yesterday, I replaced my ordinary ATAPI Diamond Data CD player with one of these: acd0: CD-RW at ata1-slave using UDMA33 The other disks are masters on each of the two ATA controllers: ad0: 6149MB [13328/15/63] at ata0-master UDMA33 ad1: 6149MB [13328/15/63] at ata1-master UDMA33 After producing a non-working CD with burncd, probably because of the ill-advised placement of a "data" file, I tried to erase the CD-RW disk before trying again. So I did something like: burncd -e -f /dev/acd0c erase Over the next few seconds my X session locked-up hard, apart from the mouse, which could still move. I was also unable to connect to the box over my LAN, using ssh. Since the CD erase operation still seemed to be happening, I decided to just let it go for a while, to see if that would stop. Sure enough, many minutes later (I didn't time it), the disk ejected itself, and my X session restarted itself, probably because I had been madly pressing ctrl-alt-backspace while things were locked up. So the system did not actually crash at all, but it became unuseful for a very long time. Afterwards, the logs and the console were seen to contain these messages: > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 7936, size: 36864 > swap_pager: indefinite wait buffer: device: #ad/0x30009, blkno: 47904, size: 4096 > swap_
RE: Staying *really stable* in FreeBSD
On Wednesday, June 27, 2001 5:30 PM, Juha Saarinen [SMTP:[EMAIL PROTECTED]] wrote: > On Wed, 27 Jun 2001, Bill Moran wrote: > > > In a company, alpha testing is done by the developers or other > > employees of the company, > > Once Upon A Time this was true, but no longer. Viz. Microsoft's > "Technology Preview" editions of various pieces of software. Due to > lengthening development cycles, companies feel compelled to issue some > pretty raw code into the public eye, just to show that they're actually > doing something. The mindshare game I guess. True, but I guess it still just seems to me that "alpha" is a closed-source kinda word that doesn't fit in with any open-source type of development. Might just be my perception of the whole thing. > Anyway, code never gets out of the beta stage. ;-) I don't know. I mean, "beta" says to me, "we, as developers, can't find any problems, but this hasn't been tested in the real world yet." Whereas a "release" tag says "we've tested this under real world conditions and have not found any problems" I see where you're coming from with that statement, though. Especially open-source development, which is always under scrutiny for the purpose of improvement. > Oh, and could you please wrap your lines? Yeah ... I just realized that the only way to keep Outlook from mangling lines is to manually wrap. I'm working on site this week, far away from my comfortable FreeBSD desktop workstation :-( so I'm stuck with Outlook. I think I'll install mutt on one of the servers here and use it to get my email via ssh ... :-) Don't tell my boss. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Staying *really stable* in FreeBSD
On Wednesday, June 27, 2001 3:14 PM, Mike Porter [SMTP:[EMAIL PROTECTED]] wrote: > On Wednesday 27 June 2001 09:44, Bill Moran wrote: > > Is there a reason why you took this off the list? > > > my mistake (or my mailer's depending on how you look at it). If the > majordomo config file for the list included the line "reply-to: > [EMAIL PROTECTED]" then all replies would by defualt go back to the list. > While this isn't ALWAYS appropriate, it usually is No problem. I expected as such ... looking back, I had intended that question to mean "Should I not be posting to -STABLE" but then I *did* post to -STABLE so it was pretty silly to bring it up at all ... > I agree, but I think that putting things in terms people can understand is > also important, and mentioning something along the lines of the above > paragraph might help some people better undrstand the relationship between > -current, -stable, and -release. To take all the specifics out and state my opinion in one general comment. The statement you make above is the exact reason I don't think that beta is a good name. Folks are used to seeing the label beta on some sort of static release that they can test and compare (beta1, beta2, etc) Whereas -STABLE is a constantly moving target. If you looked into it, there would be what? 20,000 possible versions of 4.3-STABLE so far? And you can grab any one of those versions if you want (like if you know a certain feature appeared after a certain date, but a certain bug didn't appear till a certain date) This is the biggest divergence from a beta type software that I see. > On the other hand.I seem to recall the initial post in this sub-thread > was something like "if we are taking votes" 1) I don't think we really > are taking votes and 2) even if we were, I think the majority by their > failure to chime in is indicating their general pleasure with the status quo. True. Considering the core team hasn't asked for a vote, I assume that they either know what they want to do, or they plan to discuss it amoung themselves. I will agree that -STABLE is somewhat misleading. If we had a single word that meant "conservative development", that would be the perfect label for that branch. I still think that beta is not that word, but as you put it, there seems to be general pleasure with the status quo. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Staying *really stable* in FreeBSD
On Wed, 27 Jun 2001, Bill Moran wrote: > In a company, alpha testing is done by the developers or other > employees of the company, Once Upon A Time this was true, but no longer. Viz. Microsoft's "Technology Preview" editions of various pieces of software. Due to lengthening development cycles, companies feel compelled to issue some pretty raw code into the public eye, just to show that they're actually doing something. The mindshare game I guess. Anyway, code never gets out of the beta stage. ;-) Oh, and could you please wrap your lines? -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Staying *really stable* in FreeBSD
On Tue, 26 Jun 2001, Nik Clayton wrote: > I've rewritten section 19.2.2.1 and 19.2.2.2 at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html > > Do people think this gets the point across any better? Yep! It's now abundantly clear. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Staying *really stable* in FreeBSD
On Wednesday 27 June 2001 09:44, Bill Moran wrote: > Is there a reason why you took this off the list? > my mistake (or my mailer's depending on how you look at it). If the majordomo config file for the list included the line "reply-to: [EMAIL PROTECTED]" then all replies would by defualt go back to the list. While this isn't ALWAYS appropriate, it usually is > This particular model falls apart when you have the FreeBSD development > model. Reasons: > 1) anyone who wants to test -CURRENT can, thus it doesn't fit typical > expectation of "alpha" Although depending on your circle of friends, it is frequnetly possible to get alpha-level stuff. More so from some places than others. However, according the handbook, "FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD." and "FreeBSD-CURRENT is made generally available for 3 primary interest groups: 1.Members of the FreeBSD group who are actively working on some part of the source tree and for whom keeping ``current'' is an absolute requirement. 2.Members of the FreeBSD group who are active testers, willing to spend time working through problems in order to ensure that FreeBSD-CURRENT remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of FreeBSD. 3.Peripheral members of the FreeBSD (or some other) group who merely wish to keep an eye on things and use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code." Item 1 is clearly developers, and thus traditionally falls under "alpha" any way you slice it. Number 2 is perhaps more of a stretch, but even alpha testing implies that some testing is done. Opening up the "alpha" test to more people doesn't necessarily make it not an alpha test, it simply makes the results more accurate. The more mistakes/bugs/problems you can catch before the beta-test stage, the less problems you will have in beta. The less beta trouble you have, the quicker you can release a product. > 2) the developers are generally also the users I don't necessarily see the relevance of that to testing. If anything, it means the tests will be somewhat more thorough, but again, when the developer is the user, the user will use the product as intended, and may never break something. When an end-user is the user, who doesn't know what the underlying data structures are, if the program isn't smart enough to compensate for a stupid user, the user is going to make the program crash. Again, I would point out that in many cases, yes, this is simple user-error, and should not necessarily be the job of the developer to fix stupid users (as my brother-in-law, a programmer, used to call those errors "User Headspace Error"). > 3) The -STABLE branch is not *intended* to be for testing purposed only. It > is *intended* to be a useable product. In the commercial world, a "beta" is > NOT INTENDED for regular use, but for testing only. Thus, renaming the > -STABLE branch would be a misnomer. > I don't necessarily recommend renaming things (especially when the current (no pun intended) naming scheme works fine for most people) I think the perception should perhaps be clarified becuase -stable isn't nearly as stable as one would understand from either the handbook pages or the name. The simplest solution would be to equate -current with "alpha" code and stable with "beta" > > Of course, if you assume that STABLE is BETA level code, then you can > > expect some glitches, and sometimes things WILL slip through the cracks > > and cause major headaches...but *in general* you should have fairly > > stable code, with a few bugs in it. You EXPECT (or SHOULD EXPECT) there > > to be bugs in itthat's part of the development effort. > > No, according the the handbook, you should not *expect* there to be bugs in > -STABLE, You should be wary, as the handbook warns you, but my experience > with -STABLE over the last two years is that it's generally pretty > reliable. The handbook also states that you should subscribe to the stable > mailing list if you intend to track -STABLE, so anyone following the > hanbook is going to be well informed when breakage occurs. > hmm...maybe we are reading different versions of the handbook? "FreeBSD-STABLE is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Any changes to this branch will have debuted in FreeBSD-CURRENT first, helping to reduce (but not eliminate) the chance that the changes will cause problems" (from the online handbook) note the "but not eliminate" phrase. There is the expectation that the code should be relatively bug free (since it has been through one set of tests already) but one set of testing isn't necessarily
Re: Staying *really stable* in FreeBSD
On Wed, Jun 27, 2001 at 09:41:18AM -0500, Christopher Schulte wrote: > > At 11:44 PM 6/26/2001 +0100, Nik Clayton wrote: > >I've rewritten section 19.2.2.1 and 19.2.2.2 at > > > > > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html > > > >Do people think this gets the point across any better? > > The patch branch (currently RELENG_4_3) should be introduced, perhaps > mentioned here, Not yet. AIUI, the RELENG_4_3 branch is an experiment, and gives us the option of providing security fixes this way. I haven't seen a commitment[1] from the security officer team that they will actually do this. Until that happens I don't think it should be documented. N [1] Not a slur on the fine efforts of the security team. I mean that I haven't seen an e-mail that says "Yes, any security fixes to RELENG_4 will *definitely* be made available on the RELENG_4_3 branch". -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Staying *really stable* in FreeBSD
On Sun, Jun 24, 2001 at 02:34:03AM -0700, Jordan Hubbard wrote: > From: "Juha Saarinen" <[EMAIL PROTECTED]> > Subject: RE: Staying *really stable* in FreeBSD > Date: Sun, 24 Jun 2001 12:00:59 +1200 > > > "19.2.2.2. Who needs FreeBSD-STABLE? > > If you are a commercial user or someone who puts maximum stability of > > their FreeBSD system before all other concerns, you should consider > > tracking FreeBSD-STABLE. This is especially true if you have installed > > It's probably time to rewrite that paragraph substantially. It was > something of a tactical error to encourage certain interest groups to > run "work in progress" code, even if that work is very carefully > bounded and kept "in progress" for the shortest periods possible. > > You just can't have a code base which is actually going places and > having things actively updated (which is generally a really good idea, > especially when the updates involved fixing bugs) and also guarantee > that it's particularly usable for anything. Whether it builds > flawlessly without warnings or not, it still represents a fairly > significant unknown quantity until such time as you've frozen the code > and spent a few weeks, at minimum, collecting user reports and making > very carefully selected changes. > > We've also heard any number of suggestions for "fixing" the problem, > from aggressive automated tagging (which would be tremendously > expensive with CVS and not fix the "builds but doesn't work" problem) > to extensive regression test suites that nobody seems to have time to > actually write. > > As I said at the beginning, perhaps it's time to simply re-write the > Handbook paragraph which inadvertently "sells" -stable as a solution > for certain types of problems it was never meant to solve. Done. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
RE: Staying *really stable* in FreeBSD
Is there a reason why you took this off the list? On Wednesday, June 27, 2001 10:52 AM, Mike Porter [SMTP:[EMAIL PROTECTED]] wrote: > On Wednesday 27 June 2001 07:11, you wrote: > > On Tuesday, June 26, 2001 5:07 PM, Chad R. Larson [SMTP:[EMAIL PROTECTED]] > wrote: > > > If anyone is taking votes, I disagree. > > The -STABLE branch is not -BETA in any way that I can see. It's simply a > > low key development branch. Changes are tested in -CURRENT before > > being merged into -STABLE, therefore there's nothing -BETA about it. > > > > While I agree with most of what you said, I disagree here. Just because > *some* testing has been done, doesn't mean it isn't BETA. BETA software is > generally believed to be pretty stable, just a few minor kinks to work out. > At that point, getting it into the hands of the largest possible > cross-section of users makes sense, becuase collectively they are more likely > to excercise all of the features. Further, some features may work as > intended when the user follows all the correct steps in the correct sequence, > but how easy is it to get out of the sequence and break things? (Example (ok, > its a bad/simplified example but it demonstrates the point): Actually ... it's a good example. > So BETA testing takes place after a good deal of > previous "in house" development happens. This is the "alpha" test stage. > Why do you think they use "beta" (the SECOND letter of the greek alphbet) to > denote the SECOND test? It implies that there is an "alpha" or "first" test > before. thus -CURRENT is ALPHA level code, STABLE is BETA. That's also a relevent point. "alpha" and "beta" are generally used to describe testing sequences in/out of the developer circle. In a company, alpha testing is done by the developers or other employees of the company, while beta testing is done by providing the software to a select group of customers who have volunteered to test the software. This particular model falls apart when you have the FreeBSD development model. Reasons: 1) anyone who wants to test -CURRENT can, thus it doesn't fit typical expectation of "alpha" 2) the developers are generally also the users 3) The -STABLE branch is not *intended* to be for testing purposed only. It is *intended* to be a useable product. In the commercial world, a "beta" is NOT INTENDED for regular use, but for testing only. Thus, renaming the -STABLE branch would be a misnomer. > Of course, if you assume that STABLE is BETA level code, then you can expect > some glitches, and sometimes things WILL slip through the cracks and cause > major headaches...but *in general* you should have fairly stable code, with a > few bugs in it. You EXPECT (or SHOULD EXPECT) there to be bugs in > itthat's part of the development effort. No, according the the handbook, you should not *expect* there to be bugs in -STABLE, You should be wary, as the handbook warns you, but my experience with -STABLE over the last two years is that it's generally pretty reliable. The handbook also states that you should subscribe to the stable mailing list if you intend to track -STABLE, so anyone following the hanbook is going to be well informed when breakage occurs. I believe the recent changes to the handbook did an excellent job of clearing this up. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
