rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject RE: [DISCUSS] Apache Rave 0.6-incubating Release Candidate
Date Tue, 06 Dec 2011 16:05:47 GMT
>-----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. a
>>> 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?

>
>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 :)

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


Mime
View raw message