ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chandrasekhar Gopal <cgo...@pivotal.io>
Subject Re: Preparing Ambari 1.7.0 branch
Date Fri, 03 Oct 2014 23:47:01 GMT
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 <alejandro@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 <cgopal@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

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