rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject Re: [DISCUSS] Apache Rave 0.10 Release Candidate
Date Mon, 09 Apr 2012 13:51:12 GMT

On 4/9/12 9:46 AM, "Raminderjeet Singh" <raminderjsingh@gmail.com> wrote:

>As the fix is already part of trunk and we did not create any branch so
>what should i do to create build. Shall i create a tag 0.10.1 from trunk
>and create the release. As the trunk pom's are already at 0.11-snaphot, i
>need to careful not to update them again i release process.

Since the fix is in place in trunk, IMO we no longer need to branch.  You
could release 0.10.1 right now out of trunk without any need to change
poms.  Just make sure you set the development version to 0.11-SNAPSHOT
when prompted by the release plugin...

> 
>
>Thanks
>Raminder
>
>
>On Apr 9, 2012, at 6:46 AM, Jasha Joachimsthal wrote:
>
>> Tested the portal and it works again. Thanks for fixing it.
>> 
>> 
>> On 6 April 2012 20:37, Mahadevan, Venkat <venkatm@mitre.org> wrote:
>> 
>>> Fixed the issue. Please let me know otherwise.
>>> 
>>> 
>>> Venkat
>>> 
>>> 
>>> On 4/6/12 9:19 AM, "Mahadevan, Venkat" <venkatm@mitre.org> wrote:
>>> 
>>>> Jasha, I will work on RAVE-541 and fix the issue
>>>> 
>>>> 
>>>> 
>>>> On 4/6/12 6:26 AM, "Jasha Joachimsthal" <j.joachimsthal@onehippo.com>
>>>> wrote:
>>>> 
>>>>> On 6 April 2012 10:46, Ate Douma <ate@douma.nu> wrote:
>>>>> 
>>>>>> On 04/06/2012 10:41 AM, Ate Douma wrote:
>>>>>> 
>>>>>>> I've got two remarks so far:
>>>>>>> 
>>>>>>> a) This release candidate is dependent on the non-yet released
>>>>>>> rave-master-0.10,
>>>>>>> which I don't like much.
>>>>>>> 
>>>>>>> IMO it would have been better to wait another day until the
>>>>>>> rave-master
>>>>>>> was
>>>>>>> formally released. Although the rave-master release most certainly
>>>>>>> will
>>>>>>> commence, in theory if we find a last minute blocker issue with
it
>>>>>>> causing its
>>>>>>> release to be failed, it would cause *this* release candidate
then
>>>>>>>to
>>>>>>> fail
>>>>>>> automatically as well...
>>>>>>> 
>>>>>>> b) Issue RAVE-553 just reported by Jasha and also confirmed by
>>>>>>>myself
>>>>>>> makes the
>>>>>>> release useless for all practical use-cases and most certainly
>>>>>>>should
>>>>>>> have been
>>>>>>> easily tested/found before the release. We should look into
>>>>>>>improving
>>>>>>> our
>>>>>>> quality assurance and add some minimal but sensible (interaction)
>>>>>>> testing
>>>>>>> plan
>>>>>>> which should pass before we cut a release candidate because this
is
>>>>>>> quite
>>>>>>> annoying.
>>>>>>> 
>>>>>>> For b) I'm inclined to vote -1 or at least -0. As I haven't had
>>>>>>>time
>>>>>>> to
>>>>>>> further
>>>>>>> review I'll postpone casting my vote for now but it doesn't look
>>>>>>>rosy
>>>>>>> to
>>>>>>> me.
>>>>>>> 
>>>>>> 
>>>>>> BTW: just want to make clear, especially for Raminder, I consider
b)
>>>>>> and
>>>>>> the need for improving on our quality assurance a responsibility
of
>>>>>>the
>>>>>> team, including myself, not one of the release-manager who but must
>>>>>> execute
>>>>>> and ascertain this.
>>>>> 
>>>>> 
>>>>> If I revert the commit in
>>>>>https://issues.apache.org/jira/browse/RAVE-541
>>>>> I
>>>>> can create new users again. I don't know what the intention of this
>>>>> feature
>>>>> was, but the result is that it creates a new PROFILE page instead of
>>>>>a
>>>>> new
>>>>> USER page. The portal cannot handle a user without a user page. The
>>>>> portal
>>>>> can however render a profile page if no profile page is present yet
>>>>>for
>>>>> that user.
>>>>> 
>>>>> We have multiple options:
>>>>> 0. accept the 0.10 release, but I also doubt between -0 and -1
>>>>> 1. reject the 0.10 release, fix or revert the issue, no new release
>>>>>until
>>>>> the end of the month
>>>>> 2. reject the 0.10 release, revert the commit done for RAVE-541 and
>>>>> create
>>>>> a new 0.10.1 release after the rave-master pom has been released
>>>>> 3. reject the 0.10 release, fix the RAVE-541 issue and create a new
>>>>> 0.10.1
>>>>> release after the rave-master pom has been released
>>>>> 
>>>>> For option 2 & 3 we don't want other new features in the 0.10.1
>>>>>release
>>>>> so
>>>>> either
>>>>> a. hold all commits until the issue RAVE-541 has been resolved or
>>>>> reverted.
>>>>> Create a release from trunk (0.11-SNAPSHOT -> 0.10.1 ->
>>>>>0.11-SNAPSHOT)
>>>>> b. create a branch from 0.10 tag (0.10.1-SNAPSHOT), fix or revert
>>>>> RAVE-541,
>>>>> release from the branch (0.10.1-SNAPSHOT -> 0.10.1 ->
>>>>>0.10.2-SNAPSHOT).
>>>>> Merge the fix into trunk (0.11-SNAPSHOT)
>>>>> 
>>>>> @Venkat (or whoever can fix the issue and knows what the intention
>>>>>was):
>>>>> in
>>>>> case we want a 0.10.1 release, do you think you can fix this issue
>>>>>soon,
>>>>> shall we first revert your commit and give you more time to solve it?
>>>>> 
>>>>> Jasha
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Ate
>>>>>>> 
>>>>>>> 
>>>>>>> On 04/06/2012 02:51 AM, Raminderjeet Singh wrote:
>>>>>>> 
>>>>>>>> This is discussion thread for vote on Apache Rave Project
0.10
>>>>>>>> Release
>>>>>>>> Candidate
>>>>>>>> 
>>>>>>>> For more information on the release process, checkout -
>>>>>>>> 
>>>>>>>> 
>>>>>>>> http://rave.apache.org/**release-management.html<
>>> http://rave.apache.or
>>>>>>>> g
>>>>>>>> /release-management.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,
>>>>>>>>NOTICE
>>>>>>>> and
>>>>>>>> DISCLAIMER files
>>>>>>>> - are all of the staged jars signed and the signature verifiable
>>>>>>>> - is the signing key in the project's KEYS file and on a
public
>>>>>>>> server
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>


Mime
View raw message