Jeffrey Hutzelman wrote: > --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? > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
