incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Rules for a release vote.
Date Mon, 19 Feb 2007 17:02:47 GMT
A couple quick comments

-- I recall some incubating project (activemq?) being told that they  
could start release votes for themselves and the incubator  
simultaneously, thus having both 72 hr waits run concurrently.

-- I'm really worried about the cxf snapshot dependency.  IMO we  
absolutely need to avoid releasing yoko bits that depend on cxf or  
get something stable from cxf that we can release against.  If the  
bits of cxf yoko needs are actually quite stable and basically done  
then perhaps cxf could make a milestone release of those bits.   
Otherwise I don't think we should be releasing something that depends  
on code we know is unstable.

david jencks

On Feb 19, 2007, at 7:32 AM, Daniel Kulp wrote:

> On Monday 19 February 2007 06:35, Rick McGuire wrote:
>> I'm not sure I've got the terminology correct here, but what are the
>> voting rules for an incubating project to cut a release.  What are  
>> the
>> binding votes required for the vote to pass (i.e, do we need to nudge
>> the project mentors to vote on this)?
> From my understanding, this is what will need to be done:
> 1) Get some sort of tagged/reproducable snapshot of CXF.   This can  
> be done
> one of two ways:
>    a) you can tag (svn cp) the cxf version into your own tags dir,  
> modify the
> version numbers, and build/deploy a snapshot from there.
>    b) convince a cxf developer to do it from their tree.   I could  
> possibly do
> this late tomorrow if need be.
> The important thing is to get a version that is known and  
> reproducable.   I'd
> suggest a version with the SVN number in the version number.
> 2) Tag your own codebase, update version numbers, etc... (since you  
> depend on
> snapshots, you cannot use the mvn release plugin)   Build and  
> deploy to a
> staging area. (/home/user/public_html/yoko_m2 on people or  
> similar)  One
> note: don't deploy javadocs jars.  (or rm them before the vote)   
> With your
> setup, those jars don't have the required NOTICE/LICENSE/DISCLAIMER  
> in them
> so they aren't releasable.    If you wait another 3 or 4 days, that  
> will be
> fixable.
> 3) Call a vote on that here.   Wait 72 hours.
> 4) Call a vote on general@.   Wait at least 72 hours.   This was a  
> major
> holdup last time.   Once you call a vote, I'd start asking the  
> Harmony and
> Geronimo folks that are on the IPMC to get a in vote asap.  You  
> need the 3
> +1's.
> Anyway, if you start right now, at a minimum, that's 6 days before  
> a release.
> More likely: 8-10 days.
> -- 
> J. Daniel Kulp
> Principal Engineer
> P: 781-902-8727    C: 508-380-7194

View raw message