Re: [VOTE] Accept Zeppelin into the Apache Incubator
+1 (non-binding) 2014-12-19 7:24 GMT+01:00 Jaideep Dhok jaideep.d...@inmobi.com: +1 (non-binding) Thanks, Jaideep On Fri, Dec 19, 2014 at 11:50 AM, Hyunsik Choi hyun...@apache.org wrote: +1 (binding) On Friday, December 19, 2014, Roman Shaposhnik r...@apache.org wrote: Following the discussion earlier: http://s.apache.org/kTp I would like to call a VOTE for accepting Zeppelin as a new Incubator project. The proposal is available at: https://wiki.apache.org/incubator/ZeppelinProposal and is also attached to the end of this email. Vote is open until at least Sunday, 21th December 2014, 23:59:00 PST [ ] +1 Accept Zeppelin into the Incubator [ ] ±0 Indifferent to the acceptance of Zeppelin [ ] -1 Do not accept Zeppelin because ... Thanks, Roman. == Abstract == Zeppelin is a collaborative data analytics and visualization tool for distributed, general-purpose data processing systems such as Apache Spark, Apache Flink, etc. == Proposal == Zeppelin is a modern web-based tool for the data scientists to collaborate over large-scale data exploration and visualization projects. It is a notebook style interpreter that enable collaborative analysis sessions sharing between users. Zeppelin is independent of the execution framework itself. Current version runs on top of Apache Spark but it has pluggable interpreter APIs to support other data processing systems. More execution frameworks could be added at a later date i.e Apache Flink, Crunch as well as SQL-like backends such as Hive, Tajo, MRQL. We have a strong preference for the project to be called Zeppelin. In case that may not be feasible, alternative names could be: “Mir”, “Yuga” or “Sora”. == Background == Large scale data analysis workflow includes multiple steps like data acquisition, pre-processing, visualization, etc and may include inter-operation of multiple different tools and technologies. With the widespread of the open source general-purpose data processing systems like Spark there is a lack of open source, modern user-friendly tools that combine strengths of interpreted language for data analysis with new in-browser visualization libraries and collaborative capabilities. Zeppelin initially started as a GUI tool for diverse set of SQL-over-Hadoop systems like Hive, Presto, Shark, etc. It was open source since its inception in Sep 2013. Later, it became clear that there was a need for a greater web-based tool for data scientists to collaborate on data exploration over the large-scale projects, not limited to SQL. So Zeppelin integrated full support of Apache Spark while adding a collaborative environment with the ability to run and share interpreter sessions in-browser == Rationale == There are no open source alternatives for a collaborative notebook-based interpreter with support of multiple distributed data processing systems. As a number of companies adopting and contributing back to Zeppelin is growing, we think that having a long-term home at Apache foundation would be a great fit for the project ensuring that processes and procedures are in place to keep project and community “healthy” and free of any commercial, political or legal faults. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. This includes moving all infrastructure that we currently maintain, such as: a website, a mailing list, an issues tracker and a Jenkins CI, as mentioned in “Required Resources” section of current proposal. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. To increase adoption the major goal for the project would be to provide integration with as much projects from Apache data ecosystem as possible, including new interpreters for Apache Hive, Apache Drill and adding Zeppelin distribution to Apache Bigtop. On the community building side the main goal is to attract a diverse set of contributors by promoting Zeppelin to wide variety of engineers, starting a Zeppelin user groups around the globe and by engaging with other existing Apache projects communities online. == Current Status == Currently, Zeppelin has 4 released versions and is used in production at a number of companies across the globe mentioned in Affiliation section. Current implementation status is pre-release with public API not being finalized yet. Current main and default backend processing engine is Apache Spark with consistent support of SparkSQL. Zeppelin is distributed as a binary package which includes an embedded webserver, application itself, a set of libraries and startup/shutdown scripts. No platform-specific installation packages are
Re: [VOTE] Accept Zeppelin into the Apache Incubator
+1 (binding) On 12/19/2014 12:29 AM, Roman Shaposhnik wrote: Following the discussion earlier: http://s.apache.org/kTp I would like to call a VOTE for accepting Zeppelin as a new Incubator project. The proposal is available at: https://wiki.apache.org/incubator/ZeppelinProposal and is also attached to the end of this email. Vote is open until at least Sunday, 21th December 2014, 23:59:00 PST [ ] +1 Accept Zeppelin into the Incubator [ ] ±0 Indifferent to the acceptance of Zeppelin [ ] -1 Do not accept Zeppelin because ... Thanks, Roman. == Abstract == Zeppelin is a collaborative data analytics and visualization tool for distributed, general-purpose data processing systems such as Apache Spark, Apache Flink, etc. == Proposal == Zeppelin is a modern web-based tool for the data scientists to collaborate over large-scale data exploration and visualization projects. It is a notebook style interpreter that enable collaborative analysis sessions sharing between users. Zeppelin is independent of the execution framework itself. Current version runs on top of Apache Spark but it has pluggable interpreter APIs to support other data processing systems. More execution frameworks could be added at a later date i.e Apache Flink, Crunch as well as SQL-like backends such as Hive, Tajo, MRQL. We have a strong preference for the project to be called Zeppelin. In case that may not be feasible, alternative names could be: “Mir”, “Yuga” or “Sora”. == Background == Large scale data analysis workflow includes multiple steps like data acquisition, pre-processing, visualization, etc and may include inter-operation of multiple different tools and technologies. With the widespread of the open source general-purpose data processing systems like Spark there is a lack of open source, modern user-friendly tools that combine strengths of interpreted language for data analysis with new in-browser visualization libraries and collaborative capabilities. Zeppelin initially started as a GUI tool for diverse set of SQL-over-Hadoop systems like Hive, Presto, Shark, etc. It was open source since its inception in Sep 2013. Later, it became clear that there was a need for a greater web-based tool for data scientists to collaborate on data exploration over the large-scale projects, not limited to SQL. So Zeppelin integrated full support of Apache Spark while adding a collaborative environment with the ability to run and share interpreter sessions in-browser == Rationale == There are no open source alternatives for a collaborative notebook-based interpreter with support of multiple distributed data processing systems. As a number of companies adopting and contributing back to Zeppelin is growing, we think that having a long-term home at Apache foundation would be a great fit for the project ensuring that processes and procedures are in place to keep project and community “healthy” and free of any commercial, political or legal faults. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. This includes moving all infrastructure that we currently maintain, such as: a website, a mailing list, an issues tracker and a Jenkins CI, as mentioned in “Required Resources” section of current proposal. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. To increase adoption the major goal for the project would be to provide integration with as much projects from Apache data ecosystem as possible, including new interpreters for Apache Hive, Apache Drill and adding Zeppelin distribution to Apache Bigtop. On the community building side the main goal is to attract a diverse set of contributors by promoting Zeppelin to wide variety of engineers, starting a Zeppelin user groups around the globe and by engaging with other existing Apache projects communities online. == Current Status == Currently, Zeppelin has 4 released versions and is used in production at a number of companies across the globe mentioned in Affiliation section. Current implementation status is pre-release with public API not being finalized yet. Current main and default backend processing engine is Apache Spark with consistent support of SparkSQL. Zeppelin is distributed as a binary package which includes an embedded webserver, application itself, a set of libraries and startup/shutdown scripts. No platform-specific installation packages are provided yet but it is something we are looking to provide as part of Apache Bigtop integration. Project codebase is currently hosted at github.com, which will form the basis of the Apache git repository. === Meritocracy === Zeppelin is an open source project that already leverages meritocracy principles. It was started by a handfull of people and now it has multiple contributors, although as the number of contribution grows we want to build a diverse developer and user community that is
Re: [VOTE] Accept Zeppelin into the Apache Incubator
+1 (binding) On 19 December 2014 at 14:09, Hadrian Zbarcea hzbar...@gmail.com wrote: +1 (binding) On 12/19/2014 12:29 AM, Roman Shaposhnik wrote: Following the discussion earlier: http://s.apache.org/kTp I would like to call a VOTE for accepting Zeppelin as a new Incubator project. The proposal is available at: https://wiki.apache.org/incubator/ZeppelinProposal and is also attached to the end of this email. Vote is open until at least Sunday, 21th December 2014, 23:59:00 PST [ ] +1 Accept Zeppelin into the Incubator [ ] ±0 Indifferent to the acceptance of Zeppelin [ ] -1 Do not accept Zeppelin because ... Thanks, Roman. == Abstract == Zeppelin is a collaborative data analytics and visualization tool for distributed, general-purpose data processing systems such as Apache Spark, Apache Flink, etc. == Proposal == Zeppelin is a modern web-based tool for the data scientists to collaborate over large-scale data exploration and visualization projects. It is a notebook style interpreter that enable collaborative analysis sessions sharing between users. Zeppelin is independent of the execution framework itself. Current version runs on top of Apache Spark but it has pluggable interpreter APIs to support other data processing systems. More execution frameworks could be added at a later date i.e Apache Flink, Crunch as well as SQL-like backends such as Hive, Tajo, MRQL. We have a strong preference for the project to be called Zeppelin. In case that may not be feasible, alternative names could be: “Mir”, “Yuga” or “Sora”. == Background == Large scale data analysis workflow includes multiple steps like data acquisition, pre-processing, visualization, etc and may include inter-operation of multiple different tools and technologies. With the widespread of the open source general-purpose data processing systems like Spark there is a lack of open source, modern user-friendly tools that combine strengths of interpreted language for data analysis with new in-browser visualization libraries and collaborative capabilities. Zeppelin initially started as a GUI tool for diverse set of SQL-over-Hadoop systems like Hive, Presto, Shark, etc. It was open source since its inception in Sep 2013. Later, it became clear that there was a need for a greater web-based tool for data scientists to collaborate on data exploration over the large-scale projects, not limited to SQL. So Zeppelin integrated full support of Apache Spark while adding a collaborative environment with the ability to run and share interpreter sessions in-browser == Rationale == There are no open source alternatives for a collaborative notebook-based interpreter with support of multiple distributed data processing systems. As a number of companies adopting and contributing back to Zeppelin is growing, we think that having a long-term home at Apache foundation would be a great fit for the project ensuring that processes and procedures are in place to keep project and community “healthy” and free of any commercial, political or legal faults. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. This includes moving all infrastructure that we currently maintain, such as: a website, a mailing list, an issues tracker and a Jenkins CI, as mentioned in “Required Resources” section of current proposal. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. To increase adoption the major goal for the project would be to provide integration with as much projects from Apache data ecosystem as possible, including new interpreters for Apache Hive, Apache Drill and adding Zeppelin distribution to Apache Bigtop. On the community building side the main goal is to attract a diverse set of contributors by promoting Zeppelin to wide variety of engineers, starting a Zeppelin user groups around the globe and by engaging with other existing Apache projects communities online. == Current Status == Currently, Zeppelin has 4 released versions and is used in production at a number of companies across the globe mentioned in Affiliation section. Current implementation status is pre-release with public API not being finalized yet. Current main and default backend processing engine is Apache Spark with consistent support of SparkSQL. Zeppelin is distributed as a binary package which includes an embedded webserver, application itself, a set of libraries and startup/shutdown scripts. No platform-specific installation packages are provided yet but it is something we are looking to provide as part of Apache Bigtop integration. Project codebase is currently hosted at github.com, which will form the basis of the Apache git repository. === Meritocracy === Zeppelin is an open source project that already leverages meritocracy principles. It was started
Re: [VOTE] Accept Zeppelin into the Apache Incubator
+1 (non-binding) Thanks Naresh On Fri, Dec 19, 2014 at 4:32 PM, Fabian Hueske fhue...@apache.org wrote: +1 (non-binding) 2014-12-19 7:24 GMT+01:00 Jaideep Dhok jaideep.d...@inmobi.com: +1 (non-binding) Thanks, Jaideep On Fri, Dec 19, 2014 at 11:50 AM, Hyunsik Choi hyun...@apache.org wrote: +1 (binding) On Friday, December 19, 2014, Roman Shaposhnik r...@apache.org wrote: Following the discussion earlier: http://s.apache.org/kTp I would like to call a VOTE for accepting Zeppelin as a new Incubator project. The proposal is available at: https://wiki.apache.org/incubator/ZeppelinProposal and is also attached to the end of this email. Vote is open until at least Sunday, 21th December 2014, 23:59:00 PST [ ] +1 Accept Zeppelin into the Incubator [ ] ±0 Indifferent to the acceptance of Zeppelin [ ] -1 Do not accept Zeppelin because ... Thanks, Roman. == Abstract == Zeppelin is a collaborative data analytics and visualization tool for distributed, general-purpose data processing systems such as Apache Spark, Apache Flink, etc. == Proposal == Zeppelin is a modern web-based tool for the data scientists to collaborate over large-scale data exploration and visualization projects. It is a notebook style interpreter that enable collaborative analysis sessions sharing between users. Zeppelin is independent of the execution framework itself. Current version runs on top of Apache Spark but it has pluggable interpreter APIs to support other data processing systems. More execution frameworks could be added at a later date i.e Apache Flink, Crunch as well as SQL-like backends such as Hive, Tajo, MRQL. We have a strong preference for the project to be called Zeppelin. In case that may not be feasible, alternative names could be: “Mir”, “Yuga” or “Sora”. == Background == Large scale data analysis workflow includes multiple steps like data acquisition, pre-processing, visualization, etc and may include inter-operation of multiple different tools and technologies. With the widespread of the open source general-purpose data processing systems like Spark there is a lack of open source, modern user-friendly tools that combine strengths of interpreted language for data analysis with new in-browser visualization libraries and collaborative capabilities. Zeppelin initially started as a GUI tool for diverse set of SQL-over-Hadoop systems like Hive, Presto, Shark, etc. It was open source since its inception in Sep 2013. Later, it became clear that there was a need for a greater web-based tool for data scientists to collaborate on data exploration over the large-scale projects, not limited to SQL. So Zeppelin integrated full support of Apache Spark while adding a collaborative environment with the ability to run and share interpreter sessions in-browser == Rationale == There are no open source alternatives for a collaborative notebook-based interpreter with support of multiple distributed data processing systems. As a number of companies adopting and contributing back to Zeppelin is growing, we think that having a long-term home at Apache foundation would be a great fit for the project ensuring that processes and procedures are in place to keep project and community “healthy” and free of any commercial, political or legal faults. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. This includes moving all infrastructure that we currently maintain, such as: a website, a mailing list, an issues tracker and a Jenkins CI, as mentioned in “Required Resources” section of current proposal. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. To increase adoption the major goal for the project would be to provide integration with as much projects from Apache data ecosystem as possible, including new interpreters for Apache Hive, Apache Drill and adding Zeppelin distribution to Apache Bigtop. On the community building side the main goal is to attract a diverse set of contributors by promoting Zeppelin to wide variety of engineers, starting a Zeppelin user groups around the globe and by engaging with other existing Apache projects communities online. == Current Status == Currently, Zeppelin has 4 released versions and is used in production at a number of companies across the globe mentioned in Affiliation section. Current implementation status is pre-release with public API not being finalized yet. Current main and default backend processing engine is Apache Spark with consistent support of
Re: [VOTE] Release Apache Brooklyn 0.7.0-M2-incubating [rc4]
+1 (binding) Regards JB On 12/18/2014 05:42 PM, Richard Downer wrote: This is to call for a vote for the source release of Apache Brooklyn 0.7.0-M2-incubating. Call for votes on d...@brooklyn.incubator.apache.org: https://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201412.mbox/%3CCABQFKi1P58JJhsgCzXGeW6_fpwHt1imttHENtYPERAgM0nWTGg%40mail.gmail.com%3E Result of vote on d...@brooklyn.incubator.apache.org: https://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201412.mbox/%3CCABQFKi0hrAOkQh1wtke-nQsxxNyVXKqnJXVvsNU5EchAHcxhNw%40mail.gmail.com%3E One of the votes on d...@brooklyn.incubator.apache.org is from IPMC member Chip Childers, and I understand that his vote will carry forward to this IPMC vote. The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/incubator/brooklyn/apache-brooklyn-0.7.0-M2-incubating-rc4 The Git commit ID is 94b42b85e80efd817f951326238864e37edc2cb0 https://git-wip-us.apache.org/repos/asf?p=incubator-brooklyn.git;a=commit;h=94b42b85e80efd817f951326238864e37edc2cb0 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/richard.asc https://people.apache.org/keys/committer/chipchilders.asc Checksums of apache-brooklyn-0.7.0-M2-incubating-rc4.tar.gz: MD5: a30cbc287f4d72b983e9c08c2074690f SHA1: f573c49e36d806d1fbc8349b03ea5ffd1ec01751 SHA256: e3c2a844c5816db2c0ac4ae6c6d9c43a64dc51c98546589f14413baf98fad2cb KEYS file available here: https://dist.apache.org/repos/dist/release/incubator/brooklyn/KEYS Please vote on releasing this package as Apache Brooklyn 0.7.0-M2-incubating. The vote will be open for 72 hours. [ ] +1 Release this package as Apache Brooklyn 0.7.0-M2-incubating [ ] +0 no opinion [ ] -1 Do not release this package because ... Thanks, Richard Downer - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Samza from the Incubator
+1 (non-binding) — Hitesh On Dec 12, 2014, at 3:54 PM, Jakob Homan jgho...@gmail.com wrote: Restarting vote having fixed resolution detail, dastardly AWOL paragraph breaks and removed nod to increased diversity in introduction. The Samza podling community has voted to graduate from the Incubator. The vote passed with 17 +1s and no -1s or +/-0s. Binding +1s x 10 : Jakob, Chinmay, Yan, Chris Riccomini, Sriram, Zhijie, Martin, Roman, Garry, Chris Douglas Non-binding +1s x 7: Claudio, TJ, Robert, Roger, Danny, Jon, Yi Links to votes and discussions: http://s.apache.org/samzaGradResult http://s.apache.org/samzaGradDiscuss Samza has been incubating for a bit more than a year. In that time the community has: * Completed two Incubator-approved releases * Opened nearly 500 JIRAs * Added five new committers/PMC members. This thread is to vote on the graduation resolution Samza has approved. It will run for at least 96 hours (to Tuesday, 12/22 4pm PST, the extra day to accommodate the weekend and holiday schedule). [ ] +1 Graduate Apache Samza from the Incubator. [ ] +0 Don't care. [ ] -1 Don't graduate Apache Samza from the Incubator because ... Here's my binding vote: +1. -Jakob WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to low-latency, distributed processing of streaming data. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Samza Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Samza Project be and hereby is responsible for the creation and maintenance of software related to low-latency, distributed processing of streaming data; and be it further RESOLVED, that the office of Vice President, Apache Samza be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Samza Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Samza Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Samza Project: * Chinmay Soman cpsoman at apache dot org * Chris Riccomini criccomini at apache dot org * Garry Turkington garryturk at apache dot org * Jakob Homan jghoman at apache dot org * Jay Kreps jkreps at apache dot org * Martin Kleppman martinkl at apache dot org * Sriram Subramanian sriramsub at apache dot org * Yan Fang yanfang at apache dot org * Zhijie Shen zjshen at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Chris Riccomini be appointed to the office of Vice President, Apache Samza, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Samza Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Samza podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Samza podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator report sign-off
I noted in my comments on the recent Incubator board report that I am concerned, month after month, at the number of podlings that have no mentor sign-off at all, as well as the ones where a minority of the mentors sign-off. I certainly don't expect that every mentor has their full attention on a podling every month, but I do expect that a podling that cares about its incubation will seek out that mentor sign-off, and that the mentors who have committed to help a podling into the family will have a few moments every few months to look in and approve a report. The result, unfortunately, is that we have projects graduating with no notion of the importance of reporting, and so we have TLPs that look at reporting as a checkbox, submit exactly the same cut-and-paste report each month, some of them without even changing stats and dates, or skip their reporting entirely. I don't mean to point fingers here - this is a problem that has existed literally since the beginning of the Incubator, and I'm not innocent of it myself. Indeed, I don't show up often enough even on this list. But I wonder if we might, as the Board does, reject reports that have no sign-off, and force projects to report again the following month, in an attempt to require them to engage with their mentor(s) a little more? This seems like a small, easily reversible, step, that has a good chance of achieving something. Thoughts? (Please note that I originally started this thread on the IPMC list, and some discussion has happened there, but it has been pointed out that it's more appropriate to have this conversation in public.) -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
Hi Rich, As I noted previously, at least from my point of view we wouldn't be accepting a podling's report that wasn't signed off on. I had deliberately added a section to the report header separating podlings that didn't report (and hence their reports not being included) and podlings that did report but no mentor sign off (report included in the incubator's report). My intention with doing this was that both of these groups would be marked as monthly. I only did the first group, mostly on a time constraint. The others should have been marked as well, but I've held off considering this discussion first. John On Fri Dec 19 2014 at 12:11:44 PM Rich Bowen rbo...@rcbowen.com wrote: I noted in my comments on the recent Incubator board report that I am concerned, month after month, at the number of podlings that have no mentor sign-off at all, as well as the ones where a minority of the mentors sign-off. I certainly don't expect that every mentor has their full attention on a podling every month, but I do expect that a podling that cares about its incubation will seek out that mentor sign-off, and that the mentors who have committed to help a podling into the family will have a few moments every few months to look in and approve a report. The result, unfortunately, is that we have projects graduating with no notion of the importance of reporting, and so we have TLPs that look at reporting as a checkbox, submit exactly the same cut-and-paste report each month, some of them without even changing stats and dates, or skip their reporting entirely. I don't mean to point fingers here - this is a problem that has existed literally since the beginning of the Incubator, and I'm not innocent of it myself. Indeed, I don't show up often enough even on this list. But I wonder if we might, as the Board does, reject reports that have no sign-off, and force projects to report again the following month, in an attempt to require them to engage with their mentor(s) a little more? This seems like a small, easily reversible, step, that has a good chance of achieving something. Thoughts? (Please note that I originally started this thread on the IPMC list, and some discussion has happened there, but it has been pointed out that it's more appropriate to have this conversation in public.) -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
Hi Rich! Thanks for raising this point and giving us a bit more of a forcing function to tackle an old problem: accountability for mentors. On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote: I certainly don't expect that every mentor has their full attention on a podling every month, but I do expect that a podling that cares about its incubation will seek out that mentor sign-off, and that the mentors who have committed to help a podling into the family will have a few moments every few months to look in and approve a report. I've been thinking about this for quite some time (and trying to seek a solution by various means) and it seems to be that we have to start from a very basic expectation setting. First of all, *my* expectation is that multiple mentors on the project are more of redundancy or HA consideration. IOW, my expectation that a project needs to have at least one active mentor at all times, but it doesn't have to be the same person. Thus, I expect at least a signle sign-off on the report and I don't mind if it ends up being a single one too much. Second biggest expectation that I have is that mentors are extension of the IPMC, not part of the poddling. They are akin to professors or faculty members -- they are not part of the student body. As such we, as IPMC are accountable to make sure that mentors perform their duties. My expectation is that it is as unfair to ask poddling to actively pursue mentors who are missing in action as it would be unfair to ask students to hire detectives to hunt down professors who don't show up for class. What is fair, is to provide poddlings with a semi-format feedback channel for IPMC to monitor things like mentors MIA. I would like to pause here and ask everybody to chime in with what they thing are the right expectations on the above two points. But I wonder if we might, as the Board does, reject reports that have no sign-off, and force projects to report again the following month, in an attempt to require them to engage with their mentor(s) a little more? As was pointed by John, we're already rejecting reports with no mentor sign-off. Before we potentially take it one step further I'd like to get clarity on the expectations first (and then I can volunteer to document that as well!). Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote: I noted in my comments on the recent Incubator board report that I am concerned, month after month, at the number of podlings that have no mentor sign-off at all, as well as the ones where a minority of the mentors sign-off. Thanks, Rich! Thoughtful, constructive feedback like this from a Board member reviewing our report will help the Incubator improve as a project. Wouldn't it be great if we could provide such feedback more consistently to podlings when they go to the trouble of preparing their own reports? Every report is an opportunity to open a conversation... But I wonder if we might, as the Board does, reject reports that have no sign-off, and force projects to report again the following month, in an attempt to require them to engage with their mentor(s) a little more? This seems like a small, easily reversible, step, that has a good chance of achieving something. (Adapting my response from the private list...) +1 to reject reports where not a single Mentor has signed off and to require the podling to report next month. The mechanism we use for this is to have the Report Manager edit content/podlings.xml add the monthly attribute to the metadata for the relevant podlings podlings. Such tasks are documented in report_runbook.py. Unfortunately manual XML editing is fiddly and it's easy to either fail to add or fail to remove, but the system is better than it was before. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 10:12 AM, Marvin Humphrey mar...@rectangular.com wrote: (Adapting my response from the private list...) +1 to reject reports where not a single Mentor has signed off and to require the podling to report next month. I am confused. We're already doing that. Are you just +1ing an existing practice? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. Maybe we should simply scrap the idea of mentors and change the role of the champion to one of an initial committer who will help build an Apache project as it incubates and into being a TLP. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. If a champion's priorities change during the course of incubation then the project must find another champion (potentially from within their own ranks) who is sufficiently qualified and committed to take on the responsibility. The important thing is that the Champion is personally invested in seeing the podling succeed and acts as a true mentor (as opposed to someone with a title and an entry on a web page). The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. This model is almost identical to the way the board and TLPs work (where Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) are roughly equivalent to Directors and he monthly meeting is roughly equivalent to the monthly board meeting to review TLP reports). I've designed it this way (and proposed the same solution before) because it is proven to work for TLPs and we have tooling to assist with the process. I look forward to the PMC tearing this strawman proposal apart and (most importantly) suggesting alternatives and/or tweaks of value. We've been skirting this issue for far too long. Things have improved (thanks to all who have worked hard on this), but we have not yet solved the problem. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Friday, December 19, 2014 10:11 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off Hi Rich! Thanks for raising this point and giving us a bit more of a forcing function to tackle an old problem: accountability for mentors. On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote: I certainly don't expect that every mentor has their full attention on a podling every month, but I do expect that a podling that cares about its incubation will seek out that mentor sign-off, and that the mentors who have committed to help a podling into the family will have a few moments every few months to look in and approve a report. I've been thinking about this for quite some time (and trying to seek a solution by various means) and it seems to be that we have to start from a very basic expectation setting. First of all, *my* expectation is that multiple mentors on the project are more of redundancy or HA consideration. IOW, my expectation that a project needs to have at least one active mentor at all times, but it doesn't have to be the same person. Thus, I expect at least a signle sign-off on the report and I don't mind if it ends up being a single one too much. Second biggest expectation that I have is that mentors are extension of the IPMC, not part of the poddling. They are akin to professors or faculty members -- they are not part of the student body. As such we, as IPMC are accountable to make sure that mentors perform their duties. My expectation is that it is as unfair to ask poddling to actively pursue mentors who are missing in action as it would be unfair to ask students to hire detectives to hunt down professors who don't show up for class. What is fair, is to provide poddlings with a semi-format feedback channel for IPMC to monitor things like mentors MIA. I would like to pause here and ask everybody to chime in with what they thing are the right expectations on the above two points. But I wonder if we might, as the Board does, reject reports that have no sign-off, and force projects to report again the following month, in an attempt to require them to engage with their mentor(s) a little more? As was pointed by John, we're already rejecting reports with no mentor sign-off. Before we potentially take it one step further I'd like to get clarity on the expectations first (and then I can
Re: Incubator report sign-off
And how could the below proposal return without me passing along my comment regarding it - if we’re going to emulate the board and TLPs, etc., why emulate it when we could cut through the middle man and simply rely on the board to do so? I guess to protect the board from an influx of “incubating” projects (+30-40 at this point in time?) I myself as a board member would welcome this. What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. TL;DR 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. My 2c. Cheers, Chris -Original Message- From: Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, December 19, 2014 at 11:00 AM To: general@incubator.apache.org general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. Maybe we should simply scrap the idea of mentors and change the role of the champion to one of an initial committer who will help build an Apache project as it incubates and into being a TLP. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. If a champion's priorities change during the course of incubation then the project must find another champion (potentially from within their own ranks) who is sufficiently qualified and committed to take on the responsibility. The important thing is that the Champion is personally invested in seeing the podling succeed and acts as a true mentor (as opposed to someone with a title and an entry on a web page). The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. This model is almost identical to the way the board and TLPs work (where Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) are roughly equivalent to Directors and he monthly meeting is roughly equivalent to the monthly board meeting to review TLP reports). I've designed it this way (and proposed the same solution before) because it is proven to work for TLPs and we have tooling to assist with the process. I look forward to the PMC tearing this strawman proposal apart and (most importantly) suggesting alternatives and/or tweaks of value. We've been skirting this issue for far too long. Things have improved (thanks to all who have worked hard on this), but we have not yet solved the problem. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Friday, December 19, 2014 10:11 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off Hi Rich! Thanks for raising this point and giving us a bit more of a forcing function to tackle an old problem: accountability
Re: Incubator report sign-off
+1 for Chris's proposal. Without diminishing the creativity applied to solving problems with the incubator, perhaps the better solution is to trade those problems for tractable ones. -C On Fri, Dec 19, 2014 at 11:20 AM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: And how could the below proposal return without me passing along my comment regarding it - if we’re going to emulate the board and TLPs, etc., why emulate it when we could cut through the middle man and simply rely on the board to do so? I guess to protect the board from an influx of “incubating” projects (+30-40 at this point in time?) I myself as a board member would welcome this. What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. TL;DR 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. My 2c. Cheers, Chris -Original Message- From: Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, December 19, 2014 at 11:00 AM To: general@incubator.apache.org general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. Maybe we should simply scrap the idea of mentors and change the role of the champion to one of an initial committer who will help build an Apache project as it incubates and into being a TLP. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. If a champion's priorities change during the course of incubation then the project must find another champion (potentially from within their own ranks) who is sufficiently qualified and committed to take on the responsibility. The important thing is that the Champion is personally invested in seeing the podling succeed and acts as a true mentor (as opposed to someone with a title and an entry on a web page). The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. This model is almost identical to the way the board and TLPs work (where Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) are roughly equivalent to Directors and he monthly meeting is roughly equivalent to the monthly board meeting to review TLP reports). I've designed it this way (and proposed the same solution before) because it is proven to work for TLPs and we have tooling to assist with the process. I look forward to the PMC tearing this strawman proposal apart and (most importantly) suggesting alternatives and/or tweaks of value. We've been skirting this issue for far too long. Things have improved (thanks to all who have worked hard on this), but we have not yet solved the problem. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message-
Re: Incubator report sign-off
Back when I was trying to be the chair of this operation, we (ChrisM I others) had a lovely old food fight about Chris M's proposal. It seems to me that the fundamental situation as I saw it remains: this is a proposal to the board to dissolve the IPMC and replace it with something else. And just to be clear: I think that it's a _good idea_ as a proposal to the board. I think that it amounts to making the Foundation's policy be: You can launch a new project in the Foundation if you can recruit three foundation members (or others acceptable to the board) as the nucleus of your PMC to teach you the ropes and ensure that policies are respected; from the start, you're an 'incubating TLP' reporting to the board like all other TLPs. I don't think that those three people have, necessarily to be coders. But they have to be fully engaged -- they have to be members of the community and the PMC. It seems to me that any scheme short of this is guaranteed to end up right back where we are; struggling to simulate working PMCs with shepherds and mentors and champions and, I don't know, curators and wardens and counselors. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Votes for git repos - commit id vs tag
On 12/18/2014 05:58 AM, John D. Ament wrote: All, I was looking through the incubator site and I don't see anything definite. Whenever a podling goes for a vote, and they include a git tag in their vote message, it's typically asked to change to a commit id. It seems to me this is done for the reproducible builds concept. Tags are mutable, and therefore could be changed and rebuilding a tag could give you a different result. So, is this the right understanding? Do we want to ask podlings to always submit a git commit id? If so, is there a place in the website we can clarify this? Thanks, John I recently found this confusing with the first parquet-format release. I thought that both commit id and tag were optional, given that the actual release candidate is a signed tarball (actually, the necessary source code to build the project [1]). We can't necessarily recover the commit id from the tarball because the parent information is lost [2], so requiring the commit id is only useful for convenience and validating that a new tarball from git at the commit id matches the vote tarball. Is this validation done? Is it a requirement? If it isn't a requirement for a commit to match what is being voted on, then does it matter whether we use a tag for convenience or a commit id? We could also accept signed tags, though I don't know if there are issues that would prevent it. rb [1]: https://www.apache.org/dev/release-publishing.html#valid [2]: Unless using `git archive`: http://git-scm.com/docs/git-archive -- Ryan Blue - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
Assuming that the project VP is someone personally invested in the project I have no real problem with the core of this proposal. If they are not personally invested, if they are instead a semi-random person from the IPMC then I do not see how this will address the real problem (which is *not* having people tick a box on a report). I do question the need to dissolve the IPMC, but we've been over that before and at this point is probably an unnecessary distraction from the important topic of ensuring mentors have a vested interest in the project. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Friday, December 19, 2014 11:21 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off And how could the below proposal return without me passing along my comment regarding it - if we’re going to emulate the board and TLPs, etc., why emulate it when we could cut through the middle man and simply rely on the board to do so? I guess to protect the board from an influx of “incubating” projects (+30-40 at this point in time?) I myself as a board member would welcome this. What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. TL;DR 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. My 2c. Cheers, Chris -Original Message- From: Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, December 19, 2014 at 11:00 AM To: general@incubator.apache.org general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. Maybe we should simply scrap the idea of mentors and change the role of the champion to one of an initial committer who will help build an Apache project as it incubates and into being a TLP. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. If a champion's priorities change during the course of incubation then the project must find another champion (potentially from within their own ranks) who is sufficiently qualified and committed to take on the responsibility. The important thing is that the Champion is personally invested in seeing the podling succeed and acts as a true mentor (as opposed to someone with a title and an entry on a web page). The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. This model is almost identical to the way the board and TLPs work (where Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) are roughly equivalent to Directors and he monthly meeting is roughly equivalent to the monthly board meeting to review TLP
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 12:45 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: I do question the need to dissolve the IPMC Indeed. Chris' proposal is not exclusive with keeping the Incubator as it is. Folks could currently submit a resolution to the board to start a TLP and see what happens. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
As a participant, I have two concerns about a player-mentor requirement. 1. Sustainability. In many ways, it is mentors who need to have their attention on The Apache Way and cultivating a sustainable project. That means, from my perspective, that mentors need to encourage others to do things, especially around project management and procedural matters, and not just take on matters without leaving any bread crumbs. It seems important that others learn how to do that sort of thing too, whether or not special karma is eventually required to perform the same activities. 2. I have learned repeatedly, and it is evidently well-known, that a developer is his own worst project manager. It has to do with attention being at a completely different place when heads-down in development tasks than when heads-up watching the horizon and keeping objectives and current effort aligned. When I am in developer mode, I need someone else to pull my attention out of the weeds and look to see what course I am on and where I am at on that course. I remember in the 60s when a colleague had ended up managing a project at GE Medical Systems (or something similar) and he confessed that his team made a terrible mistake -- they allowed him to program on their project. I'm not saying that a mentor could not be an effective player. I think doing it well while mentoring is not common and it might interfere with training and development as well. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 11:01 To: general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Votes for git repos - commit id vs tag
I recently found this confusing with the first parquet-format release. I thought that both commit id and tag were optional, given that the actual release candidate is a signed tarball (actually, the necessary source code to build the project [1]). Commit id is not optional. Tag is. The release candidate is a signed tarball, but I should be able to take your source tree from the commit id, and get the exact same tarball by following your release process. (Note that this applies only to source tarballs - but those are the ones that matter). If I can't arrive at the same exact tarball there's something amiss with the release or the process. We can't necessarily recover the commit id from the tarball because the parent information is lost [2], so requiring the commit id is only useful for convenience and validating that a new tarball from git at the commit id matches the vote tarball. Is this validation done? Is it a requirement? If it isn't a requirement for a commit to match what is being voted on, then does it matter whether we use a tag for convenience or a commit id? We could also accept signed tags, though I don't know if there are issues that would prevent it. rb [1]: https://www.apache.org/dev/release-publishing.html#valid [2]: Unless using `git archive`: http://git-scm.com/docs/git-archive -- Ryan Blue - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
Thank you Benson. And that food fight taught me a lot too and so did the conversations with you. Cheers and happy holidays. Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Benson Margulies bimargul...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, December 19, 2014 at 12:15 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator report sign-off Back when I was trying to be the chair of this operation, we (ChrisM I others) had a lovely old food fight about Chris M's proposal. It seems to me that the fundamental situation as I saw it remains: this is a proposal to the board to dissolve the IPMC and replace it with something else. And just to be clear: I think that it's a _good idea_ as a proposal to the board. I think that it amounts to making the Foundation's policy be: You can launch a new project in the Foundation if you can recruit three foundation members (or others acceptable to the board) as the nucleus of your PMC to teach you the ropes and ensure that policies are respected; from the start, you're an 'incubating TLP' reporting to the board like all other TLPs. I don't think that those three people have, necessarily to be coders. But they have to be fully engaged -- they have to be members of the community and the PMC. It seems to me that any scheme short of this is guaranteed to end up right back where we are; struggling to simulate working PMCs with shepherds and mentors and champions and, I don't know, curators and wardens and counselors. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[OFF-LIST] RE: Incubator report sign-off
Now we are getting somewhere? This post disappeared too. But yours in the same thread before it didn't. Are you replying to Chris's post or another here? Was there anything else at all different? Is there more than one way you read from the lists (i.e., via a news reader or something)? -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 12:46 To: general@incubator.apache.org Subject: RE: Incubator report sign-off - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
Are we top posting now? My comments below Ross’ On 19 Dec 2014, at 16:33, Dennis E. Hamilton dennis.hamil...@acm.org wrote: As a participant, I have two concerns about a player-mentor requirement. 1. Sustainability. In many ways, it is mentors who need to have their attention on The Apache Way and cultivating a sustainable project. That means, from my perspective, that mentors need to encourage others to do things, especially around project management and procedural matters, and not just take on matters without leaving any bread crumbs. It seems important that others learn how to do that sort of thing too, whether or not special karma is eventually required to perform the same activities. 2. I have learned repeatedly, and it is evidently well-known, that a developer is his own worst project manager. It has to do with attention being at a completely different place when heads-down in development tasks than when heads-up watching the horizon and keeping objectives and current effort aligned. When I am in developer mode, I need someone else to pull my attention out of the weeds and look to see what course I am on and where I am at on that course. I remember in the 60s when a colleague had ended up managing a project at GE Medical Systems (or something similar) and he confessed that his team made a terrible mistake -- they allowed him to program on their project. I'm not saying that a mentor could not be an effective player. I think doing it well while mentoring is not common and it might interfere with training and development as well. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 11:01 To: general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. [ … ] Accepting Dennis’ point, but I think that there’s a difference between being in a large corporation doing in-house work and participating part time as a mentor. It’s as if I were (as I do) to teach courses after work that relate to my expertise but are not identical to it, if only because I like to think that I’m more advanced than any student I’d have. In prior instances where we’ve had mentors, or where I know of them, e.g., Mozilla’s Firefox extension program at Seneca College, Toronto, where the lead instructor of the classroom of students (as well as of individual pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to teach, I believe; that, at least, was at the arrangement we had with Seneca for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the argument presented to me by the instructor was that it was essential to be an active developer, at least if one were instructing students on both the collaborative dynamics as well as the code itself. To be sure, one need not be immersed in the project (i.e., have it as a day job), but being engaged and current with the latest was important. But to stipulate it as a requirement? Why? Why make it a requirement and not just a recommendation, albeit a strong one? the only thing gained by making it a requirement—and in bold, too—is to have a tool by which one could eliminate candidates. And I do not think that is in the spirit of a pragmatic open source project. louis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [OFF-LIST] RE: Incubator report sign-off
Sorry, I forgot to change the automatic reply to list when moving this to an off-list investigation. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Friday, December 19, 2014 15:07 To: general@incubator.apache.org Subject: [OFF-LIST] RE: Incubator report sign-off Now we are getting somewhere? This post disappeared too. But yours in the same thread before it didn't. Are you replying to Chris's post or another here? Was there anything else at all different? Is there more than one way you read from the lists (i.e., via a news reader or something)? -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 12:46 To: general@incubator.apache.org Subject: RE: Incubator report sign-off - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 6:09 PM, Louis Suárez-Potts lui...@gmail.com wrote: Are we top posting now? My comments below Ross’ On 19 Dec 2014, at 16:33, Dennis E. Hamilton dennis.hamil...@acm.org wrote: As a participant, I have two concerns about a player-mentor requirement. 1. Sustainability. In many ways, it is mentors who need to have their attention on The Apache Way and cultivating a sustainable project. That means, from my perspective, that mentors need to encourage others to do things, especially around project management and procedural matters, and not just take on matters without leaving any bread crumbs. It seems important that others learn how to do that sort of thing too, whether or not special karma is eventually required to perform the same activities. 2. I have learned repeatedly, and it is evidently well-known, that a developer is his own worst project manager. It has to do with attention being at a completely different place when heads-down in development tasks than when heads-up watching the horizon and keeping objectives and current effort aligned. When I am in developer mode, I need someone else to pull my attention out of the weeds and look to see what course I am on and where I am at on that course. I remember in the 60s when a colleague had ended up managing a project at GE Medical Systems (or something similar) and he confessed that his team made a terrible mistake -- they allowed him to program on their project. I'm not saying that a mentor could not be an effective player. I think doing it well while mentoring is not common and it might interfere with training and development as well. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 11:01 To: general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. [ … ] Accepting Dennis’ point, but I think that there’s a difference between being in a large corporation doing in-house work and participating part time as a mentor. It’s as if I were (as I do) to teach courses after work that relate to my expertise but are not identical to it, if only because I like to think that I’m more advanced than any student I’d have. In prior instances where we’ve had mentors, or where I know of them, e.g., Mozilla’s Firefox extension program at Seneca College, Toronto, where the lead instructor of the classroom of students (as well as of individual pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to teach, I believe; that, at least, was at the arrangement we had with Seneca for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the argument presented to me by the instructor was that it was essential to be an active developer, at least if one were instructing students on both the collaborative dynamics as well as the code itself. To be sure, one need not be immersed in the project (i.e., have it as a day job), but being engaged and current with the latest was important. But to stipulate it as a requirement? Why? Why make it a requirement and not just a recommendation, albeit a strong one? the only thing gained by making it a requirement—and in bold, too—is to have a tool by which one could eliminate candidates. And I do not think that is in the spirit of a pragmatic open source project. louis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org I'm not top-posting. I think the 'involved mentors' is part of an attempt to resolve several conflicting desires. The mentor model is that the PPMC members start out being all of the doers, and the mentors are coaches and supervisors. Conflict #1: coaching and supervising is not always a happy combination. Conflict #2: coaching means staying in the background to a large extend, as per Ross' statement. 'In the background' can be perilously close to 'gone fishing.' How does the IPMC (or whomever) tell the difference? Conflict #3: there's a shortage of people to mentor, and that leads to people with good intentions signing up and then failing to deliver. Over years, we've send
Re: Incubator report sign-off
On 19 Dec 2014, at 18:30, Benson Margulies bimargul...@gmail.com wrote: On Fri, Dec 19, 2014 at 6:09 PM, Louis Suárez-Potts lui...@gmail.com wrote: Are we top posting now? My comments below Ross’ On 19 Dec 2014, at 16:33, Dennis E. Hamilton dennis.hamil...@acm.org wrote: As a participant, I have two concerns about a player-mentor requirement. 1. Sustainability. In many ways, it is mentors who need to have their attention on The Apache Way and cultivating a sustainable project. That means, from my perspective, that mentors need to encourage others to do things, especially around project management and procedural matters, and not just take on matters without leaving any bread crumbs. It seems important that others learn how to do that sort of thing too, whether or not special karma is eventually required to perform the same activities. 2. I have learned repeatedly, and it is evidently well-known, that a developer is his own worst project manager. It has to do with attention being at a completely different place when heads-down in development tasks than when heads-up watching the horizon and keeping objectives and current effort aligned. When I am in developer mode, I need someone else to pull my attention out of the weeds and look to see what course I am on and where I am at on that course. I remember in the 60s when a colleague had ended up managing a project at GE Medical Systems (or something similar) and he confessed that his team made a terrible mistake -- they allowed him to program on their project. I'm not saying that a mentor could not be an effective player. I think doing it well while mentoring is not common and it might interfere with training and development as well. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 11:01 To: general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. [ … ] Accepting Dennis’ point, but I think that there’s a difference between being in a large corporation doing in-house work and participating part time as a mentor. It’s as if I were (as I do) to teach courses after work that relate to my expertise but are not identical to it, if only because I like to think that I’m more advanced than any student I’d have. In prior instances where we’ve had mentors, or where I know of them, e.g., Mozilla’s Firefox extension program at Seneca College, Toronto, where the lead instructor of the classroom of students (as well as of individual pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to teach, I believe; that, at least, was at the arrangement we had with Seneca for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the argument presented to me by the instructor was that it was essential to be an active developer, at least if one were instructing students on both the collaborative dynamics as well as the code itself. To be sure, one need not be immersed in the project (i.e., have it as a day job), but being engaged and current with the latest was important. But to stipulate it as a requirement? Why? Why make it a requirement and not just a recommendation, albeit a strong one? the only thing gained by making it a requirement—and in bold, too—is to have a tool by which one could eliminate candidates. And I do not think that is in the spirit of a pragmatic open source project. louis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org I'm not top-posting. I think the 'involved mentors' is part of an attempt to resolve several conflicting desires. The mentor model is that the PPMC members start out being all of the doers, and the mentors are coaches and supervisors. Conflict #1: coaching and supervising is not always a happy combination. Conflict #2: coaching means staying in the background to a large extend, as per Ross' statement. 'In the background' can be perilously close to 'gone fishing.' How does the IPMC (or whomever) tell the difference? Conflict #3: there's a shortage of people
Re: [VOTE] Accept Zeppelin into the Apache Incubator
+1 (binding) Regards, Arvind Prabhakar On Thu, Dec 18, 2014 at 9:29 PM, Roman Shaposhnik r...@apache.org wrote: Following the discussion earlier: http://s.apache.org/kTp I would like to call a VOTE for accepting Zeppelin as a new Incubator project. The proposal is available at: https://wiki.apache.org/incubator/ZeppelinProposal and is also attached to the end of this email. Vote is open until at least Sunday, 21th December 2014, 23:59:00 PST [ ] +1 Accept Zeppelin into the Incubator [ ] ±0 Indifferent to the acceptance of Zeppelin [ ] -1 Do not accept Zeppelin because ... Thanks, Roman. == Abstract == Zeppelin is a collaborative data analytics and visualization tool for distributed, general-purpose data processing systems such as Apache Spark, Apache Flink, etc. == Proposal == Zeppelin is a modern web-based tool for the data scientists to collaborate over large-scale data exploration and visualization projects. It is a notebook style interpreter that enable collaborative analysis sessions sharing between users. Zeppelin is independent of the execution framework itself. Current version runs on top of Apache Spark but it has pluggable interpreter APIs to support other data processing systems. More execution frameworks could be added at a later date i.e Apache Flink, Crunch as well as SQL-like backends such as Hive, Tajo, MRQL. We have a strong preference for the project to be called Zeppelin. In case that may not be feasible, alternative names could be: “Mir”, “Yuga” or “Sora”. == Background == Large scale data analysis workflow includes multiple steps like data acquisition, pre-processing, visualization, etc and may include inter-operation of multiple different tools and technologies. With the widespread of the open source general-purpose data processing systems like Spark there is a lack of open source, modern user-friendly tools that combine strengths of interpreted language for data analysis with new in-browser visualization libraries and collaborative capabilities. Zeppelin initially started as a GUI tool for diverse set of SQL-over-Hadoop systems like Hive, Presto, Shark, etc. It was open source since its inception in Sep 2013. Later, it became clear that there was a need for a greater web-based tool for data scientists to collaborate on data exploration over the large-scale projects, not limited to SQL. So Zeppelin integrated full support of Apache Spark while adding a collaborative environment with the ability to run and share interpreter sessions in-browser == Rationale == There are no open source alternatives for a collaborative notebook-based interpreter with support of multiple distributed data processing systems. As a number of companies adopting and contributing back to Zeppelin is growing, we think that having a long-term home at Apache foundation would be a great fit for the project ensuring that processes and procedures are in place to keep project and community “healthy” and free of any commercial, political or legal faults. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. This includes moving all infrastructure that we currently maintain, such as: a website, a mailing list, an issues tracker and a Jenkins CI, as mentioned in “Required Resources” section of current proposal. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. To increase adoption the major goal for the project would be to provide integration with as much projects from Apache data ecosystem as possible, including new interpreters for Apache Hive, Apache Drill and adding Zeppelin distribution to Apache Bigtop. On the community building side the main goal is to attract a diverse set of contributors by promoting Zeppelin to wide variety of engineers, starting a Zeppelin user groups around the globe and by engaging with other existing Apache projects communities online. == Current Status == Currently, Zeppelin has 4 released versions and is used in production at a number of companies across the globe mentioned in Affiliation section. Current implementation status is pre-release with public API not being finalized yet. Current main and default backend processing engine is Apache Spark with consistent support of SparkSQL. Zeppelin is distributed as a binary package which includes an embedded webserver, application itself, a set of libraries and startup/shutdown scripts. No platform-specific installation packages are provided yet but it is something we are looking to provide as part of Apache Bigtop integration. Project codebase is currently hosted at github.com, which will form the basis of the Apache git repository. === Meritocracy === Zeppelin is an open source project that already leverages meritocracy principles. It was started by a handfull of people and now it has
Re: Votes for git repos - commit id vs tag
Tags are at best a convenience, and nothing else. But so are commit id, since in the long-term, GIT may not prevail and the commit id is in effect an internal artifact of Git itself, not the concept of version control systems. Compare how commit numbers from Subversion are imported to Git repositories, or not... But tags are imported, if the ttb structure in subversion is used. Releases are the tarball(s) prepared by the release manager, not a pointer into the source control system. It is the tarball that is released to the public, not the commit id, and it is the tarball that must be vetted by the community, not their local copy of the particular commit ID. So, to make this clear to the community, I would discourage to publish the commit ID in the vote request, and only provide the URL link to the tarball(s). It would be totally possible for the release manager (and build system) to include the commit id into the tarball as additional information, for instance a footer in README. Cheers Niclas On Sat, Dec 20, 2014 at 6:15 AM, David Nalley da...@gnsa.us wrote: I recently found this confusing with the first parquet-format release. I thought that both commit id and tag were optional, given that the actual release candidate is a signed tarball (actually, the necessary source code to build the project [1]). Commit id is not optional. Tag is. The release candidate is a signed tarball, but I should be able to take your source tree from the commit id, and get the exact same tarball by following your release process. (Note that this applies only to source tarballs - but those are the ones that matter). If I can't arrive at the same exact tarball there's something amiss with the release or the process. We can't necessarily recover the commit id from the tarball because the parent information is lost [2], so requiring the commit id is only useful for convenience and validating that a new tarball from git at the commit id matches the vote tarball. Is this validation done? Is it a requirement? If it isn't a requirement for a commit to match what is being voted on, then does it matter whether we use a tag for convenience or a commit id? We could also accept signed tags, though I don't know if there are issues that would prevent it. rb [1]: https://www.apache.org/dev/release-publishing.html#valid [2]: Unless using `git archive`: http://git-scm.com/docs/git-archive -- Ryan Blue - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
