incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Rules for a release vote.
Date Mon, 19 Feb 2007 18:17:18 GMT
On Monday 19 February 2007 12:02, David Jencks wrote:
> 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.

Yea.  However, IMO, that didn't work very well.   There was some confusion as 
to where the votes went.   There were IPMC members that didn't vote 
specifically because they didn't want their vote influencing the PPMC votes.  
(they want the PPMC to function by themselves as much as possible)  Etc...   

I wouldn't recommend going that route unless it's somewhat of an emergency 
(security patch or similar).   The "cleanest" route is the Yoko PPMC gets it 
ready to their satisfaction and the IPMC then validates it.

> -- 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.

Well, from the CXF teams standpoint, there isn't a way we would release a 
milestone based on the latest code.   There are things that are in major flux 
right now.   Actually, I think some stuff that was committed on 
Friday/Saturday may have broken Yoko.   Not sure yet, but I'm not going to 
deploy another CXF snapshot until I double check.   

Thus, the options are really:
1) CXF team tags, builds, and deploys a snapshot based on a specific SVN 
version number.  2.0-incubator-509280-SNAPSHOT for example.  

2) Yoko team pretty much does that instead of CXF.  

3) Create a "coreorb" or "embedded" assembly.   I was talking to Balaji about 
this on Friday.   Basically, in distribution, have 
an "yoko-incubating-M2-embedded.tar.gz"   thing along with the current full 
source/bin builds.   This may make sense long term anyway.   For this 
release, ONLY release the embedded stuff.   (basically, deploy to a staging 
area, then delete all the stuff you aren't planning on releasing before the 
votes)  In the future (1.0 or M3), when things stabilize, everything would be 
released together, both the embedded versions and the full versions.


> thanks
> 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
> > IONA
> > P: 781-902-8727    C: 508-380-7194
> >

J. Daniel Kulp
Principal Engineer
P: 781-902-8727    C: 508-380-7194

View raw message