Upcoming Releases Schedule...

[Robert Watson]

On Thu, 18 Sep 2008, Jo Rhett wrote:

> Thank you.  If you don't mind I'd prefer to widen the scope a touch because 
> 6.2 will eventually go away, and frankly it is probably better to look 
> forward than to resurrect an unsupported version.  So I would probably 
> state:
>
> Jo's $EMPLOYER has significant interest in longer support for -REL versions. 
> Enough to fund my time supporting the mainstream project.  What would Jo (or 
> anyone else in a similar situation) need to bring to the table in order to 
> provide back to the project?

This is the same answer I gave Lowell, but let me expand on it slightly.  Our 
community grants rights (read also: responsibilities) on the basis of 
credibility in the community.  Here's a possible plan:

In the first stage, you need to establish credibility with the community as 
someone able and willing to do the work.  You can do this by doing hard bits 
of the work without getting "official" sanction by creating an "Unofficial 
security and errata support for EoL'd FreeBSD releases" web page.  Be very 
careful to scope the work so that you're not over-committing and there's no 
misunderstanding of what you're trying to do.  Flag certain branches as "in 
support", and for each of those branches, provide pointers to the security 
advisories and errata patches that you've backported.  If you take a branch 
out of support for your page (are no longer interested in maintaining it), 
keep the old stuff around for historical reasons, but clearly marked as 
historical rather than active.

This will allow you to gain experience in maintaining security and errata 
patches for FreeBSD branches (more different than you might think from 
maintaining patches locally), establish credibility with the community as a 
whole, but in particular with the FreeBSD developers who are responsible for 
doing similar work for supported branches.  This in turn may convince them 
that they should invest their time in mentoring you for a FreeBSD commit bit, 
and potentially join the security or release engineering teams once you've 
established that you are a member of the developer team who works well with 
others, does good technical work, and who is in it for the long haul.

Some downsides to this approach:

(1) It doesn't give the immediate gratification of seeing the official support
     status extended for releases.  However, as you say, you're already doing
     the work.

(2) You don't gain early access to confidential vulnerability information as a
     member of the security team, so (a) you can't have the patches ready in
     advance of the advisory, and (b) if there are reports of vulnerabilities
     in versions you support but the FreeBSD security team doesn't, you might
     not receive it in a timely manner.

However, it accepts the way the project works: we don't provide access to our 
CVS (SVN) repository to people unless they have a mentor willing to propose 
them, and that mentor has to argue on the basis of a proven track record that 
the contribution you will make justify commit access to the tree.  Likewise, 
we don't grant membership to the security team to committers unless they've 
shown a longer term commitment even than required for a commit bit, shown 
specific interest and commitment to security support issues, and that have 
they confidence of the security team that will be able to work with 
appropriate discretion in protecting the confidential and often critical 
security information we receive.

Don't take this as a personal slight -- none of this says you aren't able to 
work with others, that you don't have the technical skills, that you don't 
have the time, aren't willing to make the commitment, or that you lack 
adequate discretion.  Rather, it's saying that the way we evaluate people for 
participation in the project is that they have a track record of these things 
in the community.  In a largely online and volunteer community, that's the way 
it works.

Robert N M Watson
Computer Laboratory
University of Cambridge