geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: releasing: it takes two
Date Fri, 20 Jan 2006 20:20:34 GMT
I agree with this.  The release can be difficult at best.  And I
appreciate you giving me *much* more credit that is did a lot
more than just a co-pilot (perhaps I should be scolding you for giving
me more credit than is due) ;-)

In any case, this is a great idea, and I would be happy to help co-pilot
others in some coming releases.  Having 2 is the way to go, and its a
great learning experience to be able to learn from your peers, as
everyone does things a little differently.


David Blevins wrote:
> One thing I've been meaning to hit the list with now that we are
> formalizing our release process a bit more....
> For every release I've done ever (in OpenEJB, Geronimo, or otherwise),
> the dynamic I call Pilot and Co-Pilot seems to always come in.  You have
> the person leading the show, the Pilot (aka "Release Manager") and
> someone dedicated to the pilot.  The two of them are responsible for
> delivering a good release.  It's just too much work to do a release
> completely alone; too much to remember and too many steps to do.  You
> usually have someone putting in the hours with you dotting the "i"s and
> crossing the "t"s while you are doing the tagging and branching,
> building and signing, etc.
> In OpenEJB for many of the releases is was me as pilot and Alan as
> co-pilot.  For some Alan would be pilot and I would be co-pilot.
> In Geronimo, I seem to remember the releases going like this:
>  1.0-M1:  David B. (pilot), Dain (co-pilot)
>  1.0-M2:  David B. (pilot), Dain (co-pilot)
>  1.0-M3:  David B. (pilot), Dain (co-pilot)
> Those were all done in the exact same Dunn Brothers coffee shop,
> ironically, and took 1-2 weeks each.  In M3 we actually tried to do it
> at OSCON '04 and I lost Dain to endless meetings and the release just
> didn't happen till the second week after when we happened to be back in
> MN again.  None of those releases could have happened without Dain.
>  1.0-M4:  David B. (pilot), David J. (co-pilot)
> This one was a bit TCK release and it was David J. and I up till the wee
> hours of the morning the last three days and pushing binaries getting
> the last few tck results.  I remember I screwed up the installer cause I
> built it from the branch and no the tag by mistake.  Since David J. was
> working with me on it, he was able to figure it out and put out a good
> installer right away the next morning when people complained about it
> not working quite right.  Definitely, that release would not exist
> without David J.  He carries more than his weight in TCK work in all
> releases these days, but this one he did a significant amount of the
> polish on the binary work.
>  1.0-M5:  Jeff (pilot), David B. (co-pilot)
> Jeff lead the charge with closing up issues, branching, etc., and I
> pretty much just did my best to try and figure out what it is I usually
> did for releases and communicate that to Jeff.  David J. and I did the
> pre-final-build TCK testing and managed to get that done just before
> OSCON '05.  The final run happened on David J's machine "crow" during
> OSCON '05.
>  1.0: Matt (pilot), David B. (co-pilot)
> Matt lead the charge.  He gets the record for the most endurance
> displayed during a release cycle ;).  This was the most community driven
> release to date namely because many of us in LA then San Diego for a
> week.  TCK work done by David J. and myself.  The
> final-final-final-final binaries created, signed and pushed to the
> mirrors by Matt with help from me.  I'm not a very good co-pilot or I
> would have remembered to push the OpenEJB binaries at the same time we
> did the Geronimo ones :)
> Anyway, all releases should be community run and they are getting that
> way more and more.  But I know from experience doing a release is hard
> work and you need a dedicated backup to really do it right.  It's also
> the only real way to pass the release baton from one person to another:
> let them co-pilot a release with you and then let them be pilot on the
> next release; or let them be pilot and you be co-pilot.
> The proposal is that I think it would be great if we designated a pilot
> and co-pilot for every release cause that's pretty much the way every
> release has been done.  I've also noticed that the quality of release
> seems to be very tied to how closely the pilot and co-pilot work
> together (i.e. less is overlooked).
> What do you guys think?
> -David

View raw message