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] >
