You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Alejandro Fernandez <al...@apache.org> on 2014/09/29 22:35:59 UTC
Preparing Ambari 1.7.0 branch
Hi developers and PMCs,
I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3 at 2
pm Pacific Time, as per the outlined tasks in the Ambari Feature + Roadmap
page (
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705).
After making the branch, we (i.e., development community) should only
accept blocker or critical bug fixes into the branch and harden it until it
meets a high enough quality bar (roughly around 4 weeks, and subject to
change).
To further improve the stability of the release branch, we will require all
checkins into Ambari 1.7.0 to be reviewed by at least two committers and
unit-tested & system-tested.
If you have a bug fix, it should first be committed to trunk, and after
ensuring that it does not break any tests (including smoke tests), then it
should be integrated to the Ambari 1.7.0 branch.
If you have any doubts whether a fix should be committed into the 1.7.0
branch, please email me for input at alejandro@apache.org
Stay tuned for updates on the release process.
Thank you,
Alejandro Fernandez
Ambari 1.7.0 Release Manager
Re: Preparing Ambari 1.7.0 branch
Posted by Chandrasekhar Gopal <cg...@pivotal.io>.
This issue has already been reported by Jun.
https://issues.apache.org/jira/browse/AMBARI-7622
So we are good in terms of having consistent results for the builds off
trunk and branch-1.7.0.
On Fri, Oct 3, 2014 at 4:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
wrote:
> Enabled the Jenkins Job on b.a.o for branch-1.7.0. Manually triggered
> the first build.
>
>
>
> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/1/consoleFull
>
> I noticed that the following test failed for Ambari-Server. Looking to
> see if this issue has already been reported.
>
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.041 sec
>
> Results :
>
> Failed tests: testOpFailedEventRaisedForAbortedHostRole(org.apache.ambari.server.actionmanager.TestActionScheduler): expected:<ABORTED> but was:<PENDING>
>
> Tests run: 2076, Failures: 1, Errors: 0, Skipped: 16
>
>
> The same failure occurs on the trunk build also.
> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-trunk-Commit/477/
>
>
>
> @Jun: Thanks for all the help !
>
> -Chandra
>
>
>
>
> On Fri, Oct 3, 2014 at 2:33 PM, Alejandro Fernandez <al...@apache.org>
> wrote:
>
>> The release candidate branch-1.7.0 is ready.
>>
>> git pull
>> git branch --remote
>>
>> Thanks,
>> Alejandro Fernandez
>>
>> On Fri, Oct 3, 2014 at 1:46 PM, Chandrasekhar Gopal <cg...@pivotal.io>
>> wrote:
>>
>>> With Jun's help, we have a created a build for branch-1.7.0 on b.a.o.
>>>
>>> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/
>>>
>>> This build is currently disabled. Once we get the green signal from
>>> Alejandro with regards to the completion of the branch creation for 1.7.0,
>>> I'll enable and test the build out.
>>>
>>> I have updated https://issues.apache.org/jira/browse/AMBARI-7565
>>>
>>> Chandra
>>>
>>>
>>> On Fri, Oct 3, 2014 at 10:35 AM, Alejandro Fernandez <
>>> alejandro@apache.org> wrote:
>>>
>>>> I was thinking of adding a page to the wiki entitled "Developer
>>>> Workflow", this can contain the diagram that Jun Aoki started, plus our
>>>> guideline/expectations for release candidate branches.
>>>>
>>>> For the release candidate, all Jiras must have a Fix-Version of 1.7.0;
>>>> whereas Jiras for the trunk branch can target 2.0.0. An empty Fix-Version
>>>> is typically used for the backlog (unless we create a Backlog Fix-Version).
>>>>
>>>> Thanks,
>>>> Alejandro Fernandez
>>>>
>>>> On Thu, Oct 2, 2014 at 4:20 PM, Sumit Mohanty <smohanty@hortonworks.com
>>>> > wrote:
>>>>
>>>>> Is the definition of Blocker/Critical etc. standard - if not can you
>>>>> host it in Ambari wiki.
>>>>>
>>>>> Also, I assume the Fix Version/s should include 1.7.0.
>>>>>
>>>>> This brings up another question -
>>>>>
>>>>> What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is
>>>>> it empty or we have a version number for post 1.7.0?
>>>>>
>>>>> -Sumit
>>>>>
>>>>> On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <
>>>>> alejandro@apache.org> wrote:
>>>>>
>>>>>> I propose using the "severity" field.
>>>>>>
>>>>>> All Jiras with a severity of "blocker" or "critical" should make it
>>>>>> into
>>>>>> 1.7.0, and I will send periodic emails with the state of the release
>>>>>> (#
>>>>>> blockers, # critical, # major, etc.)
>>>>>> It is up to the developers to contact me if they want to bring up the
>>>>>> discussion of a Jira that may need to increase its severity. I will
>>>>>> act as
>>>>>> a funnel to involve the right folks, and potentially involve the dev
>>>>>> community when required.
>>>>>> For this reason, we need to have a consistent understanding of what
>>>>>> the
>>>>>> severities mean,
>>>>>>
>>>>>> *Blocker *- Blocker type issues are the most critical issues. You
>>>>>> will not
>>>>>> be able to use the product if this type of issue occurs.
>>>>>> Example: Unable to log on to the system.
>>>>>>
>>>>>> *Critical *- This type of issue is critical to the system and you
>>>>>> need to
>>>>>> attend to these issues as soon as possible.
>>>>>> Example: An exception occurring when performing a particular function,
>>>>>> (i.e., adding a user to the system)
>>>>>>
>>>>>> *Major *- Issues that are important and should be fixed but does not
>>>>>> stop
>>>>>> the rest of the system from functioning.
>>>>>> Example: When adding one record, the same record gets added twice.
>>>>>>
>>>>>> *Minor *- These issues have a relatively minor impact on the product
>>>>>> but
>>>>>> needs to be fixed.
>>>>>> Example: Wrong message being displayed when some action is performed.
>>>>>>
>>>>>> *Trivial *- Trivial issues have the least impact on the product.
>>>>>>
>>>>>> Example: Spelling error in an error message, GUI Issues, etc.
>>>>>>
>>>>>> Generally, we should consider fixing "major" issues if we
>>>>>> 1. Eliminated all or nearly all blocker/critical issues (since these
>>>>>> have a
>>>>>> higher priority)
>>>>>> 2. Have high confidence that the fix is not introducing regressions,
>>>>>> have a
>>>>>> good understanding of all of its side-effects, and the fix does not
>>>>>> product
>>>>>> a lot of code-churn or change too many lines
>>>>>> 3. Have enough time to let the fix stabilize and fully understand how
>>>>>> to
>>>>>> unit and system test it
>>>>>>
>>>>>> Thanks,
>>>>>> Alejandro Fernandez
>>>>>>
>>>>>> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <
>>>>>> cgopal@pivotal.io>
>>>>>> wrote:
>>>>>>
>>>>>> > Alejandro,
>>>>>> > Had a quick question with regards to the criteria/specifics for
>>>>>> bug-fixes
>>>>>> > making it to the 1.7.0 branch. Do we need to add a label (such as
>>>>>> GA
>>>>>> > Blocker) to the JIRA tickets? Or do they need to have a certain
>>>>>> level of
>>>>>> > Severity?
>>>>>> >
>>>>>> > Thanks !
>>>>>> > Chandra
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
>>>>>> alejandro@apache.org
>>>>>> > > wrote:
>>>>>> >
>>>>>> >> Friendly reminder that we will make the Ambari 1.7.0 branch on
>>>>>> Friday at
>>>>>> >> 2 pm Pacific Time. After the cut-off, we will require all bug
>>>>>> fixes to
>>>>>> >> first be committed to trunk, ensure that nothing breaks, and then
>>>>>> integrate
>>>>>> >> it into the release branch.
>>>>>> >>
>>>>>> >> All bug fixes meant for the release branch must be reviewed by at
>>>>>> least 2
>>>>>> >> people on Review Board, unit-tested, and system-tested.
>>>>>> >> Please don't hesitate to contact me if you have any questions.
>>>>>> >>
>>>>>> >> Stay tuned for more updates once the release candidate (will be
>>>>>> named
>>>>>> >> branch-1.7.0) is made and we have builds running on Apache.
>>>>>> >>
>>>>>> >> Thank you,
>>>>>> >> Alejandro Fernandez
>>>>>> >> Ambari 1.7.0 Release Manager
>>>>>> >>
>>>>>> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
>>>>>> >> alejandro@apache.org> wrote:
>>>>>> >>
>>>>>> >>> Hi developers and PMCs,
>>>>>> >>>
>>>>>> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday
>>>>>> October 3
>>>>>> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari
>>>>>> Feature +
>>>>>> >>> Roadmap page (
>>>>>> >>>
>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>>>>>> >>> ).
>>>>>> >>>
>>>>>> >>> After making the branch, we (i.e., development community) should
>>>>>> only
>>>>>> >>> accept blocker or critical bug fixes into the branch and harden
>>>>>> it until it
>>>>>> >>> meets a high enough quality bar (roughly around 4 weeks, and
>>>>>> subject to
>>>>>> >>> change).
>>>>>> >>> To further improve the stability of the release branch, we will
>>>>>> require
>>>>>> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
>>>>>> committers
>>>>>> >>> and unit-tested & system-tested.
>>>>>> >>>
>>>>>> >>> If you have a bug fix, it should first be committed to trunk, and
>>>>>> after
>>>>>> >>> ensuring that it does not break any tests (including smoke
>>>>>> tests), then it
>>>>>> >>> should be integrated to the Ambari 1.7.0 branch.
>>>>>> >>>
>>>>>> >>> If you have any doubts whether a fix should be committed into the
>>>>>> 1.7.0
>>>>>> >>> branch, please email me for input at alejandro@apache.org
>>>>>> >>>
>>>>>> >>> Stay tuned for updates on the release process.
>>>>>> >>>
>>>>>> >>> Thank you,
>>>>>> >>> Alejandro Fernandez
>>>>>> >>> Ambari 1.7.0 Release Manager
>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Chandrasekhar Gopal
>>>>>> > Pivotal Hadoop -- Build, Release and Deployments
>>>>>> > cgopal@gopivotal.com
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE
>>>>> NOTICE: This message is intended for the use of the individual or
>>>>> entity to which it is addressed and may contain information that is
>>>>> confidential, privileged and exempt from disclosure under applicable law.
>>>>> If the reader of this message is not the intended recipient, you are hereby
>>>>> notified that any printing, copying, dissemination, distribution,
>>>>> disclosure or forwarding of this communication is strictly prohibited. If
>>>>> you have received this communication in error, please contact the sender
>>>>> immediately and delete it from your system. Thank You.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Chandrasekhar Gopal
>>> Pivotal Hadoop -- Build, Release and Deployments
>>> cgopal@gopivotal.com
>>>
>>
>>
>
>
> --
> Chandrasekhar Gopal
> Pivotal Hadoop -- Build, Release and Deployments
> cgopal@gopivotal.com
>
--
Chandrasekhar Gopal
Pivotal Hadoop -- Build, Release and Deployments
cgopal@gopivotal.com
Re: Preparing Ambari 1.7.0 branch
Posted by Yusaku Sako <yu...@hortonworks.com>.
Great. Thanks Chandra!
Yusaku
On Fri, Oct 3, 2014 at 4:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
wrote:
> Enabled the Jenkins Job on b.a.o for branch-1.7.0. Manually triggered
> the first build.
>
>
>
> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/1/consoleFull
>
> I noticed that the following test failed for Ambari-Server. Looking to see
> if this issue has already been reported.
>
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.041 sec
>
> Results :
>
> Failed tests:
>
> testOpFailedEventRaisedForAbortedHostRole(org.apache.ambari.server.actionmanager.TestActionScheduler):
> expected:<ABORTED> but was:<PENDING>
>
> Tests run: 2076, Failures: 1, Errors: 0, Skipped: 16
>
>
> The same failure occurs on the trunk build also.
> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-trunk-Commit/477/
>
>
>
> @Jun: Thanks for all the help !
>
> -Chandra
>
>
>
>
> On Fri, Oct 3, 2014 at 2:33 PM, Alejandro Fernandez <al...@apache.org>
> wrote:
>
> > The release candidate branch-1.7.0 is ready.
> >
> > git pull
> > git branch --remote
> >
> > Thanks,
> > Alejandro Fernandez
> >
> > On Fri, Oct 3, 2014 at 1:46 PM, Chandrasekhar Gopal <cg...@pivotal.io>
> > wrote:
> >
> >> With Jun's help, we have a created a build for branch-1.7.0 on b.a.o.
> >>
> >> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/
> >>
> >> This build is currently disabled. Once we get the green signal from
> >> Alejandro with regards to the completion of the branch creation for
> 1.7.0,
> >> I'll enable and test the build out.
> >>
> >> I have updated https://issues.apache.org/jira/browse/AMBARI-7565
> >>
> >> Chandra
> >>
> >>
> >> On Fri, Oct 3, 2014 at 10:35 AM, Alejandro Fernandez <
> >> alejandro@apache.org> wrote:
> >>
> >>> I was thinking of adding a page to the wiki entitled "Developer
> >>> Workflow", this can contain the diagram that Jun Aoki started, plus our
> >>> guideline/expectations for release candidate branches.
> >>>
> >>> For the release candidate, all Jiras must have a Fix-Version of 1.7.0;
> >>> whereas Jiras for the trunk branch can target 2.0.0. An empty
> Fix-Version
> >>> is typically used for the backlog (unless we create a Backlog
> Fix-Version).
> >>>
> >>> Thanks,
> >>> Alejandro Fernandez
> >>>
> >>> On Thu, Oct 2, 2014 at 4:20 PM, Sumit Mohanty <
> smohanty@hortonworks.com>
> >>> wrote:
> >>>
> >>>> Is the definition of Blocker/Critical etc. standard - if not can you
> >>>> host it in Ambari wiki.
> >>>>
> >>>> Also, I assume the Fix Version/s should include 1.7.0.
> >>>>
> >>>> This brings up another question -
> >>>>
> >>>> What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is
> >>>> it empty or we have a version number for post 1.7.0?
> >>>>
> >>>> -Sumit
> >>>>
> >>>> On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <
> >>>> alejandro@apache.org> wrote:
> >>>>
> >>>>> I propose using the "severity" field.
> >>>>>
> >>>>> All Jiras with a severity of "blocker" or "critical" should make it
> >>>>> into
> >>>>> 1.7.0, and I will send periodic emails with the state of the release
> (#
> >>>>> blockers, # critical, # major, etc.)
> >>>>> It is up to the developers to contact me if they want to bring up the
> >>>>> discussion of a Jira that may need to increase its severity. I will
> >>>>> act as
> >>>>> a funnel to involve the right folks, and potentially involve the dev
> >>>>> community when required.
> >>>>> For this reason, we need to have a consistent understanding of what
> the
> >>>>> severities mean,
> >>>>>
> >>>>> *Blocker *- Blocker type issues are the most critical issues. You
> will
> >>>>> not
> >>>>> be able to use the product if this type of issue occurs.
> >>>>> Example: Unable to log on to the system.
> >>>>>
> >>>>> *Critical *- This type of issue is critical to the system and you
> need
> >>>>> to
> >>>>> attend to these issues as soon as possible.
> >>>>> Example: An exception occurring when performing a particular
> function,
> >>>>> (i.e., adding a user to the system)
> >>>>>
> >>>>> *Major *- Issues that are important and should be fixed but does not
> >>>>> stop
> >>>>> the rest of the system from functioning.
> >>>>> Example: When adding one record, the same record gets added twice.
> >>>>>
> >>>>> *Minor *- These issues have a relatively minor impact on the product
> >>>>> but
> >>>>> needs to be fixed.
> >>>>> Example: Wrong message being displayed when some action is performed.
> >>>>>
> >>>>> *Trivial *- Trivial issues have the least impact on the product.
> >>>>>
> >>>>> Example: Spelling error in an error message, GUI Issues, etc.
> >>>>>
> >>>>> Generally, we should consider fixing "major" issues if we
> >>>>> 1. Eliminated all or nearly all blocker/critical issues (since these
> >>>>> have a
> >>>>> higher priority)
> >>>>> 2. Have high confidence that the fix is not introducing regressions,
> >>>>> have a
> >>>>> good understanding of all of its side-effects, and the fix does not
> >>>>> product
> >>>>> a lot of code-churn or change too many lines
> >>>>> 3. Have enough time to let the fix stabilize and fully understand how
> >>>>> to
> >>>>> unit and system test it
> >>>>>
> >>>>> Thanks,
> >>>>> Alejandro Fernandez
> >>>>>
> >>>>> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <
> cgopal@pivotal.io
> >>>>> >
> >>>>> wrote:
> >>>>>
> >>>>> > Alejandro,
> >>>>> > Had a quick question with regards to the criteria/specifics for
> >>>>> bug-fixes
> >>>>> > making it to the 1.7.0 branch. Do we need to add a label (such as
> >>>>> GA
> >>>>> > Blocker) to the JIRA tickets? Or do they need to have a certain
> >>>>> level of
> >>>>> > Severity?
> >>>>> >
> >>>>> > Thanks !
> >>>>> > Chandra
> >>>>> >
> >>>>> >
> >>>>> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
> >>>>> alejandro@apache.org
> >>>>> > > wrote:
> >>>>> >
> >>>>> >> Friendly reminder that we will make the Ambari 1.7.0 branch on
> >>>>> Friday at
> >>>>> >> 2 pm Pacific Time. After the cut-off, we will require all bug
> fixes
> >>>>> to
> >>>>> >> first be committed to trunk, ensure that nothing breaks, and then
> >>>>> integrate
> >>>>> >> it into the release branch.
> >>>>> >>
> >>>>> >> All bug fixes meant for the release branch must be reviewed by at
> >>>>> least 2
> >>>>> >> people on Review Board, unit-tested, and system-tested.
> >>>>> >> Please don't hesitate to contact me if you have any questions.
> >>>>> >>
> >>>>> >> Stay tuned for more updates once the release candidate (will be
> >>>>> named
> >>>>> >> branch-1.7.0) is made and we have builds running on Apache.
> >>>>> >>
> >>>>> >> Thank you,
> >>>>> >> Alejandro Fernandez
> >>>>> >> Ambari 1.7.0 Release Manager
> >>>>> >>
> >>>>> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
> >>>>> >> alejandro@apache.org> wrote:
> >>>>> >>
> >>>>> >>> Hi developers and PMCs,
> >>>>> >>>
> >>>>> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday
> >>>>> October 3
> >>>>> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari
> >>>>> Feature +
> >>>>> >>> Roadmap page (
> >>>>> >>>
> >>>>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
> >>>>> >>> ).
> >>>>> >>>
> >>>>> >>> After making the branch, we (i.e., development community) should
> >>>>> only
> >>>>> >>> accept blocker or critical bug fixes into the branch and harden
> it
> >>>>> until it
> >>>>> >>> meets a high enough quality bar (roughly around 4 weeks, and
> >>>>> subject to
> >>>>> >>> change).
> >>>>> >>> To further improve the stability of the release branch, we will
> >>>>> require
> >>>>> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
> >>>>> committers
> >>>>> >>> and unit-tested & system-tested.
> >>>>> >>>
> >>>>> >>> If you have a bug fix, it should first be committed to trunk, and
> >>>>> after
> >>>>> >>> ensuring that it does not break any tests (including smoke
> tests),
> >>>>> then it
> >>>>> >>> should be integrated to the Ambari 1.7.0 branch.
> >>>>> >>>
> >>>>> >>> If you have any doubts whether a fix should be committed into the
> >>>>> 1.7.0
> >>>>> >>> branch, please email me for input at alejandro@apache.org
> >>>>> >>>
> >>>>> >>> Stay tuned for updates on the release process.
> >>>>> >>>
> >>>>> >>> Thank you,
> >>>>> >>> Alejandro Fernandez
> >>>>> >>> Ambari 1.7.0 Release Manager
> >>>>> >>>
> >>>>> >>
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>> > --
> >>>>> > Chandrasekhar Gopal
> >>>>> > Pivotal Hadoop -- Build, Release and Deployments
> >>>>> > cgopal@gopivotal.com
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>> CONFIDENTIALITY NOTICE
> >>>> NOTICE: This message is intended for the use of the individual or
> >>>> entity to which it is addressed and may contain information that is
> >>>> confidential, privileged and exempt from disclosure under applicable
> law.
> >>>> If the reader of this message is not the intended recipient, you are
> hereby
> >>>> notified that any printing, copying, dissemination, distribution,
> >>>> disclosure or forwarding of this communication is strictly
> prohibited. If
> >>>> you have received this communication in error, please contact the
> sender
> >>>> immediately and delete it from your system. Thank You.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Chandrasekhar Gopal
> >> Pivotal Hadoop -- Build, Release and Deployments
> >> cgopal@gopivotal.com
> >>
> >
> >
>
>
> --
> Chandrasekhar Gopal
> Pivotal Hadoop -- Build, Release and Deployments
> cgopal@gopivotal.com
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Preparing Ambari 1.7.0 branch
Posted by Chandrasekhar Gopal <cg...@pivotal.io>.
Enabled the Jenkins Job on b.a.o for branch-1.7.0. Manually triggered
the first build.
https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/1/consoleFull
I noticed that the following test failed for Ambari-Server. Looking to see
if this issue has already been reported.
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.041 sec
Results :
Failed tests:
testOpFailedEventRaisedForAbortedHostRole(org.apache.ambari.server.actionmanager.TestActionScheduler):
expected:<ABORTED> but was:<PENDING>
Tests run: 2076, Failures: 1, Errors: 0, Skipped: 16
The same failure occurs on the trunk build also.
https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-trunk-Commit/477/
@Jun: Thanks for all the help !
-Chandra
On Fri, Oct 3, 2014 at 2:33 PM, Alejandro Fernandez <al...@apache.org>
wrote:
> The release candidate branch-1.7.0 is ready.
>
> git pull
> git branch --remote
>
> Thanks,
> Alejandro Fernandez
>
> On Fri, Oct 3, 2014 at 1:46 PM, Chandrasekhar Gopal <cg...@pivotal.io>
> wrote:
>
>> With Jun's help, we have a created a build for branch-1.7.0 on b.a.o.
>>
>> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/
>>
>> This build is currently disabled. Once we get the green signal from
>> Alejandro with regards to the completion of the branch creation for 1.7.0,
>> I'll enable and test the build out.
>>
>> I have updated https://issues.apache.org/jira/browse/AMBARI-7565
>>
>> Chandra
>>
>>
>> On Fri, Oct 3, 2014 at 10:35 AM, Alejandro Fernandez <
>> alejandro@apache.org> wrote:
>>
>>> I was thinking of adding a page to the wiki entitled "Developer
>>> Workflow", this can contain the diagram that Jun Aoki started, plus our
>>> guideline/expectations for release candidate branches.
>>>
>>> For the release candidate, all Jiras must have a Fix-Version of 1.7.0;
>>> whereas Jiras for the trunk branch can target 2.0.0. An empty Fix-Version
>>> is typically used for the backlog (unless we create a Backlog Fix-Version).
>>>
>>> Thanks,
>>> Alejandro Fernandez
>>>
>>> On Thu, Oct 2, 2014 at 4:20 PM, Sumit Mohanty <sm...@hortonworks.com>
>>> wrote:
>>>
>>>> Is the definition of Blocker/Critical etc. standard - if not can you
>>>> host it in Ambari wiki.
>>>>
>>>> Also, I assume the Fix Version/s should include 1.7.0.
>>>>
>>>> This brings up another question -
>>>>
>>>> What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is
>>>> it empty or we have a version number for post 1.7.0?
>>>>
>>>> -Sumit
>>>>
>>>> On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <
>>>> alejandro@apache.org> wrote:
>>>>
>>>>> I propose using the "severity" field.
>>>>>
>>>>> All Jiras with a severity of "blocker" or "critical" should make it
>>>>> into
>>>>> 1.7.0, and I will send periodic emails with the state of the release (#
>>>>> blockers, # critical, # major, etc.)
>>>>> It is up to the developers to contact me if they want to bring up the
>>>>> discussion of a Jira that may need to increase its severity. I will
>>>>> act as
>>>>> a funnel to involve the right folks, and potentially involve the dev
>>>>> community when required.
>>>>> For this reason, we need to have a consistent understanding of what the
>>>>> severities mean,
>>>>>
>>>>> *Blocker *- Blocker type issues are the most critical issues. You will
>>>>> not
>>>>> be able to use the product if this type of issue occurs.
>>>>> Example: Unable to log on to the system.
>>>>>
>>>>> *Critical *- This type of issue is critical to the system and you need
>>>>> to
>>>>> attend to these issues as soon as possible.
>>>>> Example: An exception occurring when performing a particular function,
>>>>> (i.e., adding a user to the system)
>>>>>
>>>>> *Major *- Issues that are important and should be fixed but does not
>>>>> stop
>>>>> the rest of the system from functioning.
>>>>> Example: When adding one record, the same record gets added twice.
>>>>>
>>>>> *Minor *- These issues have a relatively minor impact on the product
>>>>> but
>>>>> needs to be fixed.
>>>>> Example: Wrong message being displayed when some action is performed.
>>>>>
>>>>> *Trivial *- Trivial issues have the least impact on the product.
>>>>>
>>>>> Example: Spelling error in an error message, GUI Issues, etc.
>>>>>
>>>>> Generally, we should consider fixing "major" issues if we
>>>>> 1. Eliminated all or nearly all blocker/critical issues (since these
>>>>> have a
>>>>> higher priority)
>>>>> 2. Have high confidence that the fix is not introducing regressions,
>>>>> have a
>>>>> good understanding of all of its side-effects, and the fix does not
>>>>> product
>>>>> a lot of code-churn or change too many lines
>>>>> 3. Have enough time to let the fix stabilize and fully understand how
>>>>> to
>>>>> unit and system test it
>>>>>
>>>>> Thanks,
>>>>> Alejandro Fernandez
>>>>>
>>>>> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <cgopal@pivotal.io
>>>>> >
>>>>> wrote:
>>>>>
>>>>> > Alejandro,
>>>>> > Had a quick question with regards to the criteria/specifics for
>>>>> bug-fixes
>>>>> > making it to the 1.7.0 branch. Do we need to add a label (such as
>>>>> GA
>>>>> > Blocker) to the JIRA tickets? Or do they need to have a certain
>>>>> level of
>>>>> > Severity?
>>>>> >
>>>>> > Thanks !
>>>>> > Chandra
>>>>> >
>>>>> >
>>>>> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
>>>>> alejandro@apache.org
>>>>> > > wrote:
>>>>> >
>>>>> >> Friendly reminder that we will make the Ambari 1.7.0 branch on
>>>>> Friday at
>>>>> >> 2 pm Pacific Time. After the cut-off, we will require all bug fixes
>>>>> to
>>>>> >> first be committed to trunk, ensure that nothing breaks, and then
>>>>> integrate
>>>>> >> it into the release branch.
>>>>> >>
>>>>> >> All bug fixes meant for the release branch must be reviewed by at
>>>>> least 2
>>>>> >> people on Review Board, unit-tested, and system-tested.
>>>>> >> Please don't hesitate to contact me if you have any questions.
>>>>> >>
>>>>> >> Stay tuned for more updates once the release candidate (will be
>>>>> named
>>>>> >> branch-1.7.0) is made and we have builds running on Apache.
>>>>> >>
>>>>> >> Thank you,
>>>>> >> Alejandro Fernandez
>>>>> >> Ambari 1.7.0 Release Manager
>>>>> >>
>>>>> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
>>>>> >> alejandro@apache.org> wrote:
>>>>> >>
>>>>> >>> Hi developers and PMCs,
>>>>> >>>
>>>>> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday
>>>>> October 3
>>>>> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari
>>>>> Feature +
>>>>> >>> Roadmap page (
>>>>> >>>
>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>>>>> >>> ).
>>>>> >>>
>>>>> >>> After making the branch, we (i.e., development community) should
>>>>> only
>>>>> >>> accept blocker or critical bug fixes into the branch and harden it
>>>>> until it
>>>>> >>> meets a high enough quality bar (roughly around 4 weeks, and
>>>>> subject to
>>>>> >>> change).
>>>>> >>> To further improve the stability of the release branch, we will
>>>>> require
>>>>> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
>>>>> committers
>>>>> >>> and unit-tested & system-tested.
>>>>> >>>
>>>>> >>> If you have a bug fix, it should first be committed to trunk, and
>>>>> after
>>>>> >>> ensuring that it does not break any tests (including smoke tests),
>>>>> then it
>>>>> >>> should be integrated to the Ambari 1.7.0 branch.
>>>>> >>>
>>>>> >>> If you have any doubts whether a fix should be committed into the
>>>>> 1.7.0
>>>>> >>> branch, please email me for input at alejandro@apache.org
>>>>> >>>
>>>>> >>> Stay tuned for updates on the release process.
>>>>> >>>
>>>>> >>> Thank you,
>>>>> >>> Alejandro Fernandez
>>>>> >>> Ambari 1.7.0 Release Manager
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Chandrasekhar Gopal
>>>>> > Pivotal Hadoop -- Build, Release and Deployments
>>>>> > cgopal@gopivotal.com
>>>>> >
>>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE
>>>> NOTICE: This message is intended for the use of the individual or
>>>> entity to which it is addressed and may contain information that is
>>>> confidential, privileged and exempt from disclosure under applicable law.
>>>> If the reader of this message is not the intended recipient, you are hereby
>>>> notified that any printing, copying, dissemination, distribution,
>>>> disclosure or forwarding of this communication is strictly prohibited. If
>>>> you have received this communication in error, please contact the sender
>>>> immediately and delete it from your system. Thank You.
>>>
>>>
>>>
>>
>>
>> --
>> Chandrasekhar Gopal
>> Pivotal Hadoop -- Build, Release and Deployments
>> cgopal@gopivotal.com
>>
>
>
--
Chandrasekhar Gopal
Pivotal Hadoop -- Build, Release and Deployments
cgopal@gopivotal.com
Re: Preparing Ambari 1.7.0 branch
Posted by Alejandro Fernandez <al...@apache.org>.
The release candidate branch-1.7.0 is ready.
git pull
git branch --remote
Thanks,
Alejandro Fernandez
On Fri, Oct 3, 2014 at 1:46 PM, Chandrasekhar Gopal <cg...@pivotal.io>
wrote:
> With Jun's help, we have a created a build for branch-1.7.0 on b.a.o.
>
> https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/
>
> This build is currently disabled. Once we get the green signal from
> Alejandro with regards to the completion of the branch creation for 1.7.0,
> I'll enable and test the build out.
>
> I have updated https://issues.apache.org/jira/browse/AMBARI-7565
>
> Chandra
>
>
> On Fri, Oct 3, 2014 at 10:35 AM, Alejandro Fernandez <alejandro@apache.org
> > wrote:
>
>> I was thinking of adding a page to the wiki entitled "Developer
>> Workflow", this can contain the diagram that Jun Aoki started, plus our
>> guideline/expectations for release candidate branches.
>>
>> For the release candidate, all Jiras must have a Fix-Version of 1.7.0;
>> whereas Jiras for the trunk branch can target 2.0.0. An empty Fix-Version
>> is typically used for the backlog (unless we create a Backlog Fix-Version).
>>
>> Thanks,
>> Alejandro Fernandez
>>
>> On Thu, Oct 2, 2014 at 4:20 PM, Sumit Mohanty <sm...@hortonworks.com>
>> wrote:
>>
>>> Is the definition of Blocker/Critical etc. standard - if not can you
>>> host it in Ambari wiki.
>>>
>>> Also, I assume the Fix Version/s should include 1.7.0.
>>>
>>> This brings up another question -
>>>
>>> What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is
>>> it empty or we have a version number for post 1.7.0?
>>>
>>> -Sumit
>>>
>>> On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <
>>> alejandro@apache.org> wrote:
>>>
>>>> I propose using the "severity" field.
>>>>
>>>> All Jiras with a severity of "blocker" or "critical" should make it into
>>>> 1.7.0, and I will send periodic emails with the state of the release (#
>>>> blockers, # critical, # major, etc.)
>>>> It is up to the developers to contact me if they want to bring up the
>>>> discussion of a Jira that may need to increase its severity. I will act
>>>> as
>>>> a funnel to involve the right folks, and potentially involve the dev
>>>> community when required.
>>>> For this reason, we need to have a consistent understanding of what the
>>>> severities mean,
>>>>
>>>> *Blocker *- Blocker type issues are the most critical issues. You will
>>>> not
>>>> be able to use the product if this type of issue occurs.
>>>> Example: Unable to log on to the system.
>>>>
>>>> *Critical *- This type of issue is critical to the system and you need
>>>> to
>>>> attend to these issues as soon as possible.
>>>> Example: An exception occurring when performing a particular function,
>>>> (i.e., adding a user to the system)
>>>>
>>>> *Major *- Issues that are important and should be fixed but does not
>>>> stop
>>>> the rest of the system from functioning.
>>>> Example: When adding one record, the same record gets added twice.
>>>>
>>>> *Minor *- These issues have a relatively minor impact on the product but
>>>> needs to be fixed.
>>>> Example: Wrong message being displayed when some action is performed.
>>>>
>>>> *Trivial *- Trivial issues have the least impact on the product.
>>>>
>>>> Example: Spelling error in an error message, GUI Issues, etc.
>>>>
>>>> Generally, we should consider fixing "major" issues if we
>>>> 1. Eliminated all or nearly all blocker/critical issues (since these
>>>> have a
>>>> higher priority)
>>>> 2. Have high confidence that the fix is not introducing regressions,
>>>> have a
>>>> good understanding of all of its side-effects, and the fix does not
>>>> product
>>>> a lot of code-churn or change too many lines
>>>> 3. Have enough time to let the fix stabilize and fully understand how to
>>>> unit and system test it
>>>>
>>>> Thanks,
>>>> Alejandro Fernandez
>>>>
>>>> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
>>>> wrote:
>>>>
>>>> > Alejandro,
>>>> > Had a quick question with regards to the criteria/specifics for
>>>> bug-fixes
>>>> > making it to the 1.7.0 branch. Do we need to add a label (such as GA
>>>> > Blocker) to the JIRA tickets? Or do they need to have a certain
>>>> level of
>>>> > Severity?
>>>> >
>>>> > Thanks !
>>>> > Chandra
>>>> >
>>>> >
>>>> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
>>>> alejandro@apache.org
>>>> > > wrote:
>>>> >
>>>> >> Friendly reminder that we will make the Ambari 1.7.0 branch on
>>>> Friday at
>>>> >> 2 pm Pacific Time. After the cut-off, we will require all bug fixes
>>>> to
>>>> >> first be committed to trunk, ensure that nothing breaks, and then
>>>> integrate
>>>> >> it into the release branch.
>>>> >>
>>>> >> All bug fixes meant for the release branch must be reviewed by at
>>>> least 2
>>>> >> people on Review Board, unit-tested, and system-tested.
>>>> >> Please don't hesitate to contact me if you have any questions.
>>>> >>
>>>> >> Stay tuned for more updates once the release candidate (will be named
>>>> >> branch-1.7.0) is made and we have builds running on Apache.
>>>> >>
>>>> >> Thank you,
>>>> >> Alejandro Fernandez
>>>> >> Ambari 1.7.0 Release Manager
>>>> >>
>>>> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
>>>> >> alejandro@apache.org> wrote:
>>>> >>
>>>> >>> Hi developers and PMCs,
>>>> >>>
>>>> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday
>>>> October 3
>>>> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari
>>>> Feature +
>>>> >>> Roadmap page (
>>>> >>>
>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>>>> >>> ).
>>>> >>>
>>>> >>> After making the branch, we (i.e., development community) should
>>>> only
>>>> >>> accept blocker or critical bug fixes into the branch and harden it
>>>> until it
>>>> >>> meets a high enough quality bar (roughly around 4 weeks, and
>>>> subject to
>>>> >>> change).
>>>> >>> To further improve the stability of the release branch, we will
>>>> require
>>>> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
>>>> committers
>>>> >>> and unit-tested & system-tested.
>>>> >>>
>>>> >>> If you have a bug fix, it should first be committed to trunk, and
>>>> after
>>>> >>> ensuring that it does not break any tests (including smoke tests),
>>>> then it
>>>> >>> should be integrated to the Ambari 1.7.0 branch.
>>>> >>>
>>>> >>> If you have any doubts whether a fix should be committed into the
>>>> 1.7.0
>>>> >>> branch, please email me for input at alejandro@apache.org
>>>> >>>
>>>> >>> Stay tuned for updates on the release process.
>>>> >>>
>>>> >>> Thank you,
>>>> >>> Alejandro Fernandez
>>>> >>> Ambari 1.7.0 Release Manager
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Chandrasekhar Gopal
>>>> > Pivotal Hadoop -- Build, Release and Deployments
>>>> > cgopal@gopivotal.com
>>>> >
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE
>>> NOTICE: This message is intended for the use of the individual or entity
>>> to which it is addressed and may contain information that is confidential,
>>> privileged and exempt from disclosure under applicable law. If the reader
>>> of this message is not the intended recipient, you are hereby notified that
>>> any printing, copying, dissemination, distribution, disclosure or
>>> forwarding of this communication is strictly prohibited. If you have
>>> received this communication in error, please contact the sender immediately
>>> and delete it from your system. Thank You.
>>
>>
>>
>
>
> --
> Chandrasekhar Gopal
> Pivotal Hadoop -- Build, Release and Deployments
> cgopal@gopivotal.com
>
Re: Preparing Ambari 1.7.0 branch
Posted by Chandrasekhar Gopal <cg...@pivotal.io>.
With Jun's help, we have a created a build for branch-1.7.0 on b.a.o.
https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/
This build is currently disabled. Once we get the green signal from
Alejandro with regards to the completion of the branch creation for 1.7.0,
I'll enable and test the build out.
I have updated https://issues.apache.org/jira/browse/AMBARI-7565
Chandra
On Fri, Oct 3, 2014 at 10:35 AM, Alejandro Fernandez <al...@apache.org>
wrote:
> I was thinking of adding a page to the wiki entitled "Developer Workflow",
> this can contain the diagram that Jun Aoki started, plus our
> guideline/expectations for release candidate branches.
>
> For the release candidate, all Jiras must have a Fix-Version of 1.7.0;
> whereas Jiras for the trunk branch can target 2.0.0. An empty Fix-Version
> is typically used for the backlog (unless we create a Backlog Fix-Version).
>
> Thanks,
> Alejandro Fernandez
>
> On Thu, Oct 2, 2014 at 4:20 PM, Sumit Mohanty <sm...@hortonworks.com>
> wrote:
>
>> Is the definition of Blocker/Critical etc. standard - if not can you host
>> it in Ambari wiki.
>>
>> Also, I assume the Fix Version/s should include 1.7.0.
>>
>> This brings up another question -
>>
>> What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is it
>> empty or we have a version number for post 1.7.0?
>>
>> -Sumit
>>
>> On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <alejandro@apache.org
>> > wrote:
>>
>>> I propose using the "severity" field.
>>>
>>> All Jiras with a severity of "blocker" or "critical" should make it into
>>> 1.7.0, and I will send periodic emails with the state of the release (#
>>> blockers, # critical, # major, etc.)
>>> It is up to the developers to contact me if they want to bring up the
>>> discussion of a Jira that may need to increase its severity. I will act
>>> as
>>> a funnel to involve the right folks, and potentially involve the dev
>>> community when required.
>>> For this reason, we need to have a consistent understanding of what the
>>> severities mean,
>>>
>>> *Blocker *- Blocker type issues are the most critical issues. You will
>>> not
>>> be able to use the product if this type of issue occurs.
>>> Example: Unable to log on to the system.
>>>
>>> *Critical *- This type of issue is critical to the system and you need to
>>> attend to these issues as soon as possible.
>>> Example: An exception occurring when performing a particular function,
>>> (i.e., adding a user to the system)
>>>
>>> *Major *- Issues that are important and should be fixed but does not stop
>>> the rest of the system from functioning.
>>> Example: When adding one record, the same record gets added twice.
>>>
>>> *Minor *- These issues have a relatively minor impact on the product but
>>> needs to be fixed.
>>> Example: Wrong message being displayed when some action is performed.
>>>
>>> *Trivial *- Trivial issues have the least impact on the product.
>>>
>>> Example: Spelling error in an error message, GUI Issues, etc.
>>>
>>> Generally, we should consider fixing "major" issues if we
>>> 1. Eliminated all or nearly all blocker/critical issues (since these
>>> have a
>>> higher priority)
>>> 2. Have high confidence that the fix is not introducing regressions,
>>> have a
>>> good understanding of all of its side-effects, and the fix does not
>>> product
>>> a lot of code-churn or change too many lines
>>> 3. Have enough time to let the fix stabilize and fully understand how to
>>> unit and system test it
>>>
>>> Thanks,
>>> Alejandro Fernandez
>>>
>>> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
>>> wrote:
>>>
>>> > Alejandro,
>>> > Had a quick question with regards to the criteria/specifics for
>>> bug-fixes
>>> > making it to the 1.7.0 branch. Do we need to add a label (such as GA
>>> > Blocker) to the JIRA tickets? Or do they need to have a certain level
>>> of
>>> > Severity?
>>> >
>>> > Thanks !
>>> > Chandra
>>> >
>>> >
>>> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
>>> alejandro@apache.org
>>> > > wrote:
>>> >
>>> >> Friendly reminder that we will make the Ambari 1.7.0 branch on Friday
>>> at
>>> >> 2 pm Pacific Time. After the cut-off, we will require all bug fixes to
>>> >> first be committed to trunk, ensure that nothing breaks, and then
>>> integrate
>>> >> it into the release branch.
>>> >>
>>> >> All bug fixes meant for the release branch must be reviewed by at
>>> least 2
>>> >> people on Review Board, unit-tested, and system-tested.
>>> >> Please don't hesitate to contact me if you have any questions.
>>> >>
>>> >> Stay tuned for more updates once the release candidate (will be named
>>> >> branch-1.7.0) is made and we have builds running on Apache.
>>> >>
>>> >> Thank you,
>>> >> Alejandro Fernandez
>>> >> Ambari 1.7.0 Release Manager
>>> >>
>>> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
>>> >> alejandro@apache.org> wrote:
>>> >>
>>> >>> Hi developers and PMCs,
>>> >>>
>>> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday October
>>> 3
>>> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari
>>> Feature +
>>> >>> Roadmap page (
>>> >>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>>> >>> ).
>>> >>>
>>> >>> After making the branch, we (i.e., development community) should only
>>> >>> accept blocker or critical bug fixes into the branch and harden it
>>> until it
>>> >>> meets a high enough quality bar (roughly around 4 weeks, and subject
>>> to
>>> >>> change).
>>> >>> To further improve the stability of the release branch, we will
>>> require
>>> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
>>> committers
>>> >>> and unit-tested & system-tested.
>>> >>>
>>> >>> If you have a bug fix, it should first be committed to trunk, and
>>> after
>>> >>> ensuring that it does not break any tests (including smoke tests),
>>> then it
>>> >>> should be integrated to the Ambari 1.7.0 branch.
>>> >>>
>>> >>> If you have any doubts whether a fix should be committed into the
>>> 1.7.0
>>> >>> branch, please email me for input at alejandro@apache.org
>>> >>>
>>> >>> Stay tuned for updates on the release process.
>>> >>>
>>> >>> Thank you,
>>> >>> Alejandro Fernandez
>>> >>> Ambari 1.7.0 Release Manager
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Chandrasekhar Gopal
>>> > Pivotal Hadoop -- Build, Release and Deployments
>>> > cgopal@gopivotal.com
>>> >
>>>
>>
>>
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity
>> to which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>
>
>
--
Chandrasekhar Gopal
Pivotal Hadoop -- Build, Release and Deployments
cgopal@gopivotal.com
Re: Preparing Ambari 1.7.0 branch
Posted by Alejandro Fernandez <al...@apache.org>.
I was thinking of adding a page to the wiki entitled "Developer Workflow",
this can contain the diagram that Jun Aoki started, plus our
guideline/expectations for release candidate branches.
For the release candidate, all Jiras must have a Fix-Version of 1.7.0;
whereas Jiras for the trunk branch can target 2.0.0. An empty Fix-Version
is typically used for the backlog (unless we create a Backlog Fix-Version).
Thanks,
Alejandro Fernandez
On Thu, Oct 2, 2014 at 4:20 PM, Sumit Mohanty <sm...@hortonworks.com>
wrote:
> Is the definition of Blocker/Critical etc. standard - if not can you host
> it in Ambari wiki.
>
> Also, I assume the Fix Version/s should include 1.7.0.
>
> This brings up another question -
>
> What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is it
> empty or we have a version number for post 1.7.0?
>
> -Sumit
>
> On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <al...@apache.org>
> wrote:
>
>> I propose using the "severity" field.
>>
>> All Jiras with a severity of "blocker" or "critical" should make it into
>> 1.7.0, and I will send periodic emails with the state of the release (#
>> blockers, # critical, # major, etc.)
>> It is up to the developers to contact me if they want to bring up the
>> discussion of a Jira that may need to increase its severity. I will act as
>> a funnel to involve the right folks, and potentially involve the dev
>> community when required.
>> For this reason, we need to have a consistent understanding of what the
>> severities mean,
>>
>> *Blocker *- Blocker type issues are the most critical issues. You will not
>> be able to use the product if this type of issue occurs.
>> Example: Unable to log on to the system.
>>
>> *Critical *- This type of issue is critical to the system and you need to
>> attend to these issues as soon as possible.
>> Example: An exception occurring when performing a particular function,
>> (i.e., adding a user to the system)
>>
>> *Major *- Issues that are important and should be fixed but does not stop
>> the rest of the system from functioning.
>> Example: When adding one record, the same record gets added twice.
>>
>> *Minor *- These issues have a relatively minor impact on the product but
>> needs to be fixed.
>> Example: Wrong message being displayed when some action is performed.
>>
>> *Trivial *- Trivial issues have the least impact on the product.
>>
>> Example: Spelling error in an error message, GUI Issues, etc.
>>
>> Generally, we should consider fixing "major" issues if we
>> 1. Eliminated all or nearly all blocker/critical issues (since these have
>> a
>> higher priority)
>> 2. Have high confidence that the fix is not introducing regressions, have
>> a
>> good understanding of all of its side-effects, and the fix does not
>> product
>> a lot of code-churn or change too many lines
>> 3. Have enough time to let the fix stabilize and fully understand how to
>> unit and system test it
>>
>> Thanks,
>> Alejandro Fernandez
>>
>> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
>> wrote:
>>
>> > Alejandro,
>> > Had a quick question with regards to the criteria/specifics for
>> bug-fixes
>> > making it to the 1.7.0 branch. Do we need to add a label (such as GA
>> > Blocker) to the JIRA tickets? Or do they need to have a certain level
>> of
>> > Severity?
>> >
>> > Thanks !
>> > Chandra
>> >
>> >
>> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
>> alejandro@apache.org
>> > > wrote:
>> >
>> >> Friendly reminder that we will make the Ambari 1.7.0 branch on Friday
>> at
>> >> 2 pm Pacific Time. After the cut-off, we will require all bug fixes to
>> >> first be committed to trunk, ensure that nothing breaks, and then
>> integrate
>> >> it into the release branch.
>> >>
>> >> All bug fixes meant for the release branch must be reviewed by at
>> least 2
>> >> people on Review Board, unit-tested, and system-tested.
>> >> Please don't hesitate to contact me if you have any questions.
>> >>
>> >> Stay tuned for more updates once the release candidate (will be named
>> >> branch-1.7.0) is made and we have builds running on Apache.
>> >>
>> >> Thank you,
>> >> Alejandro Fernandez
>> >> Ambari 1.7.0 Release Manager
>> >>
>> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
>> >> alejandro@apache.org> wrote:
>> >>
>> >>> Hi developers and PMCs,
>> >>>
>> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3
>> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari Feature
>> +
>> >>> Roadmap page (
>> >>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>> >>> ).
>> >>>
>> >>> After making the branch, we (i.e., development community) should only
>> >>> accept blocker or critical bug fixes into the branch and harden it
>> until it
>> >>> meets a high enough quality bar (roughly around 4 weeks, and subject
>> to
>> >>> change).
>> >>> To further improve the stability of the release branch, we will
>> require
>> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
>> committers
>> >>> and unit-tested & system-tested.
>> >>>
>> >>> If you have a bug fix, it should first be committed to trunk, and
>> after
>> >>> ensuring that it does not break any tests (including smoke tests),
>> then it
>> >>> should be integrated to the Ambari 1.7.0 branch.
>> >>>
>> >>> If you have any doubts whether a fix should be committed into the
>> 1.7.0
>> >>> branch, please email me for input at alejandro@apache.org
>> >>>
>> >>> Stay tuned for updates on the release process.
>> >>>
>> >>> Thank you,
>> >>> Alejandro Fernandez
>> >>> Ambari 1.7.0 Release Manager
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Chandrasekhar Gopal
>> > Pivotal Hadoop -- Build, Release and Deployments
>> > cgopal@gopivotal.com
>> >
>>
>
>
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
Re: Preparing Ambari 1.7.0 branch
Posted by Sumit Mohanty <sm...@hortonworks.com>.
Is the definition of Blocker/Critical etc. standard - if not can you host
it in Ambari wiki.
Also, I assume the Fix Version/s should include 1.7.0.
This brings up another question -
What is the Fix Version for JIRAs that are not targeted for 1.7.0 - is it
empty or we have a version number for post 1.7.0?
-Sumit
On Thu, Oct 2, 2014 at 2:11 PM, Alejandro Fernandez <al...@apache.org>
wrote:
> I propose using the "severity" field.
>
> All Jiras with a severity of "blocker" or "critical" should make it into
> 1.7.0, and I will send periodic emails with the state of the release (#
> blockers, # critical, # major, etc.)
> It is up to the developers to contact me if they want to bring up the
> discussion of a Jira that may need to increase its severity. I will act as
> a funnel to involve the right folks, and potentially involve the dev
> community when required.
> For this reason, we need to have a consistent understanding of what the
> severities mean,
>
> *Blocker *- Blocker type issues are the most critical issues. You will not
> be able to use the product if this type of issue occurs.
> Example: Unable to log on to the system.
>
> *Critical *- This type of issue is critical to the system and you need to
> attend to these issues as soon as possible.
> Example: An exception occurring when performing a particular function,
> (i.e., adding a user to the system)
>
> *Major *- Issues that are important and should be fixed but does not stop
> the rest of the system from functioning.
> Example: When adding one record, the same record gets added twice.
>
> *Minor *- These issues have a relatively minor impact on the product but
> needs to be fixed.
> Example: Wrong message being displayed when some action is performed.
>
> *Trivial *- Trivial issues have the least impact on the product.
> Example: Spelling error in an error message, GUI Issues, etc.
>
> Generally, we should consider fixing "major" issues if we
> 1. Eliminated all or nearly all blocker/critical issues (since these have a
> higher priority)
> 2. Have high confidence that the fix is not introducing regressions, have a
> good understanding of all of its side-effects, and the fix does not product
> a lot of code-churn or change too many lines
> 3. Have enough time to let the fix stabilize and fully understand how to
> unit and system test it
>
> Thanks,
> Alejandro Fernandez
>
> On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
> wrote:
>
> > Alejandro,
> > Had a quick question with regards to the criteria/specifics for
> bug-fixes
> > making it to the 1.7.0 branch. Do we need to add a label (such as GA
> > Blocker) to the JIRA tickets? Or do they need to have a certain level of
> > Severity?
> >
> > Thanks !
> > Chandra
> >
> >
> > On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <
> alejandro@apache.org
> > > wrote:
> >
> >> Friendly reminder that we will make the Ambari 1.7.0 branch on Friday at
> >> 2 pm Pacific Time. After the cut-off, we will require all bug fixes to
> >> first be committed to trunk, ensure that nothing breaks, and then
> integrate
> >> it into the release branch.
> >>
> >> All bug fixes meant for the release branch must be reviewed by at least
> 2
> >> people on Review Board, unit-tested, and system-tested.
> >> Please don't hesitate to contact me if you have any questions.
> >>
> >> Stay tuned for more updates once the release candidate (will be named
> >> branch-1.7.0) is made and we have builds running on Apache.
> >>
> >> Thank you,
> >> Alejandro Fernandez
> >> Ambari 1.7.0 Release Manager
> >>
> >> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
> >> alejandro@apache.org> wrote:
> >>
> >>> Hi developers and PMCs,
> >>>
> >>> I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3
> >>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari Feature +
> >>> Roadmap page (
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
> >>> ).
> >>>
> >>> After making the branch, we (i.e., development community) should only
> >>> accept blocker or critical bug fixes into the branch and harden it
> until it
> >>> meets a high enough quality bar (roughly around 4 weeks, and subject to
> >>> change).
> >>> To further improve the stability of the release branch, we will require
> >>> all checkins into Ambari 1.7.0 to be reviewed by at least two
> committers
> >>> and unit-tested & system-tested.
> >>>
> >>> If you have a bug fix, it should first be committed to trunk, and after
> >>> ensuring that it does not break any tests (including smoke tests),
> then it
> >>> should be integrated to the Ambari 1.7.0 branch.
> >>>
> >>> If you have any doubts whether a fix should be committed into the 1.7.0
> >>> branch, please email me for input at alejandro@apache.org
> >>>
> >>> Stay tuned for updates on the release process.
> >>>
> >>> Thank you,
> >>> Alejandro Fernandez
> >>> Ambari 1.7.0 Release Manager
> >>>
> >>
> >>
> >
> >
> > --
> > Chandrasekhar Gopal
> > Pivotal Hadoop -- Build, Release and Deployments
> > cgopal@gopivotal.com
> >
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Preparing Ambari 1.7.0 branch
Posted by Alejandro Fernandez <al...@apache.org>.
I propose using the "severity" field.
All Jiras with a severity of "blocker" or "critical" should make it into
1.7.0, and I will send periodic emails with the state of the release (#
blockers, # critical, # major, etc.)
It is up to the developers to contact me if they want to bring up the
discussion of a Jira that may need to increase its severity. I will act as
a funnel to involve the right folks, and potentially involve the dev
community when required.
For this reason, we need to have a consistent understanding of what the
severities mean,
*Blocker *- Blocker type issues are the most critical issues. You will not
be able to use the product if this type of issue occurs.
Example: Unable to log on to the system.
*Critical *- This type of issue is critical to the system and you need to
attend to these issues as soon as possible.
Example: An exception occurring when performing a particular function,
(i.e., adding a user to the system)
*Major *- Issues that are important and should be fixed but does not stop
the rest of the system from functioning.
Example: When adding one record, the same record gets added twice.
*Minor *- These issues have a relatively minor impact on the product but
needs to be fixed.
Example: Wrong message being displayed when some action is performed.
*Trivial *- Trivial issues have the least impact on the product.
Example: Spelling error in an error message, GUI Issues, etc.
Generally, we should consider fixing "major" issues if we
1. Eliminated all or nearly all blocker/critical issues (since these have a
higher priority)
2. Have high confidence that the fix is not introducing regressions, have a
good understanding of all of its side-effects, and the fix does not product
a lot of code-churn or change too many lines
3. Have enough time to let the fix stabilize and fully understand how to
unit and system test it
Thanks,
Alejandro Fernandez
On Thu, Oct 2, 2014 at 1:47 PM, Chandrasekhar Gopal <cg...@pivotal.io>
wrote:
> Alejandro,
> Had a quick question with regards to the criteria/specifics for bug-fixes
> making it to the 1.7.0 branch. Do we need to add a label (such as GA
> Blocker) to the JIRA tickets? Or do they need to have a certain level of
> Severity?
>
> Thanks !
> Chandra
>
>
> On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <alejandro@apache.org
> > wrote:
>
>> Friendly reminder that we will make the Ambari 1.7.0 branch on Friday at
>> 2 pm Pacific Time. After the cut-off, we will require all bug fixes to
>> first be committed to trunk, ensure that nothing breaks, and then integrate
>> it into the release branch.
>>
>> All bug fixes meant for the release branch must be reviewed by at least 2
>> people on Review Board, unit-tested, and system-tested.
>> Please don't hesitate to contact me if you have any questions.
>>
>> Stay tuned for more updates once the release candidate (will be named
>> branch-1.7.0) is made and we have builds running on Apache.
>>
>> Thank you,
>> Alejandro Fernandez
>> Ambari 1.7.0 Release Manager
>>
>> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <
>> alejandro@apache.org> wrote:
>>
>>> Hi developers and PMCs,
>>>
>>> I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3
>>> at 2 pm Pacific Time, as per the outlined tasks in the Ambari Feature +
>>> Roadmap page (
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>>> ).
>>>
>>> After making the branch, we (i.e., development community) should only
>>> accept blocker or critical bug fixes into the branch and harden it until it
>>> meets a high enough quality bar (roughly around 4 weeks, and subject to
>>> change).
>>> To further improve the stability of the release branch, we will require
>>> all checkins into Ambari 1.7.0 to be reviewed by at least two committers
>>> and unit-tested & system-tested.
>>>
>>> If you have a bug fix, it should first be committed to trunk, and after
>>> ensuring that it does not break any tests (including smoke tests), then it
>>> should be integrated to the Ambari 1.7.0 branch.
>>>
>>> If you have any doubts whether a fix should be committed into the 1.7.0
>>> branch, please email me for input at alejandro@apache.org
>>>
>>> Stay tuned for updates on the release process.
>>>
>>> Thank you,
>>> Alejandro Fernandez
>>> Ambari 1.7.0 Release Manager
>>>
>>
>>
>
>
> --
> Chandrasekhar Gopal
> Pivotal Hadoop -- Build, Release and Deployments
> cgopal@gopivotal.com
>
Re: Preparing Ambari 1.7.0 branch
Posted by Chandrasekhar Gopal <cg...@pivotal.io>.
Alejandro,
Had a quick question with regards to the criteria/specifics for bug-fixes
making it to the 1.7.0 branch. Do we need to add a label (such as GA
Blocker) to the JIRA tickets? Or do they need to have a certain level of
Severity?
Thanks !
Chandra
On Thu, Oct 2, 2014 at 11:25 AM, Alejandro Fernandez <al...@apache.org>
wrote:
> Friendly reminder that we will make the Ambari 1.7.0 branch on Friday at 2
> pm Pacific Time. After the cut-off, we will require all bug fixes to first
> be committed to trunk, ensure that nothing breaks, and then integrate it
> into the release branch.
>
> All bug fixes meant for the release branch must be reviewed by at least 2
> people on Review Board, unit-tested, and system-tested.
> Please don't hesitate to contact me if you have any questions.
>
> Stay tuned for more updates once the release candidate (will be named
> branch-1.7.0) is made and we have builds running on Apache.
>
> Thank you,
> Alejandro Fernandez
> Ambari 1.7.0 Release Manager
>
> On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <alejandro@apache.org
> > wrote:
>
>> Hi developers and PMCs,
>>
>> I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3 at
>> 2 pm Pacific Time, as per the outlined tasks in the Ambari Feature +
>> Roadmap page (
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
>> ).
>>
>> After making the branch, we (i.e., development community) should only
>> accept blocker or critical bug fixes into the branch and harden it until it
>> meets a high enough quality bar (roughly around 4 weeks, and subject to
>> change).
>> To further improve the stability of the release branch, we will require
>> all checkins into Ambari 1.7.0 to be reviewed by at least two committers
>> and unit-tested & system-tested.
>>
>> If you have a bug fix, it should first be committed to trunk, and after
>> ensuring that it does not break any tests (including smoke tests), then it
>> should be integrated to the Ambari 1.7.0 branch.
>>
>> If you have any doubts whether a fix should be committed into the 1.7.0
>> branch, please email me for input at alejandro@apache.org
>>
>> Stay tuned for updates on the release process.
>>
>> Thank you,
>> Alejandro Fernandez
>> Ambari 1.7.0 Release Manager
>>
>
>
--
Chandrasekhar Gopal
Pivotal Hadoop -- Build, Release and Deployments
cgopal@gopivotal.com
Re: Preparing Ambari 1.7.0 branch
Posted by Alejandro Fernandez <al...@apache.org>.
Friendly reminder that we will make the Ambari 1.7.0 branch on Friday at 2
pm Pacific Time. After the cut-off, we will require all bug fixes to first
be committed to trunk, ensure that nothing breaks, and then integrate it
into the release branch.
All bug fixes meant for the release branch must be reviewed by at least 2
people on Review Board, unit-tested, and system-tested.
Please don't hesitate to contact me if you have any questions.
Stay tuned for more updates once the release candidate (will be named
branch-1.7.0) is made and we have builds running on Apache.
Thank you,
Alejandro Fernandez
Ambari 1.7.0 Release Manager
On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <al...@apache.org>
wrote:
> Hi developers and PMCs,
>
> I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3 at
> 2 pm Pacific Time, as per the outlined tasks in the Ambari Feature +
> Roadmap page (
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
> ).
>
> After making the branch, we (i.e., development community) should only
> accept blocker or critical bug fixes into the branch and harden it until it
> meets a high enough quality bar (roughly around 4 weeks, and subject to
> change).
> To further improve the stability of the release branch, we will require
> all checkins into Ambari 1.7.0 to be reviewed by at least two committers
> and unit-tested & system-tested.
>
> If you have a bug fix, it should first be committed to trunk, and after
> ensuring that it does not break any tests (including smoke tests), then it
> should be integrated to the Ambari 1.7.0 branch.
>
> If you have any doubts whether a fix should be committed into the 1.7.0
> branch, please email me for input at alejandro@apache.org
>
> Stay tuned for updates on the release process.
>
> Thank you,
> Alejandro Fernandez
> Ambari 1.7.0 Release Manager
>
Re: Preparing Ambari 1.7.0 branch
Posted by Chandrasekhar Gopal <cg...@pivotal.io>.
Thanks all.
I have created the following JIRA to track this task.
https://issues.apache.org/jira/browse/AMBARI-7565
I will work with the team to have this job in place once the RC branch gets
created.
-Chandra
On Tue, Sep 30, 2014 at 7:52 AM, Yusaku Sako <yu...@hortonworks.com> wrote:
> +1 for setting up a 1.7.0 release build on builds.apache.org.
>
> Yusaku
>
> On Mon, Sep 29, 2014 at 8:12 PM, Judes Sarmiento <js...@pivotal.io>
> wrote:
>
> > That will help a lot!
> >
> > On Monday, September 29, 2014, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> > > On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal <
> cgopal@pivotal.io
> > > <javascript:;>> wrote:
> > > > Alejandro,
> > > > Upon creation of the RC branch for the 1.7.0 release, I'd like to
> > suggest
> > > > that we also create a release build for this branch on b.a.o.
> > >
> > > Huge +1 to that!
> > >
> > > Thanks,
> > > Roman.
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
Chandrasekhar Gopal
Pivotal Hadoop -- Build, Release and Deployments
cgopal@gopivotal.com
Re: Preparing Ambari 1.7.0 branch
Posted by Yusaku Sako <yu...@hortonworks.com>.
+1 for setting up a 1.7.0 release build on builds.apache.org.
Yusaku
On Mon, Sep 29, 2014 at 8:12 PM, Judes Sarmiento <js...@pivotal.io>
wrote:
> That will help a lot!
>
> On Monday, September 29, 2014, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal <cgopal@pivotal.io
> > <javascript:;>> wrote:
> > > Alejandro,
> > > Upon creation of the RC branch for the 1.7.0 release, I'd like to
> suggest
> > > that we also create a release build for this branch on b.a.o.
> >
> > Huge +1 to that!
> >
> > Thanks,
> > Roman.
> >
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Preparing Ambari 1.7.0 branch
Posted by Judes Sarmiento <js...@pivotal.io>.
That will help a lot!
On Monday, September 29, 2014, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal <cgopal@pivotal.io
> <javascript:;>> wrote:
> > Alejandro,
> > Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest
> > that we also create a release build for this branch on b.a.o.
>
> Huge +1 to that!
>
> Thanks,
> Roman.
>
Re: Preparing Ambari 1.7.0 branch
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal <cg...@pivotal.io> wrote:
> Alejandro,
> Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest
> that we also create a release build for this branch on b.a.o.
Huge +1 to that!
Thanks,
Roman.
Re: Preparing Ambari 1.7.0 branch
Posted by Chandrasekhar Gopal <cg...@pivotal.io>.
Alejandro,
Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest
that we also create a release build for this branch on b.a.o.
I can create a JIRA and help with creation of the release builds.
Please let me know your thoughts.
Thanks,
Chandra
On Mon, Sep 29, 2014 at 1:35 PM, Alejandro Fernandez <al...@apache.org>
wrote:
> Hi developers and PMCs,
>
> I am proposing cutting the branch for Ambari 1.7.0 on Friday October 3 at 2
> pm Pacific Time, as per the outlined tasks in the Ambari Feature + Roadmap
> page (
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705
> ).
>
> After making the branch, we (i.e., development community) should only
> accept blocker or critical bug fixes into the branch and harden it until it
> meets a high enough quality bar (roughly around 4 weeks, and subject to
> change).
> To further improve the stability of the release branch, we will require all
> checkins into Ambari 1.7.0 to be reviewed by at least two committers and
> unit-tested & system-tested.
>
> If you have a bug fix, it should first be committed to trunk, and after
> ensuring that it does not break any tests (including smoke tests), then it
> should be integrated to the Ambari 1.7.0 branch.
>
> If you have any doubts whether a fix should be committed into the 1.7.0
> branch, please email me for input at alejandro@apache.org
>
> Stay tuned for updates on the release process.
>
> Thank you,
> Alejandro Fernandez
> Ambari 1.7.0 Release Manager
>
--
Chandrasekhar Gopal
Pivotal Hadoop -- Build, Release and Deployments
cgopal@gopivotal.com