On Sep 19, 2006, at 9:25 PM, Dain Sundstrom wrote:
I have been poking around at the release stuff for a few days and feel
I have an understanding of the necessary steps to get a release out.
Unfortunately, there seem to be loads of items on the check list. In
order to keep myself sane, I have divided them into three areas:
schedule, mechanics and certification... a description of each
follows. I greatly appreciate any comments and questions.
Thanks,
-dain
Schedule
Based on the feedback from the poll, we are going to feature-box our
releases. This means we need come to an agreement on what is in the
1.2 release. I will start another email thread to discuss the 1.2
feature set and priorities. Once we know the required feature set we
will be able to track the progress of the release based on the
completed features.
Mechanics
The maven configuration, shell scripts, review process and voting
procedure for a release are all quite complex and can have a big
impact on the release. I think this area will benefit greatly from
practicing and iterative improvement. I'd like to start by posting a
binary each Wednesday to
http://people.apache.org/dist/geronimo/unstable/ and every week add at
least one improvement to the process. Starting with tomorrow here is
what I'd like to improve for the next few weeklies:
9/20 - Simply get the first binary posted with a change log
swizzled from JIRA
9/27 - Add a script or maven config to change the version number of G
to 1.2-${svn rev}
10/4 - Practice the review and voting process by pushing a voted upon
monthly snapshot (just an idea)
One of the things I've noticed from previous releases is that few
people actually pull the release and give it a go. Or, when the
first problem is noted everyone stops only to find the next problem
after several days of voting. We all need to complete as much
testing as possible up front otherwise the voting takes forever.
1.1.1 for instance was done by around August 10th and didn't ship
until September 18th. The code development was faster than the
release process. Part of that was latent issues that should have
been identified years ago (like missing LICENSES / NOTICES, etc.).
Hopefully most of that is behind us now :)
Hopefully, I'll be able to con a few of you in to help tune some parts
of the release process. If you have some free cycles, and want to
help with build/release stuff, please jump in and help.
Certification
In
the future, I'd like to move us to a continuous TCK testing mode where
we get a report every morning indicating whether or not the previous
day's commits broke anything. For now, I'd love to have our weekly
binaries tested and get results within a few days.
Since TCK generally takes a few days to run it might make sense to
include more than one OS. So we could do a Windows, Linux, Solaris
x86 in a rotating cycle. This would get results every day and we'd
also make sure we weren't running into wierd OS issues that pop up
periodically.
This also means that we need all committers to sign the NDA for the
TCK so they have access to the results. At least it would be nice to
have everyone disclosed.
Matt Hogstrom
[EMAIL PROTECTED]
