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: Ralph Huntington (rjhmohawk.net)
Date: Thu Oct 05 2000 - 19:10:41 CDT

I see what you're saying. My suggestion only involved merging bug fixes
and security patches into the latest prior version, i.e, 3.5.1 at this
time. I would not go further back than that. I thought I was suggesting
something that would be less work, not more, since it meant not adding new
features into any prior stable branch and only merging fixes into the
latest prior stable branch. Perhaps my view of this is simplistic, though,
since I am relatively new to this discussion.

In no way am I advocating increasing anyone's work load. -=r=-

On Thu, 5 Oct 2000, Warner Losh wrote:

> In message <Pine.BSF.4.21.0010050546550.8007-100000mohegan.mohawk.net> Ralph Huntington writes:
> : the latest release (not current), i.e., since 4.x-RELEASE is the latest,
> : then 3.x-STABLE hould be supported with bug fixes and security patches
> : until a 5.x-RELEASE is out.
> :
> : Does this seem unreasonable? -=r=-
>
> Yes and no. It sounds reasonable, but puts a significant burdon on
> the security officer and his security team to make it happen. Having
> two machines for -current and -stable is bad enough, plus test
> compiling patches on the last N RELEASES of -stable puts a fair load
> on getting an advisory out. Making that include a second branch will
> nearly double the work and pita factor to make it happen. When I was
> doing 4.0-current, 3.2-stable, 3.2-release, 3.1-release, 3.0-release,
> 2.2.8-release and 2.2.8-stable regression testing on a couple of
> kernel patches it took me a *HUGE* amount of time. 40% of it for 4.x
> and 3.x and 60% for the 2.2.8-stable and -release. Why so much for
> 2.x? the original author of the patch hadn't back ported it, was
> disinclined to back port it so I wound up doing it. This made it
> extremely painful to try to get the advisory out (I think it was 6
> weeks from the time the bug hit -current until I sent the advisory
> out).
>
> Until you pay someone to do this full time, it isn't going to happen.
> History has shown this. This suggestion comes up every N years, we do
> OK with it for a couple of months until one bug comes along that's
> such a pain in the butt that we say "screw this old stuff, I'm just
> going to stop doing it because it is too much of a pita and no one
> seems to care enough to help." and then are happy for a while until we
> cut the next major branch in which case we recapitulate the whole
> process.
>
> Sorry to be such a sour puss, but I've "been there, tried that" before.
>
> Warner
>
>
> To Unsubscribe: send mail to majordomoFreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
>

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message