incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vescovi, Matteo" <matteo.vesc...@iona.com>
Subject Re: Rules for a release vote.
Date Tue, 20 Feb 2007 16:45:18 GMT
Hi,

That was my understanding too.

My vote was in favour of creating a milestone release of all modules.

Creating a release with all modules should also require less time than 
cutting a new trimmed down release (i.e. once we sort out the tagging of 
our CXF dependency, we're pretty much done and we can call for a vote).


- Matteo


Nolan, Edell wrote:
> Hi,
>
> I was under the impression when I voted for the M2 release it was for a
> full release of all modules of Yoko. 
> Was I correct in my assumption ?
>
> Balaji the option of tagging CXF and making a yoko release on top of
> this tagged version 
> seems like a good solution to me. 
>
> Cheers, Edell.
>  
>
> -----Original Message-----
> From: Mosur Ravi, Balaji [mailto:bravi@iona.com] 
> Sent: 20 February 2007 16:15
> To: yoko-dev@incubator.apache.org
> Subject: RE: Rules for a release vote.
>
> I think in another discussion, there was a talk about not releasing yoko
> with just the ORB. (I don't think we reached any consensus!!!)
>
> So can we work on the option of tagging a version of CXF for out next
> release?
>
> This might be some work but I think it would solve both the issues.
> - Putting out a release for Geronimo
> - Not splitting up yoko just for the sake of a release.
>
>
> - Balaji
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Monday, February 19, 2007 1:54 PM
> To: yoko-dev@incubator.apache.org
> Subject: Re: Rules for a release vote.
>
>
> 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?
>
> thanks
> 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
>>>> daniel.kulp@iona.com
>>>>         
>> -- 
>> J. Daniel Kulp
>> Principal Engineer
>> IONA
>> P: 781-902-8727    C: 508-380-7194
>> daniel.kulp@iona.com
>>     
>
>   


Mime
View raw message