ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Fernandez <alejan...@apache.org>
Subject Re: Preparing Ambari 1.7.0 branch
Date Fri, 03 Oct 2014 21:33:24 GMT
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
>

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