Upcoming Releases Schedule...

[Scott Lambert]

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 at lambertfam.org