Mailing-List: contact dev-help@rave.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@rave.apache.org
Received-SPF: pass (athena.apache.org: domain of jashaj@gmail.com designates
 209.85.160.53 as permitted sender)
MIME-Version: 1.0
Sender: jashaj@gmail.com
In-Reply-To: <4FF16190.7010409@douma.nu>
References: <4FEE3D88.4070306@douma.nu>
 <2E45169E9A237B4DA78078A68962F9EF01606F7E@IMCMBX01.MITRE.ORG>
 <4FF0C72F.9060602@douma.nu>
 <CAFNO4Hgyy_-uwtdCs=egQZMpy5B5ZGcGgbri5Fvpx0gMOXrCrA@mail.gmail.com>
 <CAE=UxW-W8Kmx=TQP1y9FHNLZODVcscjFGhnX=645fratbuSCcA@mail.gmail.com>
 <4FF16190.7010409@douma.nu>
From: Jasha Joachimsthal <jasha@apache.org>
Date: Mon, 2 Jul 2012 14:04:24 +0200
Message-ID: 
 <CAE=UxW9D+euZJ6W2LWtNg2TrMCwnsNK29xk-5GgBa9L+nSdmBg@mail.gmail.com>
Subject: Re: [DISCUSS] Apache Rave 0.13 Release Candidate
To: dev@rave.apache.org
Content-Type: multipart/alternative; boundary=047d7b33d7c888078704c3d79a19

--047d7b33d7c888078704c3d79a19
Content-Type: text/plain; charset=ISO-8859-1

On 2 July 2012 10:53, Ate Douma <ate@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 <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>
>>>>>> <
>>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

--047d7b33d7c888078704c3d79a19--