--On Monday, January 12, 2009 08:27:27 PM -0500 Derrick Brashear
<[email protected]> wrote:
On Mon, Jan 12, 2009 at 8:20 PM, Christopher D. Clausen
<[email protected]> wrote:
Derrick Brashear <[email protected]> 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.
[email protected] 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
