Re: Enough said? Ambari Dev Process Proposal Discussion Ends on 10/5
, 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. -- 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
[jira] [Commented] (AMBARI-7565) Create Jenkins Job on builds.apache.org for Ambari RC branch 1.7.0
[ https://issues.apache.org/jira/browse/AMBARI-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158503#comment-14158503 ] Chandrasekhar Gopal commented on AMBARI-7565: - 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. Chandra Create Jenkins Job on builds.apache.org for Ambari RC branch 1.7.0 -- Key: AMBARI-7565 URL: https://issues.apache.org/jira/browse/AMBARI-7565 Project: Ambari Issue Type: Task Components: infra Affects Versions: 1.7.0 Environment: Jenkins Builds Infrastructure Reporter: Chandrasekhar Gopal Priority: Minor Labels: jenkins Original Estimate: 24h Remaining Estimate: 24h The RC branch for Ambari Release 1.7.0 is scheduled to be created on Oct 3rd. This JIRA tracks the task for creating a build Job for the RC 1.7.0 branch on builds.apache.org. We can use the Ambari Commit build as the template. https://builds.apache.org/job/Ambari-trunk-Commit/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
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
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
[jira] [Commented] (AMBARI-7565) Create Jenkins Job on builds.apache.org for Ambari RC branch 1.7.0
[ https://issues.apache.org/jira/browse/AMBARI-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158727#comment-14158727 ] Chandrasekhar Gopal commented on AMBARI-7565: - 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/ The JIRA for this issue is https://issues.apache.org/jira/browse/AMBARI-7622. Create Jenkins Job on builds.apache.org for Ambari RC branch 1.7.0 -- Key: AMBARI-7565 URL: https://issues.apache.org/jira/browse/AMBARI-7565 Project: Ambari Issue Type: Task Components: infra Affects Versions: 1.7.0 Environment: Jenkins Builds Infrastructure Reporter: Chandrasekhar Gopal Priority: Minor Labels: jenkins Original Estimate: 24h Remaining Estimate: 24h The RC branch for Ambari Release 1.7.0 is scheduled to be created on Oct 3rd. This JIRA tracks the task for creating a build Job for the RC 1.7.0 branch on builds.apache.org. We can use the Ambari Commit build as the template. https://builds.apache.org/job/Ambari-trunk-Commit/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-7622) TestActionScheduler fails occasionally on builds.a.o stating expected:ABORTED but was:PENDING
[
https://issues.apache.org/jira/browse/AMBARI-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14158739#comment-14158739
]
Chandrasekhar Gopal commented on AMBARI-7622:
-
I am seeing the same issue for the build off the new branch-1.7.0 branch.
https://builds.apache.org/view/A-D/view/Ambari/job/Ambari-branch-1.7.0/1/consoleText
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.477 sec
Running org.apache.ambari.server.metadata.RoleGraphTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.906 sec
Running org.apache.ambari.server.metadata.RoleCommandOrderTest
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
TestActionScheduler fails occasionally on builds.a.o stating
expected:ABORTED but was:PENDING
-
Key: AMBARI-7622
URL: https://issues.apache.org/jira/browse/AMBARI-7622
Project: Ambari
Issue Type: Bug
Reporter: jun aoki
Assignee: jun aoki
For example
https://builds.apache.org/job/Ambari-trunk-test-patch/77//artifact/patch-work/testrun_ambari-server.txt
This does not happen always.
{code}
Running org.apache.ambari.server.controller.AmbariManagementControllerImplTest
Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.127 sec
Running org.apache.ambari.server.actionmanager.TestActionManager
Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 13.445 sec
Running org.apache.ambari.server.actionmanager.TestActionScheduler
Tests run: 19, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 3.492 sec
FAILURE!
Running org.apache.ambari.server.actionmanager.TestActionDBAccessorImpl
...
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.484 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
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 24:05 min
[INFO] Finished at: 2014-10-02T23:54:20+00:00
[INFO] Final Memory: 20M/294M
[INFO]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Do we have any Dockerfile that builds an Ambari build environment?
I don't see an attachment here. On Thu, Oct 2, 2014 at 9:30 AM, Newton Alex na...@pivotal.io wrote: I had developed one initially a few months ago. Attached here. - Newton On Wed, Oct 1, 2014 at 9:53 PM, jun aoki ja...@apache.org wrote: Yusaku has provided vagrantfiles. Do we have something similar but Dockerfile? I'm a docker fun :) -- -jun -- Chandrasekhar Gopal Pivotal Hadoop -- Build, Release and Deployments cgo...@gopivotal.com
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
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: New committer: Jay Vyas
Congrats Jay ! Chandrasekhar Gopal Pivotal Hadoop -- Build, Release and Deployments cgo...@gopivotal.com On Tue, Apr 29, 2014 at 11:28 AM, Giridharan Kesavan gkesa...@hortonworks.com wrote: congrats jay! -Giri On Tue, Apr 29, 2014 at 11:16 AM, Sean Mackrory mackror...@gmail.com wrote: Well deserved! On Tue, Apr 29, 2014 at 12:11 PM, Mark Grover m...@apache.org wrote: Congrats, Jay! On Tue, Apr 29, 2014 at 10:16 AM, Konstantin Boudnik c...@apache.org wrote: Guys, The Project Management Committee (PMC) for Apache Bigtop has asked Jay Vyas to become a committer and we are pleased to announce that he has accepted! His ASF account has been created as: j...@apache.org Being a committer enables easier contribution to the project since there is no need to go via the proxy patch submission process. This should enable better productivity. Just keep in mind that Apache Bigtop practices RTC (review-then-commit) development process which means that most of the time you still have to get at least one +1 before the checkin. If in doubt exercise your best judgement and don't hesitate to ask questions on this very mailing list. We're happy to have you on board and looking for many more contributions to come! With regards, Cos -- 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: Bigtop meetup ApacheCon
Count me in also. Chandra Chandrasekhar Gopal Pivotal Software Build,Release and Infrastructure Management. Chandrasekhar Gopal Pivotal Hadoop -- Build, Release and Deployments cgo...@gopivotal.com On Wed, Mar 26, 2014 at 12:23 PM, Konstantin Boudnik c...@apache.org wrote: I am in! Thanks for setting everything up Jay! Also, I did some PR spamming last night on Twitter and will post a blog with the details on blogs.apache.org later in the day. Could you add a page with the info the bigtop wiki somewhere? Thanks, Cos On Wed, Mar 26, 2014 at 01:19AM, Jay Vyas wrote: Hi bigtop ! Okay. So we finally have the meetup schedules solidified: April 7th AND 8th @ApacheCon, Denver, in the Westin - Teller Room, Please RSVP if possible in this thread so we can try to estimate how to handle food/beer etc. -- Jay Vyas http://jayunit100.blogspot.com
