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

[Derrick Brashear]

On Tue, Jan 13, 2009 at 9:00 AM, Jason Edgecombe
<jason@rampaginggeek.com> wrote:
> Jeffrey Hutzelman wrote:

>> 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?

I'd rather see automatic daily testing, but, having a lightweight
release process for at least some 1.5.x releases is what I don't wish
to give up.

As to Jeff's proposal, I had an alternate proposal I wish I could find
now. It seems to have never made it anywhere but would have involved
slightly less parallel tracking; The concerns would be confusion among
the various efforts both among those contributing as well as those
using, and the difficulty in merging large changes around divergent
trees, at least unless the goals for each branch were necessarily
well-understood up front.

Derrick


-- 
Derrick