Re: releasing: it takes two
On Jan 20, 2006, at 12:20 PM, Jeff Genender wrote:
I agree with this. The release can be difficult at best. And I
appreciate you giving me *much* more credit that is due...you did a
lot
more than just a co-pilot (perhaps I should be scolding you for giving
me more credit than is due) ;-)
Well it was the first time we tried someone else as pilot. Learning
experience for us all. I'm thinking it probably wasn't fair to put
you or Matt in the pilot seat without having co-piloted a release
first, but then again that may be the best way to learn. Time will
tell I guess.
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.
You said a keyword ("peer") that just made me go "duh!" This is
pretty much peer programming but for releases. Not really a new
concept.
-David
Jeff
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
Re: releasing: it takes two
I agree with this. The release can be difficult at best. And I appreciate you giving me *much* more credit that is due...you 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. Jeff 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
releasing: it takes two
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
