On Dec 10, at 05:21 PM, Robert Watson wrote:
>
> On Mon, 10 Dec 2001, D J Hawkey Jr wrote:
>
> > So, my question is then, just what is the policy defining
> > non-current-but- still-supported-releases?
> >
> > [SNIP]
>
> It depends on the level of work required, I expect. Right now, we're
> actively supporting 4.3-RELEASE and 4.4-RELEASE. Once we get to a point
> where the cost is greater than can be handled by our all-volunteer staff,
> we'll cut back. Currently, my hope is that we can keep supporting all
> branches of 4.x-RELEASE through to 5.0-RELEASE next year. If we try to
> avoid doing too many releases, that will be easier :-).
Don't get me wrong - I don't expect the same level of support from the
FreeBSD Project than I would from, say, Sybase or Sun. Having said that,
I think FreeBSD's is outstanding, even compared to some other commercial
*cough*Microsquish(tm)*cough* entities.
> > This comes 'round to one of my original questions, too: Why, as an
> > example, isn't the DELACK patches Matt made recently considered
> > "important" enough to be backported to RELENG_4_3 (which I have more
> > generically referred to as RELENG_(current - 1) or RELENG_(release -
> > 1))?
> >
> > [SNIP]
> >
> > Yes, I know this would mean additional work on the part of the hacker
> > and committer ...
> >
> > [SNIP]
>
> The quick answer is: because the security-officer team is using the
> RELENG_4_x branches to generate binary updates, and has extremely limited
> resources. As such, the only things being merged onto the branch are
> security fixes. If the release engineering team is willing to take over
> the task of generating binary updates, and wants to broaden the scope of
> the branch, then such a proposal might make more sense.
>
> The goal of creating the branches was to permit version control to be
> applied to a series of updates that were previously being managed by hand:
> security patches ... While I'm sympathetic to the cause of "we want a
> -NOT-AS-AGRESSIVE-AS-STABLE-BUT-NOT-JUST-SECURITY-FIXES", I think our
> resources are already spread too thin to support that. If we were to move
> to a model where the branch was maintained by re@, who generated binary
> updates based on commits to the branch, and managed the QA process,
> looking at a broader scope of potential commits might be feasible.
>
> [SNIP]
I understand. I also understand that my questions and suggestions have the
benefit of 20/20 hindsight.
> > The site Michael and I have discussed will be hugely deficient in terms
> > of what can be made available to any previous release (compared to what
> > is applied to -STABLE), but as it sits right now, it would be better
> > than nought for those that can't stay -STABLE.
>
> I think in practice you'll find what is needed is the ability to do local
> revision management in the form of branches.
>
> [SNIP]
My current plans are to have several patchfiles, grouped by subject (bugfix
and/or enhancement), and subordinately grouped by FreeBSD release:
ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff
ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff
ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff
You get the idea. It will be all over the web page(s) that the patches are
very narrowly targetted, and will list all the usual paranoia steps that
should be taken for a decent fallback position should something fail. I
have no intention of trying to emulate the FreeBSD model - not that it's
not worth emulating, but rather, I simply don't have the resources.
Unless it proves overwhelming, I do plan on offering my help in applying
patches to the newbie/clueless. or to already hacked sources.
Finally, it will be perfectly clear on the web page(s) that what is
presented is not endorsed or supported by The Project, blah-blah-woof-woof.
> left with a heavy burden, however: QA. Part of the currently goal of
> RELENG_4_x is that each change be extensively tested, and usable by a wide
> audience with low levels of concern about picking up potentially
> conflicting changes. Most of the changes are very small, and as such have
> a higher probability of correctness.
Well, I can't provide that level of QA, of course. I can and do run systems
with these patches in place, and I pick my targets carefully. I'm not about
to backport something like DIRPREFs, but things more discreet/isolated, like
ICH sound and delayed ACKs, I can wrap my arms around with fair confidence
that I won't muck up something else.
C is no stranger to me, and I've hacked/patched a lot of source. I still
maintain an X WM that's over ten years old now. Hacking FreeBSD offers one
advantage over that - cross-platform compatability isn't an issue!
> Broadening the charter for the
> release branch would mean expanding the QA process.
And, had the Core 20/20 foresight, it might well have chosen that path, no?
Granted, any one patch (and therefore, release) might well take longer to
complete, but continued previous-release support would be more do-able.
Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are
outstanding products. I'm just gonna see if I can't fulfill what I percieve
as a support deficiency (again, from my own perspective) in my own little
way.
> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
Dave
PS, I'm rather honored that such an illustrious group has shown interest
enough to even discuss all this with me.
--
______________________ ______________________
\__________________ \ D. J. HAWKEY JR. / __________________/
\________________/\ [EMAIL PROTECTED] /\________________/
http://www.visi.com/~hawkeyd/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
