OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Stable branch
From: Mike Silbersack (silbysilby.com)
Date: Thu Oct 05 2000 - 19:02:52 CDT

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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message