You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2012/06/30 01:43:04 UTC

[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

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

Re: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by Ate Douma <at...@douma.nu>.
On 07/02/2012 02:04 PM, Jasha Joachimsthal wrote:
> On 2 July 2012 10:53, Ate Douma <at...@douma.nu> wrote:
>
>> On 07/02/2012 10:00 AM, Jasha Joachimsthal wrote:
>>
>>> It's a good idea to postpone the release and work on fixing the issues
>>> first.
>>>
>>
>> While I agree on the latter, I'm not sure we should postpone the release
>> (0.13).
>>
>> As we're striving for a release every month I'd rather cancel/skip the
>> 0.13 release and focus on fixing the trunk (0.14-SNAPSHOT) instead so we
>> hopefully have a more stable and reliable 0.14 release end of this month.
>>
>> Postponing 0.13 would mean creating a separate branch based on the 0.13
>> tag and working towards a 0.13.1 release candidate (note that a 0.13-RC1 as
>> Chris proposed isn't really an option anymore as 0.13 already has been
>> tagged).
>>
>> All this seems like unnecessary extra work to me, unless some major other
>> changes were planned/targeted for trunk which cannot wait.
>> Instead, I propose canceling the 0.13 release and work towards a better
>> 0.14 release instead.
>>
>> Ate
>>
>>
> I'm okay with skipping the release and continue towards a stable 0.14 at
> the end of the month. Whoever wants a sticky revision can refer to the 0.13
> tag and create the artifacts themselves.
>
It looks like the discussion about the 0.13 release candidate has dried up and 
nobody voted for it either.

My conclusion then is that everybody (lazily) agrees with canceling this release 
and that we'll focus on improving and fixing the trunk instead.
The next planned release candidate then will be for version 0.14 end of this 
month.

I will drop the release candidate staging repository and remove the binary 
artifacts from the temporary rave builds folder on people.apache.org.

Thanks, Ate

>
>>
>>
>>> On 2 July 2012 00:09, Chris Geer <ch...@cxtsoftware.com> wrote:
>>>
>>>   On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <at...@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>
>>>>>>> <
>>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Re: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by Jasha Joachimsthal <ja...@apache.org>.
On 2 July 2012 10:53, Ate Douma <at...@douma.nu> wrote:

> On 07/02/2012 10:00 AM, Jasha Joachimsthal wrote:
>
>> It's a good idea to postpone the release and work on fixing the issues
>> first.
>>
>
> While I agree on the latter, I'm not sure we should postpone the release
> (0.13).
>
> As we're striving for a release every month I'd rather cancel/skip the
> 0.13 release and focus on fixing the trunk (0.14-SNAPSHOT) instead so we
> hopefully have a more stable and reliable 0.14 release end of this month.
>
> Postponing 0.13 would mean creating a separate branch based on the 0.13
> tag and working towards a 0.13.1 release candidate (note that a 0.13-RC1 as
> Chris proposed isn't really an option anymore as 0.13 already has been
> tagged).
>
> All this seems like unnecessary extra work to me, unless some major other
> changes were planned/targeted for trunk which cannot wait.
> Instead, I propose canceling the 0.13 release and work towards a better
> 0.14 release instead.
>
> Ate
>
>
I'm okay with skipping the release and continue towards a stable 0.14 at
the end of the month. Whoever wants a sticky revision can refer to the 0.13
tag and create the artifacts themselves.


>
>
>> On 2 July 2012 00:09, Chris Geer <ch...@cxtsoftware.com> wrote:
>>
>>  On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <at...@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>
>>>>>> <
>>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

Re: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by Ate Douma <at...@douma.nu>.
On 07/02/2012 10:00 AM, Jasha Joachimsthal wrote:
> It's a good idea to postpone the release and work on fixing the issues
> first.

While I agree on the latter, I'm not sure we should postpone the release (0.13).

As we're striving for a release every month I'd rather cancel/skip the 0.13 
release and focus on fixing the trunk (0.14-SNAPSHOT) instead so we hopefully 
have a more stable and reliable 0.14 release end of this month.

Postponing 0.13 would mean creating a separate branch based on the 0.13 tag and 
working towards a 0.13.1 release candidate (note that a 0.13-RC1 as Chris 
proposed isn't really an option anymore as 0.13 already has been tagged).

All this seems like unnecessary extra work to me, unless some major other 
changes were planned/targeted for trunk which cannot wait.
Instead, I propose canceling the 0.13 release and work towards a better 0.14 
release instead.

Ate

>
> On 2 July 2012 00:09, Chris Geer <ch...@cxtsoftware.com> wrote:
>
>> On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <at...@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
>>>>>
>>>>
>>>
>>>
>>
>

Re: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by Jasha Joachimsthal <ja...@apache.org>.
It's a good idea to postpone the release and work on fixing the issues
first.

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

> On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <at...@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
> >>>
> >>
> >
> >
>

Re: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by Chris Geer <ch...@cxtsoftware.com>.
On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <at...@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
>>>
>>
>
>

Re: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by Ate Douma <at...@douma.nu>.
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?


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

RE: [DISCUSS] Apache Rave 0.13 Release Candidate

Posted by "Franklin, Matthew B." <mf...@mitre.org>.
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...

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