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 <cgo...@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 <alejan...@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 <cgo...@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 < >>> alejan...@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 <smoha...@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 < >>>>> alejan...@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 < >>>>>> cgo...@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 < >>>>>> alejan...@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 < >>>>>> >> alejan...@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 alejan...@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 >>>>>> > cgo...@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 >>> cgo...@gopivotal.com >>> >> >> > > > -- > Chandrasekhar Gopal > Pivotal Hadoop -- Build, Release and Deployments > cgo...@gopivotal.com > -- Chandrasekhar Gopal Pivotal Hadoop -- Build, Release and Deployments cgo...@gopivotal.com
