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 18:53:57 GMT

On Feb 19, 2007, at 10:17 AM, Daniel Kulp wrote:

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

That makes a lot of sense :-)
>> -- 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.

How about "embedded" and "full" profiles and we run the mvn release  
plugin on the "embedded" profile?

btw is yoko using mvn 2.0.5 yet?

david jencks

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