incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Rules for a release vote.
Date Tue, 20 Feb 2007 17:01:04 GMT
I agree as well, the vote was releasing Yoko in total.  I think that  
in the future, we should cut the release and vote on that so that  
there is no confusion as to what we're voting on.


Regards,
Alan

On Feb 20, 2007, at 8:45 AM, Vescovi, Matteo wrote:

> 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