From owner-freebsd-stable@FreeBSD.ORG Thu Sep 18 22:02:14 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADDFB1065675 for ; Thu, 18 Sep 2008 22:02:14 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id 721388FC1E for ; Thu, 18 Sep 2008 22:02:14 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id m8IM2Dgv040637 for ; Thu, 18 Sep 2008 17:02:13 -0500 (CDT) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id m8IM2Dlx040636 for freebsd-stable@FreeBSD.org; Thu, 18 Sep 2008 17:02:13 -0500 (CDT) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Thu, 18 Sep 2008 17:02:13 -0500 From: Scott Lambert To: freebsd-stable Message-ID: <20080918220213.GA94268@sysmon.tcworks.net> Mail-Followup-To: freebsd-stable References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Upcoming Releases Schedule... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 22:02:14 -0000 On Thu, Sep 18, 2008 at 12:23:45PM -0700, Jo Rhett wrote: > On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: > > (1) Become a contributor to the community by developing and > > maintaining patches against unsupported branches, especially against > > older releases such as 4.x and 5.x where the branches are open for > > commits but have fallen out of support status. I can't promise the > > results will > > We have no 4.x or 5.x systems nor do we have any interest in > maintaining those. So perhaps a good idea, but not something I can > help with. > > I *did* offer to work on maintenance for 6.2, but was told it would be > rejected by the developers. Would I extend effort to do exactly what > I am talking about -- extending the support lifetime for very recent > releases? Absolutely. If its in a form useful for the community as a > whole. > > If I have to do this on my own (what we are doing internally now) then > the FreeBSD community leverages nothing from the effort, and we're not > changing the resources limitations at all. I don't have a dog in this fight. I'm just writing this message because it looks to me like there is a lot of talking past one another going on between people who are basically in violent agreement with one another. I am hoping that wording things differently will lead to understanding on both sides. I may have completely misinterpreted both sides. Spoken languages are too ambiguous. Here is the boiled down gist of my interpretation of a possible way to go forward with this; bad pseudo code: RESOURCES='Jo and the others he seems to know of who back port fixes to their production versions of "unsupported" versions of FreeBSD.' For i in "RELENG_X_Y" (where X_Y is not a currently "supported" version of FreeBSD); do grant maintenance commit access for $i to ${RESOURCES} done; Now for the code documentation: Maybe one of the ${RESOURCES} could build some web application whereby people could sign up to be a "community extended support" resource for RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment from ${RESOURCE}s ${EMPLOYER} would be required before accepting the candidate for work on RELENG_X_Y. Then the existing developers or core team could approve their application/access and provide a mentor if they aren't currently commiters. (This is some extra work for the existing people. But hopefully the rewards would be worth the minimal? effort.) Eventually, the mentor pool could be wholly from ${RESOURCES}. Much of the approval of new candidates would be from the same pool. The whole thing might have to be conditional on ${RESOURCES} bringing the necessary tinderbox type hardware to do basic QA on their extended support branches. With enough ${RESOURCES} signed up, they might be able to get hardware from ${DONORS} other than themselves. The ${RESOURCES} people could gang up on which RELENG_X_Ys they want to support. They can support them for as long as they have people on the team who are interested in supporting them. Presumably, these people would be working for companies which have made a commitment to use RELENG_X_Y for N years. In this way, the companies which are already paying their people to apply security fixes to old releases can donate the work which is already being done back to the project. Hopefully they will end up sharing the load so that they reap the benefits of work done by other companies which are paying people to do the same things. So long as the requirements for a back port to the ${RESOURCES} supported branches are the same as to an officially supported branch, there shouldn't be much chance of harm. Perhaps they are only allowed to back port fixes which have been approved for a supported RELENG_X_Y. Eventually, if enough ${RESOURCES} sign up, they might be able to release X.Y.z distribution media. If they only provide the media for CD/DVD purchase, the revenue might help to provide for QA tinderboxes for the ${RESOURCES} supported work. We might even end up with more people who are familiar with the release process and volunteer to work on RELENG_X_Y from initial release all the way through normal end of support and into the community extended support period. I think that would provide, as much as is possible, for the "don't make extra work for the existing developers" requirement as well as giving these resources a way to "put up or shut up." I could be wrong. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org