rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jasha Joachimsthal <ja...@apache.org>
Subject Re: [DISCUSS] Apache Rave 0.13 Release Candidate
Date Mon, 02 Jul 2012 08:00:37 GMT
It's a good idea to postpone the release and work on fixing the issues
first.

On 2 July 2012 00:09, Chris Geer <chris@cxtsoftware.com> wrote:

> On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <ate@douma.nu> wrote:
>
> > On 06/30/2012 05:25 PM, Franklin, Matthew B. wrote:
> >
> >> Unfortunately, I found a pretty big bug.  When we cut over to the new
> >> interface model, the rave-shindig classes began using the username as
> the
> >> opensocial id (similar to igoogle,etc) rather than the arbitrary
> database
> >> entity id.  Unfortunately, when I made those changes, I didn't update
> the
> >> security token classes in rave portal.  This means that any code in
> shindig
> >> that checks the security token id against the passed in userid will
> fail.
> >>  This primarily affects appdata; which, IMO is a pretty big deal..
> >>
> >> Apologies, but when you consider this with Ate's potential bug, I am not
> >> sure we should ship the release...
> >>
> >
> > Matt, thanks for finding and reporting this. I agree this seems like a
> > rather serious bug.
> >
> > I haven't had time yet over the weekend to dive deeper into RAVE-708 but
> > will try to find time for it coming days.
> >
> > The merge of the model interfaces changes, the upgrade to OpenJPA 2.2.0,
> > and on top of that, the upgrade to shindig 2.5.0-beta2, all happened in
> the
> > last week. Overall this release gives me a bit uneasy feeling of being
> > (too) unstable/unreliable and certainly as not enough tested.
> >
> > I'd like to hear others opinion on it, but I'm currently inclined to say
> > we should hold off/cancel shipping this release.
> >
> > Maybe we should take the coming weeks to better validate and fix/improve
> > the quality and reliability instead of keep rushing in more major
> changes.
> > As well as JIRA could use a bit of scrubbing and cleaning up of
> > old/outstanding issues I think.
> >
> > We are also entering the summer holiday period (I myself will be 3 weeks
> > away after next week) so maybe we should anticipate a bit slower progress
> > anyway or at least lesser time or eyes available for properly review and
> > test major changes.
> >
> > All in all, I'm hesitant to push out a lesser tested/validated 0.13
> > (unlucky?) version out.
> >
> > WDYT?
>
>
> I don't have a problem delaying this release. If there are some features
> people really want from a non-SNAPSHOT version we could always tag this as
> 0.13-RC1 or something like that since it does have a lot of good stuff in
> it. I guess it depends on the length of the delay. Two things I'd like to
> see happening are expanding both Jasmine and integration tests. It would be
> nice if we could get automated test coverage for the issues we found this
> go around.
>
> On that note, I've been looking into the Jasmine tests and have hit a snag.
> I'd like to have more of the jQuery capabilities available in the tests, in
> case we want to use more of jQuery in Rave. Right now we are stubbing out
> the $ variable with just the bare minimum of what we need. Is there a way
> we can use the real jQuery library and just overwrite the things we need to
> tweak?
>
> Chris
>
> >
> >
> >
> >
> >>  -----Original Message-----
> >>> From: Ate Douma [mailto:ate@douma.nu]
> >>> Sent: Friday, June 29, 2012 7:43 PM
> >>> To: dev@rave.apache.org
> >>> Subject: [DISCUSS] Apache Rave 0.13 Release Candidate
> >>>
> >>> Discussion thread for vote on 0.13 release candidate.
> >>>
> >>> For more information on the release process, checkout -
> >>> http://www.apache.org/dev/**release.html<
> http://www.apache.org/dev/release.html>
> >>>
> >>> Some of the things to check before voting are:
> >>> - can you run the demo binaries
> >>> - can you build the contents of source-release.zip and svn tag
> >>> - do all of the staged jars/zips contain the required LICENSE and
> NOTICE
> >>> files
> >>> - are all of the staged artifacts signed and the signature verifiable
> >>> - is the signing key in the project's KEYS file and on a public server
> >>>
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message