[OpenAFS-devel] release-team@openafs.org

[Jeffrey Hutzelman]

--On Monday, January 12, 2009 08:27:27 PM -0500 Derrick Brashear 
<shadow@gmail.com> wrote:

> On Mon, Jan 12, 2009 at 8:20 PM, Christopher D. Clausen
> <cclausen@acm.org> wrote:
>> Derrick Brashear <shadow@gmail.com> wrote:
>>>>
>>>> 2. I'd like to request formally that the gatekeepers make it possible
>>>> for willing volunteers like myself to join the release team, so that
>>>> we can help with this type of work.
>>>
>>> release-team@openafs.org has been available for this purpose for quite
>>> a while now. Please join it if you'd like to help build and test
>>> releases that we'll be making binaries available of; As to the
>>> preceding point, I will grant that a few times unix support in 1.5.x
>>> has slipped a little as we've attempted to push fixes for Windows
>>> quickly, and I apologize for that.
>>
>> Maybe someone should update the description for that list then, as I
>> interrpret it as "GO AWAY" in kinder and gentler wording:
>>
>> "This list is for private discussion and announcements among the group of
>> people involved in putting together a public release of OpenAFS.
>>
>> This is a closed list -- subscriptions require approval from the list
>> adminstrator, and only current subscribers may post without moderator
>> approval. Only people involved in putting together OpenAFS releases will
>> be permitted to subscribe to this list. If you are not such a person,
>> please do not send subscription requests; the vast majority of work done
>> by GRAND.CENTRAL.ORG postmasters consists of rejecting subscription
>> requests for private lists."
>
> I didn't write it. I assume Jeff Hutzelman did. However, the goal was
> to convey that it's not a list for discussion or opinion, it's one for
> fact:
> -builds/does not build
> -works/does not work
>
> The idea being that development discussion would take place here.

In fact, I did write it, based on my understanding of the purpose of the 
list at that time.  When the list was created, it was intended for exactly 
what the description says -- private discussion among members of a closed 
group consisting specifically of those people involved in the mechanics of 
actually producing and publishing a release, and especially announcements 
from the gatekeepers to that group.  It was not intended that the list be 
used for discussion about what should or should not go into a release or 
when one should happen; those decisions were up to the gatekeepers.  It was 
also not intended for reports of what did or did not build or work, except 
from people producing the official binary builds.

To reiterate: the "release team" _does not_ decide what should go into a 
release, when one should happen, or anything like that.  What it does is 
put together the files that constitute a release, once someone decides one 
should happen, and that generally only for stable releases -- releases on 
the 1.5.x branch rarely get _any_ release-team traffic.


Now, we can change what the list is for, but I recommend against that.  It 
serves a useful purpose in its present form, and I don't think there's a 
need to invite anyone and everyone to join a list that is supposed to be 
low-volume enough that people building binaries for a release will pay 
attention when one is happening.  If you (anyone) see a gap in what should 
be in a release and feel you can fill that gap (say, by building binaries 
for a platform we don't currently distribute them for), contact the 
gatekeepers and volunteer to do so.  I don't think that's an unreasonable 
model.

If what you want to do is build and test release candidates, identify and 
fix release-critical bugs, etc, then by all means do so.  This list gets 
about as much advance notice as release-team does about 1.4.x prereleases 
and about all 1.5.x releases; release-team gets a bit more advance notice 
about 1.4.x final releases, but only because its members need to prepare 
the binary builds before the release announcement goes out.



I agree with Matt's proposal to create a steering committee for 1.6, to 
determine what should end up in a stable 1.6 and manage the process of 
getting there.  If such a thing is created, it would seem appropriate for 
it to have its own mailing list, and we can argue about how accessible that 
should be.

I'm not sure if I agree with Matt's proposal to introduce more formality 
into the 1.5.x stream.  The current release process for that branch is 
extremely lightweight, and I think there is some benefit to keeping it so. 
Instead, it might be beneficial to work on cutting a new stable branch 
which includes the major features that have been sitting in 1.5.x for a 
long time.  It would probably be good to come up with a way to allow users 
to choose from among three update strategies:

(1) Frequent releases including new features with relatively little
    advance testing, similar to today's 1.5.x branch.
(2) Infrequent, fairly conservative releases consisting mostly of bug
    fixes and, to the extent possible, keeping up with platform changes,
    similar to today's 1.4.x branch.
(3) Something in between, with releases less frequent than (1) and less
    conservative than (2), getting new features from time to time once
    they have baked on (1) for a while and are believed to be stable.


The idea more or less is that (1) is managed by the gatekeepers pretty much 
like 1.5.x today, getting new stuff as soon as they feel it is ready, while 
(3) is managed by some form of steering committee whose purpose is to pick 
changes up off of (1) once they are well-baked enough.  These would 
essentially be separate parallel sequences, with (1) always somewhat ahead 
of (3) so they never really converge.

(2), on the other hand, would be one or more branches off of (3), each 
maintained by a release manager (or more than one) who is responsible for 
getting fixes backported and doing releaess as needed.  From time to time 
we'd branch a new (2) and/or retire an old one.

Comments?


-- Jeff