Date: Thu, 15 Apr 2004 15:05:29 -0500 From: Jon Noack <noackjr@alumni.rice.edu> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: release-engineering branches (was Re: kernel panic in if_ppp.c) Message-ID: <407EEB09.7080302@alumni.rice.edu> In-Reply-To: <Pine.NEB.3.96L.1040415151115.95950G-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040415151115.95950G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Jon Noack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?407EEB09.7080302>