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
