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.
