Date: Fri, 19 Sep 2008 12:20:14 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Jo Rhett <jrhett@netconsonance.com> Cc: freebsd-stable <freebsd-stable@FreeBSD.org>, Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> Subject: Re: Upcoming Releases Schedule... Message-ID: <alpine.BSF.1.10.0809191158330.40909@fledge.watson.org> In-Reply-To: <C096D142-4572-48DF-8CCA-053B41003A07@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <F17BE4F1F989BB4A81EB94C36712A9736F3493@dni-mail.datanode.com> <20080904133604.GB1188@atarininja.org> <CB36FE28-D125-4C22-B5DE-1001515DD8A6@netconsonance.com> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <alpine.BSF.1.10.0809061159410.28840@fledge.watson.org> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <alpine.BSF.1.10.0809162043380.64176@fledge.watson.org> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <alpine.BSF.1.10.0809180022580.13100@fledge.watson.org> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <alpine.BSF.1.10.0809181935540.16464@fledge.watson.org> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <C096D142-4572-48DF-8CCA-053B41003A07@netconsonance.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0809191158330.40909>