On 12/06/2011 05:05 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: Ate Douma [mailto:[email protected]]
Sent: Tuesday, December 06, 2011 10:29 AM
To: [email protected]
Cc: [email protected]; 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:[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.
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
