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.
