geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Getting releases out
Date Wed, 20 Sep 2006 11:11:57 GMT

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
matt@hogstrom.org




Mime
View raw message