Re: release-engineering branches (was Re: kernel panic in if_ppp.c)

On Thu, 15 Apr 2004, Jon Noack wrote:

> On 4/15/2004 2:13 PM, Robert Watson wrote:
> > Currently, this fix doesn't fit the charter for the RELENG_5_2 branch,
> > which is focussed on security-only fixes.  However, there's an on-going
> > discussion of broadening the scope of the current security branches to
> > release-engineering branches.  If this happens, I'll merge it to that
> > branch also (feel free to remind me if I forget :-).
> 
> This is a fabulous idea.  I know it means a little more work, but I can
> think of several situations where I had to manually patch a release
> branch (or run -STABLE or -CURRENT) because I needed a simple bugfix.
> Broadening the scope to make them release-engineering branches would
> have saved me from this extra work.  I think it increases the
> "durability" of releases, allowing people to more strictly use just
> releases.  As a person responsible for FreeBSD machines in production, I
> find this highly desirable.  I can see definite complications (like the
> MFC rules for the branch -- recent changes in commit permissions to
> require an "Approved by:" line should help, though), but my opinion is
> that this is worthwhile. 

Yeah, this is very much a "work in progress", but it's something we've
been discussing for a while, and something I'd very much like to see
happen.  As you point out, there will be a fair number of complications
(and policy questions) to work out.  However, we've seen enough "good
match" changes that might be worth meging that I think it's definitely
something to consider strongly.  I.e., low-risk changes that introduce a
good fix to a critical stability or feature bug on a release engineering
branch.  Anyhow, expect something out of the various teams soon on how we
propose to handle it, and send feedback :-).

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research