Great. Thanks Chandra! Yusaku
On Fri, Oct 3, 2014 at 4:47 PM, Chandrasekhar Gopal <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 < > >> [email protected]> 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 < > [email protected]> > >>> 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 < > >>>> [email protected]> 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 < > [email protected] > >>>>> > > >>>>> 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 < > >>>>> [email protected] > >>>>> > > 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 < > >>>>> >> [email protected]> 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 [email protected] > >>>>> >>> > >>>>> >>> 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 > >>>>> > [email protected] > >>>>> > > >>>>> > >>>> > >>>> > >>>> 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 > >> [email protected] > >> > > > > > > > -- > Chandrasekhar Gopal > Pivotal Hadoop -- Build, Release and Deployments > [email protected] > -- 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.
