rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
Date Tue, 06 Dec 2011 16:10:50 GMT
On 12/06/2011 05:05 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Tuesday, December 06, 2011 10:29 AM
>> To: rave-dev@incubator.apache.org
>> Cc: hadrian@apache.org; Ross Gardler; Sylvain Wallez; Upayavira
>> Subject: Re: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
>> On 12/06/2011 03:54 PM, Ate Douma wrote:
>>> On 12/06/2011 02:49 PM, Ciancetta, Jesse E. wrote:
>>>>> -----Original Message-----
>>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> <snip>
>>>>> I'm now unsure if I should vote +1 or -1 on this release.
>>>>>  From a release process POV, disregarding execution, this release
>> candidate
>>>>> seems valid to me.
>>>>> But I personally cannot use this release, nor the current trunk for that
>> matter.
>>>>> So, to me this feels like a -1 on usability.
>>>> I think since the problem really comes down to a configuration issue vs.
>>>> code issue, then as long as we document the issue and how to work
>> around it
>>>> then IMO we could proceed with the release.
>>> Agree, like I also said on my other response to Matt's email.
>>> One workaround I just tested successfully is the following (*only* needed
>>> if/when you hit the initialization order bug):
>>> 0) $ rm /tmp/rave*
>>> 1) before starting tomcat for the first time, temporarily remove
>>> $TOMCAT/webapps/ROOT.war
>>> 2) start Tomcat for the first time and once started, stop it again
>>> 3) move ROOT.war back under $TOMCAT/webapps/
>>> 4) now you can start up tomcat as often again.
>>> Until you want to reset the database again, then rewind back to step 0)
>>> If everyone agrees this is an acceptable workaround, for this release
>> candidate
>>> only, and properly documented in the README, I'm OK voting +1 on
>> candidate.
> Sounds fair to me, though editing the Readme would entail repacking the binaries.  Is
that acceptable, or should we just note it on the download page?
IMO repackaging the binaries for a single (non-code related) file has been 
discussed just last week on general@ and found acceptable by most/silent 
consent. So I would +1 that.
Especially when (before) we go to general@ for the final vote there, but it 
should be mentioned as such in that vote mail.

>> BTW: I think it would be good and wise to have backing of this, and the release
>> candidate as a whole, from at least two other Rave mentors as well.
>> We can postpone and wait on that when promoting the vote to
>> general@incubator,
>> but I'd prefer have their backing upfront :)
> Agreed, I planned on keeping the vote open until we got the votes.  General@ is swamped
and we may not get the votes we need until after the 0.7-incubating release :)
I would hope for a quicker conclusion than that, but we'll wait and see :)

>> So, @Hadrian, @Ross, @Sylvain, @Upayavira, all extra notified on the cc:
>> if you have time, please review this release candidate as well as this
>> discussion around it!
>>> Ate
>>>> Or stated another way -- I don't see any reason why other projects that
>> have
>>>> been building on Rave should have to miss out on this release due to a
>>>> configuration problem which probably wouldn't even affect them (or if it
>> did,
>>>> with proper documentation of known issues for the release, could be
>> easily
>>>> worked around).
>>>>> Just to be clear: regardless my vote, if you get a majority and +3 IPMC
>> votes
>>>>> this release can be regarded successfully.
>>>>> Ate

View raw message