release-engineering branches (was Re: kernel panic in if_ppp.c)
Julian Elischer
julian at elischer.org
Thu Apr 15 15:49:32 PDT 2004
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.
yes I've been pushing for this, as I am also reponsible for production
machines.. (about a thousand of them)
We currently keep a separate cvs repository of 'patches' and added files
that we apply automatically when we make our system images..
but it's a lot of work for p[eople just getting started to set that sort
of infrastructure up.
>
> Jon Noack
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
More information about the freebsd-current
mailing list