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

[Jason Edgecombe]

Jeffrey Hutzelman wrote:
> --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?
>
My personal end-goal is to have a process that tests linux daily from
CVS and test windows whenever a intermediate build is made, but until
that time, 2-4 days advance notice of a release would give some testers
a chance to try to break things. just a thought. Ideally, automatic
testing should test daily, but until then, maybe this would help?

Jason