Re: -stable to -current
On Fri, 29 Oct 1999, Ben Rosengart wrote: On Fri, 29 Oct 1999, Doug White wrote: I still hate the way the signal change was handled. How would you have done it differently? As I understand it, the pain was more or less inevitable. Perhaps, but there must be a way to keep gcc from dying. I don't fully understand the mechanics involved so I will shut up until I teach myself about the syscall handling and concoct a better solution :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -stable to -current
On Fri, 29 Oct 1999, Doug White wrote: On Fri, 29 Oct 1999, Ben Rosengart wrote: On Fri, 29 Oct 1999, Doug White wrote: I still hate the way the signal change was handled. How would you have done it differently? As I understand it, the pain was more or less inevitable. Perhaps, but there must be a way to keep gcc from dying. I don't fully understand the mechanics involved so I will shut up until I teach myself about the syscall handling and concoct a better solution :) Since there were syscalls added, the newly compiled gcc calls system calls in the kernel that don't exist... _yet_ I like the idea of some sort of date/version checking, but it's not being checked just yet. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
In message 199905021941.paa22...@blackhelicopters.org Dispatcher writes: : For mission-critical systems, I'm still installing 2.2.8-stable. And the security officer still back ports relevant patches to 2.2.8-stale. The 2.2.8 - 3.x transition lost support for several devices (aic being the mostly loudly complained about). Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
#Tim Vanderhoek wrote: #On Fri, Apr 30, 1999 at 04:52:58PM -0700, Matthew Dillon wrote: # # I expect the 3.2 release to be a really good release. # #I seem to recall that 2.2.x wasn't even called -stable until 2.2.2. #That .2 release is exactly where 3.x is right now... And it wasn't until 2.2.5 that I saw an official note saying 2.1.7 users should upgrade now. I won't upgrade my mission-critical systems until I see a similar notice from Jordan or someone in his place. For mission-critical systems, I'm still installing 2.2.8-stable. ==ml To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
And it wasn't until 2.2.5 that I saw an official note saying 2.1.7 users should upgrade now. I won't upgrade my mission-critical systems until I see a similar notice from Jordan or someone in his place. For mission-critical systems, I'm still installing 2.2.8-stable. And I can only echo these sentiments. I've never made a secret of the fact that .5 is always the best time to jump on board any branch in this project and it's been that way since practically the beginning. There's even a later snapshot release of the 2.2 branch on the FreeBSD Toolkit for people who continue to subscribe to this philosophy. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: -stable vs -current (was Re: solid NFS patch #6... )
-Original Message- From: Matthew Dillon [mailto:dil...@apollo.backplane.com] Sent: 01 May 1999 00:53 To: freebsd-current@FreeBSD.ORG Subject: -stable vs -current (was Re: solid NFS patch #6... ) I expect the 3.2 release to be a really good release. It is true that -current has been, more often then not, more stable then -stable in the last two months. This is because fixes were being made to -current more quickly then they could be backported to -stable. Most of these fixes *have* been backported at this point. There are still a few that have not that are on my hot list ( and still not addressed, even with prodding ). There are also a few bug fixes that simply cannot be backported to stable without some pain ( i.e. require the complete replacement of a number of subsystems ), and pain is not in the cards with the 3.2 release so close. But no-one is really testing -stable. How many people have a stable machine and a current machine and spend as much time testing stable as they do current? It is hard enough dealing with two branches of the source tree. I will personally take my Super Soaker 5000 to anyone suggesting that we have *three* . Sqirt sqirt sqirt! The -stable branch shouldn't have anything done to it, that's my whole point, we shouldn't be merging stuff back into the -stable branch, only fix specific straightforward problems that don't require complete re-engineering. I am hoping that we will be able to accomplish a major synchronization after the 3.2 release. I personally believe that -current is stable enough that we should do one big-assed commit to sync -stable up to the current -current and then continue as per normal. I only wish EGCS hadn't been incorporated quite yet. At the very least, I want to sync *my* stuff up ( NFS/VM/VFS/BIO/VN/SWAPPER ). Then what happens to -stable, is it going to get thouroughly tested with all these changes? You're currently treating -stable as a beta stable in that users who track it are being used as beta testers to find the bugs caused by merges from current. There's no track for really stable users who want to pick up necessary bug fixes. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: -stable vs -current (was Re: solid NFS patch #6... )
On Sat, 1 May 1999 p...@originative.co.uk wrote: The -stable branch shouldn't have anything done to it, that's my whole point, we shouldn't be merging stuff back into the -stable branch, only fix specific straightforward problems that don't require complete re-engineering. No new features means stagnation in development. It means that someone coming to FreeBSD and looking for a feature will only find it in -current, which, by virtue of being -current, will have other miscellaneous problems. This person gets annoyed and leaves. This is the _LAST_ thing we need right now. Your idea of -beta is exactly the idea of -stable. If you want something that is only receiving bugfixes, run 2.2.x. It's in maintanance mode now. Then what happens to -stable, is it going to get thouroughly tested with all these changes? You're currently treating -stable as a beta stable in that users who track it are being used as beta testers to find the bugs caused by merges from current. There's no track for really stable users who want to pick up necessary bug fixes. Gosh, I was under the impression that every FreeBSD user was a beta tester... :) It's inevitable that bugs will be found in -stable more quickly than in -current, simply because -stable has a much larger user base. Just think back to the days after 3.0-RELEASE and the myriad of bug reports that suddenly came in because the level of usage for that code skyrocketed. Alex G. Perel -=- AP5081 al...@iplink.net -=- (work) ve...@disturbed.net -=- (play) Disturbed Networks - Powered exclusively by FreeBSD == The Power to Serve -=- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
point, we shouldn't be merging stuff back into the -stable branch, only fix specific straightforward problems that don't require complete re-engineering. No new features means stagnation in development. It means that someone coming to FreeBSD and looking for a feature will only find it in -current, which, by virtue of being -current, will have other miscellaneous problems. This person gets annoyed and leaves. Sorry, but this just isn't how our development model has worked over the past 6 years. -stable means it and we are not going to change that. -current is for new features. The only new features that are added to -stable are those which don't affect existing functionality and architectural changes are to be avoid as much as possible. This has been a winning model for us and we're not going to change it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
On Fri, Apr 30, 1999 at 04:52:58PM -0700, Matthew Dillon wrote: I expect the 3.2 release to be a really good release. I seem to recall that 2.2.x wasn't even called -stable until 2.2.2. That .2 release is exactly where 3.x is right now... -- This .sig is not innovative, witty, or profund. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
On Fri, 30 Apr 1999, Matthew Dillon wrote: Well, what it comes down to is the number of developers actively developing the codebase. We had some truely unfortunate timing with people leaving and new people coming on, and pieces of the system ( such as NFS ) that simply were left dangling for a long period of time with nobody actively locating or fixing bugs. There have been too many critics and not enough people getting into the guts of the code and fixing things. ( Of course, I'm *very* biased here in my opinion :-) ). What it comes down to is that a whole lot of changes were made between 2.2.x and 3.0 without enough debugging by the authors. This kinda resulted in a partially rotting code base even through the 3.1 release, until a number of us got sick and tired of it and started actively tracking down and fixing the bugs. I expect the 3.2 release to be a really good release. It is true that -current has been, more often then not, more stable then -stable in the last two months. This is because fixes were being made to -current more quickly then they could be backported to -stable. Most of these fixes *have* been backported at this point. There are still a few that have not that are on my hot list ( and still not addressed, even with prodding ). There are also a few bug fixes that simply cannot be backported to stable without some pain ( i.e. require the complete replacement of a number of subsystems ), and pain is not in the cards with the 3.2 release so close. It is hard enough dealing with two branches of the source tree. I will personally take my Super Soaker 5000 to anyone suggesting that we have *three* . Sqirt sqirt sqirt! 5000 is out? YES!!! I am hoping that we will be able to accomplish a major synchronization after the 3.2 release. I personally believe that -current is stable enough that we should do one big-assed commit to sync -stable up to the current -current and then continue as per normal. I only wish EGCS hadn't been incorporated quite yet. At the very least, I want to sync *my* stuff up ( NFS/VM/VFS/BIO/VN/SWAPPER ). I wholeheartedly agree with this idea! -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
