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:[email protected]]

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

I've now created a patch which, if needed, can be applied also to the 0.6-incubating release/tag sources as well as has been applied already to trunk.
See: https://issues.apache.org/jira/browse/RAVE-382

Based on this fix and documented workaround for (only) the 0.6-incubating binary demo (see RAVE-382), I'm going to vote +1 on this release candidate now, under the provision we'll provide an updated README (or add a RELEASE_NOTES?) with the release, both in the binary distribution and on the website. This should also point users to RAVE-382 and its patch with instructions how to manually fix the releases sources if needed.

Regards,

Ate

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


Reply via email to