Date: Thu, 5 Oct 2000 19:02:52 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Brett Glass <brett@lariat.org> Cc: Warner Losh <imp@village.org>, developers@freebsd.org, security@freebsd.org Subject: Re: Stable branch Message-ID: <Pine.BSF.4.21.0010051847080.4973-100000@achilles.silby.com> In-Reply-To: <4.3.2.7.2.20001005173257.048b9f00@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Oct 2000, Brett Glass wrote: > At 12:30 PM 10/5/2000, Warner Losh wrote: > > >Otherwise would do a PR spin with the following patch to 3.x would do > >the trick (I'd call it -solid, because -stable is suitable for > >production machines). > > Personally, I would equate "-SOLID" with "suitable for production > machines" whereas -STABLE would be "OK for application developers > and eager/early adopters but still settling down to the confidence > level of -SOLID." > > Which might imply setting things up so that the -STABLE branch > becomes -SOLID after, say, a good .2 release. > > --Brett I think this is getting overly complex. What would be more useful is to continue managing the different branches as is currently done, but provide some assurance that you're getting something release quality when you update. Some time ago, I recall Joe Greco commenting that he only ran releases because updating to stable was too much trouble due to the time it takes to rebuild a system in such a configuration. Additionally, it seems Brett's worried about encountering the situation where -stable is broken due to a bad commit. Would there be some way for cvsup to honor sub-tags, so that, for example, 3.5.2 could be tagged after the libpasswd bug is fixed? This way, committers could feel more at ease when updating stuff in -stable, and cvsuppers could feel more confident updating to the latest pseudo-release in their branch, knowing that they're getting the same working system their friends told them about. It also simplifies security bulletins. No more dates to confuse people, just version numbers to compare. Undoubtedly, this system would still require a full buildworld rather than simple patching, but it should help peoples' faith in -stable, hopefully. Thoughts? I'm not sure if binary releases of these releases would be a good idea or not. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010051847080.4973-100000>