Date: Tue, 23 Sep 2008 16:10:17 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Jo Rhett <jrhett@netconsonance.com>, Robert Watson <rwatson@freebsd.org>, Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> Subject: Re: Upcoming Releases Schedule... Message-ID: <200809231610.17625.jhb@freebsd.org> In-Reply-To: <C0E77652-6C95-44CE-AD4A-3592ABA3E465@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <alpine.BSF.1.10.0809222120420.26766@fledg! e.watson.org> <C0E77652-6C95-44CE-AD4A-3592ABA3E465@netconsonance.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your "cumulative patch" (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the "street cred", as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the "Unofficial FreeBSD 6.2 Patchset" can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809231610.17625.jhb>