Date: Wed, 13 Jun 2012 08:50:24 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Adrian Chadd <adrian@freebsd.org>, Matt Olander <matt@ixsystems.com>, Mark Linimon <linimon@lonesome.com> Subject: Re: Upcoming release schedule - 8.4 ? Message-ID: <CAGH67wTJ7zwAtf0g009_bxyJP5VXBUkeebNGvZCm%2B-0-8RfjvA@mail.gmail.com> In-Reply-To: <201206130853.32687.jhb@freebsd.org> References: <alpine.BSF.2.00.1206111537310.19012@kozubik.com> <alpine.BSF.2.00.1206121545560.19012@kozubik.com> <CAJ-Vmomw7Tnce2Gyo443smS_%2BZQ4jLhWUqxhuZ2m-F%2Bxi81=Nw@mail.gmail.com> <201206130853.32687.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 13, 2012 at 5:53 AM, John Baldwin <jhb@freebsd.org> wrote: > On Tuesday, June 12, 2012 8:01:00 pm Adrian Chadd wrote: >> hi, >> >> You don't need to change the FreeBSD culture. We'd love to do an 8.4 >> release. And an 8.5 release, and 8.6 release, etc. The problem is one >> of resources and time, not of culture/desire. > > I disagree. =A0The pace of X.0 releases is a deliberate choice FreeBSD > has made and directly impacts the number of "live" branches in existence. > Given our developer base, we can't really support 3 branches concurrently > (head + 2 stable like we have now with head, 9, and 8). =A0Having longer = lived > stable branches requires either increasing resources to support exising > releases longer, or slowing the pace of X.0 releases (but more aggressive= ly > merging things from HEAD back). =A0The latter case, especially, is part o= f > the culture and would be a choice we as a Project would have to make. The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc as the current paradigm requires the developer (or another stand-in developer in the event that the original developer failed to MFC the code) to do the work (which is sort of what the OP is doing in this case, and what I've seen a few different groups do that don't run bleeding edge code). That concept doesn't really exist today. Maybe this would be a good idea for improving the longevity of release cycles and maybe that's what ultimately needs to be done as it would reduce distractions on developers actively churning away on {[CURRENT-1],}[CURRENT], and maybe that's what should be proposed. As good as BSDi was from what I hear, that "business" model alone won't probably work as many people take the support piece (companies that just want the software and might develop/support apps/services on top of it) and the longevity piece (companies that develop with/on the software as a product) separately. They're typically (but not always) mutually exclusive from what I've seen in my limited experience. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wTJ7zwAtf0g009_bxyJP5VXBUkeebNGvZCm%2B-0-8RfjvA>