Re: Preparing Ambari 1.7.0 branch
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
Re: Preparing Ambari 1.7.0 branch
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
Re: Preparing Ambari 1.7.0 branch
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 cgo...@pivotal.io 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 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 (
Re: Preparing Ambari 1.7.0 branch
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 alejan...@apache.org 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 cgo...@pivotal.io 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 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
Re: Preparing Ambari 1.7.0 branch
This issue has already been reported by Jun. https://issues.apache.org/jira/browse/AMBARI-7622 So we are good in terms of having consistent results for the builds off trunk and branch-1.7.0. On Fri, Oct 3, 2014 at 4:47 PM, Chandrasekhar Gopal cgo...@pivotal.io 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 alejan...@apache.org 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 cgo...@pivotal.io 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 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
Re: Preparing Ambari 1.7.0 branch
Great. Thanks Chandra! Yusaku On Fri, Oct 3, 2014 at 4:47 PM, Chandrasekhar Gopal cgo...@pivotal.io 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 alejan...@apache.org 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 cgo...@pivotal.io 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 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
Re: Preparing Ambari 1.7.0 branch
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
Re: Preparing Ambari 1.7.0 branch
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
Re: Preparing Ambari 1.7.0 branch
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
Re: Preparing Ambari 1.7.0 branch
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
Re: Preparing Ambari 1.7.0 branch
+1 for setting up a 1.7.0 release build on builds.apache.org. Yusaku On Mon, Sep 29, 2014 at 8:12 PM, Judes Sarmiento jsarmie...@pivotal.io wrote: That will help a lot! On Monday, September 29, 2014, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal cgo...@pivotal.io javascript:; wrote: Alejandro, Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest that we also create a release build for this branch on b.a.o. Huge +1 to that! Thanks, Roman. -- 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.
Re: Preparing Ambari 1.7.0 branch
Alejandro, Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest that we also create a release build for this branch on b.a.o. I can create a JIRA and help with creation of the release builds. Please let me know your thoughts. Thanks, Chandra 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
Re: Preparing Ambari 1.7.0 branch
On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal cgo...@pivotal.io wrote: Alejandro, Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest that we also create a release build for this branch on b.a.o. Huge +1 to that! Thanks, Roman.
Re: Preparing Ambari 1.7.0 branch
That will help a lot! On Monday, September 29, 2014, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Sep 29, 2014 at 5:26 PM, Chandrasekhar Gopal cgo...@pivotal.io javascript:; wrote: Alejandro, Upon creation of the RC branch for the 1.7.0 release, I'd like to suggest that we also create a release build for this branch on b.a.o. Huge +1 to that! Thanks, Roman.
