Re: Running an experiment with pTLP
And another +1 from myself, as a Director voting on that proposal/resolution. On Mon, Dec 29, 2014 at 11:01 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: The structure would still be there - my hypothesis is that the mentors + the board will both uplift structure, and help to identify (more quickly) situations like no report, lack of mentors, etc. Anyhoo this experiment (the 2 that have volunteered so far) would have my board VOTE - prepare a resolution and send it to the board agenda and let's see what happens.. Cheers, 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: Marvin Humphrey mar...@rectangular.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Monday, December 29, 2014 at 8:36 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Mon, Dec 29, 2014 at 3:14 PM, Roman Shaposhnik r...@apache.org wrote: Might be seen as grossly unfair by the project that remain in the old regime There's no structure like no structure! Marvin Humphrey - 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: Running an experiment with pTLP
On Tue, Dec 30, 2014 at 12:14 AM, Roman Shaposhnik r...@apache.org wrote: ...Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board I don't have a clear idea of what the suggested experiment means, it looks like that info is scattered around several threads that I have lost track of. A brief definition on a wiki page would help make sure everybody has the same view of what you are suggesting. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Running an experiment with pTLP
On 12/30/2014 05:38 AM, Bertrand Delacretaz wrote: On Tue, Dec 30, 2014 at 12:14 AM, Roman Shaposhnik r...@apache.org wrote: ...Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board I don't have a clear idea of what the suggested experiment means, it looks like that info is scattered around several threads that I have lost track of. A brief definition on a wiki page would help make sure everybody has the same view of what you are suggesting. Yep, I was going to ask for that also. While I know (I think) what *I* mean, there's enough contradiction in the thread that it would be good to have a one-page document explaining what is meant. So, yeah, Roman, I'd be interested in participating. I've already thrown my hat in for Tinkerpop mentor, if they'll have me, but I'd be willing to work with you on Zeppelin, also. --Rich -- 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: Running an experiment with pTLP
On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: The structure would still be there - my hypothesis is that the mentors + the board will both uplift structure, and help to identify (more quickly) situations like no report, lack of mentors, etc. I am skeptical that Apache policies will be applied evenly under such a regime. For example, release candidates routinely make it to the full IPMC vote with binary dependencies embedded in source. Regardless of intent, removing final review by the wider IPMC will have the effect of liberalizing the policy on bundled binary dependencies for those pTLPs who do not count any sticklers among their Mentors. Rather than change effective release policy for a minority through administrative laxity, the Board should grapple with the full implications of changing it explicitly for everyone. (Yes, that will turn a huge, gory fight considering liability, etc.) Atomizing the IPMC will also yield inconsistency in other areas where there is either confusion or honest disagreement among the Membership as to what our policies are, such as provenance documentation requirements for contributions arriving via Github, or whether PMC chairs are special. Nevertheless, +1 to move forward with the pTLP experiment (whatever that means). Odds are that any given pTLP will work out OK, especially if they land one of our better Mentors. But when one messes up, maybe we'll get a clarifying post-mortem with the Board in the hot seat and the Incubator unavailable as a convenient scapegoat. No matter how much progress the Incubator makes, people will continue to hate on it because it's a teacher and front-line enforcer of contentious and frustratingly complex Foundation policies. I'm not sure that's a solvable problem, because it seems that The Apache Way inherently produces sprawling, incoherent policy and policy documentation. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Running an experiment with pTLP
Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new board members that represent their views and ethos (including themselves as new board members) 3. Having those board members be part of checks and bounds to *care* and review these projects part of our foundation Or some subset of the above. My point being - IPMC or not - the things you cite below as important will still exist, since this foundation and its people will, hopefully for the next 50+ years. Cheers, 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: Marvin Humphrey mar...@rectangular.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, December 30, 2014 at 8:03 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: The structure would still be there - my hypothesis is that the mentors + the board will both uplift structure, and help to identify (more quickly) situations like no report, lack of mentors, etc. I am skeptical that Apache policies will be applied evenly under such a regime. For example, release candidates routinely make it to the full IPMC vote with binary dependencies embedded in source. Regardless of intent, removing final review by the wider IPMC will have the effect of liberalizing the policy on bundled binary dependencies for those pTLPs who do not count any sticklers among their Mentors. Rather than change effective release policy for a minority through administrative laxity, the Board should grapple with the full implications of changing it explicitly for everyone. (Yes, that will turn a huge, gory fight considering liability, etc.) Atomizing the IPMC will also yield inconsistency in other areas where there is either confusion or honest disagreement among the Membership as to what our policies are, such as provenance documentation requirements for contributions arriving via Github, or whether PMC chairs are special. Nevertheless, +1 to move forward with the pTLP experiment (whatever that means). Odds are that any given pTLP will work out OK, especially if they land one of our better Mentors. But when one messes up, maybe we'll get a clarifying post-mortem with the Board in the hot seat and the Incubator unavailable as a convenient scapegoat. No matter how much progress the Incubator makes, people will continue to hate on it because it's a teacher and front-line enforcer of contentious and frustratingly complex Foundation policies. I'm not sure that's a solvable problem, because it seems that The Apache Way inherently produces sprawling
Re: Running an experiment with pTLP
I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it. 2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new board members that represent their views and ethos (including themselves as new board members) 3. Having those board members be part of checks and bounds to *care* and review these projects part of our foundation Or some subset of the above. My point being - IPMC or not - the things you cite below as important will still exist, since this foundation and its people will, hopefully for the next 50+ years. Cheers, 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: Marvin Humphrey mar...@rectangular.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, December 30, 2014 at 8:03 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: The structure would still be there - my hypothesis is that the mentors + the board will both uplift structure, and help to identify (more quickly) situations like no report, lack of mentors, etc. I am skeptical that Apache policies will be applied evenly under such a regime. For example, release candidates routinely make it to the full IPMC vote with binary dependencies embedded in source. Regardless of intent, removing final review by the wider IPMC will have the effect of liberalizing the policy on bundled binary dependencies for those pTLPs who do not count any sticklers among their Mentors. Rather than change effective release policy for a minority through administrative laxity, the Board should grapple with the full implications of changing it explicitly for everyone. (Yes, that will turn a huge, gory fight considering liability, etc.) Atomizing the IPMC will also yield inconsistency in other areas where there is either confusion or honest disagreement among the Membership as to what our policies are, such as provenance documentation requirements for contributions arriving via Github, or whether PMC chairs are special. Nevertheless, +1 to move forward with the pTLP experiment (whatever that means). Odds are that any given pTLP will work
Re: Running an experiment with pTLP
Thanks Benson - I would suggest using the Incubator wiki if you need one (but the point about there not being a Board wiki - interesting, would be nice to have one). At the end of the day the resolution would look like a typical board resolution after Incubator graduation e.g., “Create Apache X”, so it would be summarized as you mention in point #3 below. Cheers and good luck. Cheers, 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: Tuesday, December 30, 2014 at 11:12 AM To: general@incubator apache. org general@incubator.apache.org Subject: Re: Running an experiment with pTLP I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it. 2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new board members that represent their views and ethos (including themselves as new board members) 3. Having those board members be part of checks and bounds to *care* and review these projects part of our foundation Or some subset of the above. My point being - IPMC or not - the things you cite below as important will still exist, since this foundation and its people will, hopefully for the next 50+ years. Cheers, 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: Marvin Humphrey mar...@rectangular.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, December 30, 2014 at 8:03 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: The structure would still
Re: Running an experiment with pTLP
On Tue, Dec 30, 2014 at 2:25 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Thanks Benson - I would suggest using the Incubator wiki if you need one (but the point about there not being a Board wiki - interesting, would be nice to have one). At the end of the day the resolution would look like a typical board resolution after Incubator graduation e.g., “Create Apache X”, so it would be summarized as you mention in point #3 below. Chris, I agree that the simplest model of (p)TLP hasn't much of a (p): it would be a normal resolution, and we'll be off to the races. I plan, if the Nifi group is game, to send mail to the board offering that option, and then back off to a more complex proposal if the board wants more (p) -- like PR restrictions, or some sort of policy on how the initial podling group gets incorporated into the PMC. --benson Cheers and good luck. Cheers, 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: Tuesday, December 30, 2014 at 11:12 AM To: general@incubator apache. org general@incubator.apache.org Subject: Re: Running an experiment with pTLP I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it. 2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new board members that represent their views and ethos (including themselves as new board members) 3. Having those board members be part of checks and bounds to *care* and review these projects part of our foundation Or some subset of the above. My point being - IPMC or not - the things you cite below as important will still exist, since this foundation and its people will, hopefully for the next 50+ years. Cheers, 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
Re: Running an experiment with pTLP
+1 thanks Benson, totally agree. ++ 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: Tuesday, December 30, 2014 at 11:50 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Tue, Dec 30, 2014 at 2:25 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Thanks Benson - I would suggest using the Incubator wiki if you need one (but the point about there not being a Board wiki - interesting, would be nice to have one). At the end of the day the resolution would look like a typical board resolution after Incubator graduation e.g., “Create Apache X”, so it would be summarized as you mention in point #3 below. Chris, I agree that the simplest model of (p)TLP hasn't much of a (p): it would be a normal resolution, and we'll be off to the races. I plan, if the Nifi group is game, to send mail to the board offering that option, and then back off to a more complex proposal if the board wants more (p) -- like PR restrictions, or some sort of policy on how the initial podling group gets incorporated into the PMC. --benson Cheers and good luck. Cheers, 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: Tuesday, December 30, 2014 at 11:12 AM To: general@incubator apache. org general@incubator.apache.org Subject: Re: Running an experiment with pTLP I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it. 2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new
RE: Running an experiment with pTLP
I don't want to fan flames or point fingers, but at the same time I need to say this. Please read it as being intended to be constructive... This whole pTLP thing is not new. We conducted an experiment like the one proposed below some time ago. The outcome of that experiment was supposed to be a proposal to the board from the IPMC about how to create and manage pTLP's at scale. At the start of that experiment I (as Champion) spent a long time collating the various views on the proposal. I provided this as summary email at the start of the podlings life. I believed this was a really good start for whoever was going to turn it into a full proposal. It might be useful here also. NOTE - I'm not naming the podling or mentors to minimize the chance of people feeling that I'm finger pointing in the following paragraphs - there are plenty of folks around who will have that email in their archives. Unfortunately the experiment did not go well. No proposal was received and, more importantly, as champion (but not a mentor) for the project in question I was asked to step in on three separate occasion. This was despite, or perhaps because of, there being some very old hands in the podling committer list. My point today is just the same as it was when this was discussed the first time around. This proposal simply moves the problem (projects lacking in appropriate mentorship) to someone else's doorstep. It does not solve the problem itself. To be clear, I have no intention of voting against the proposed experiment. I do want to see the experiment take place (just as I did the first time around) but we need to ensure we are not simply moving the oversight role - that is not the problem that needs solving. Ross -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, December 30, 2014 2:39 AM To: Incubator General Subject: Re: Running an experiment with pTLP On Tue, Dec 30, 2014 at 12:14 AM, Roman Shaposhnik r...@apache.org wrote: ...Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board I don't have a clear idea of what the suggested experiment means, it looks like that info is scattered around several threads that I have lost track of. A brief definition on a wiki page would help make sure everybody has the same view of what you are suggesting. -Bertrand - 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: Running an experiment with pTLP
+1 to everything Ross said below and I monitored that experiment as well but was unaware of the 3 incidents, etc. As for pTLPs and shifting mentorship, etc., I trust Ross’s judgement but think we need more data on this across a number of projects before we know definitively what’s the cause of what, etc. Cheers, 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: Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, December 30, 2014 at 12:07 PM To: general@incubator.apache.org general@incubator.apache.org Subject: RE: Running an experiment with pTLP I don't want to fan flames or point fingers, but at the same time I need to say this. Please read it as being intended to be constructive... This whole pTLP thing is not new. We conducted an experiment like the one proposed below some time ago. The outcome of that experiment was supposed to be a proposal to the board from the IPMC about how to create and manage pTLP's at scale. At the start of that experiment I (as Champion) spent a long time collating the various views on the proposal. I provided this as summary email at the start of the podlings life. I believed this was a really good start for whoever was going to turn it into a full proposal. It might be useful here also. NOTE - I'm not naming the podling or mentors to minimize the chance of people feeling that I'm finger pointing in the following paragraphs - there are plenty of folks around who will have that email in their archives. Unfortunately the experiment did not go well. No proposal was received and, more importantly, as champion (but not a mentor) for the project in question I was asked to step in on three separate occasion. This was despite, or perhaps because of, there being some very old hands in the podling committer list. My point today is just the same as it was when this was discussed the first time around. This proposal simply moves the problem (projects lacking in appropriate mentorship) to someone else's doorstep. It does not solve the problem itself. To be clear, I have no intention of voting against the proposed experiment. I do want to see the experiment take place (just as I did the first time around) but we need to ensure we are not simply moving the oversight role - that is not the problem that needs solving. Ross -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, December 30, 2014 2:39 AM To: Incubator General Subject: Re: Running an experiment with pTLP On Tue, Dec 30, 2014 at 12:14 AM, Roman Shaposhnik r...@apache.org wrote: ...Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board I don't have a clear idea of what the suggested experiment means, it looks like that info is scattered around several threads that I have lost track of. A brief definition on a wiki page would help make sure everybody has the same view of what you are suggesting. -Bertrand - 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: Running an experiment with pTLP
On Tue, Dec 30, 2014 at 4:17 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: +1 to everything Ross said below and I monitored that experiment as well but was unaware of the 3 incidents, etc. As for pTLPs and shifting mentorship, etc., I trust Ross’s judgement but think we need more data on this across a number of projects before we know definitively what’s the cause of what, etc. If I was 'in the room' for the last time around, I seem to have forgotten. If I volunteered to write something, gosh I'm sorry and please do call me out here. Meanwhile: I think that there's some complexity here: At one extreme, consider 5 members with a demonstrable track record on IP issues and supervision who want to launch a new project (for example, a proposed VP who has been a success as a project VP on some other project(s)). Regardless of anything else, I suspect that they could go to the board, propose to launch a TLP directly, and have a pretty good chance of the board approving it. That's not really what pTLP is about, though. pTLP says, 'here we have some people who are willing to serve as the supervision structure of a new TLP but expect to fade away; they aren't necessarily planning to be write any code. They are members, but, hmm, members come in all sorts of different levels of experience with the issues faced by new projects. With all respect to ChrisM on the subject of letting the IPMC itself fade away, I read Ross' statement as pointing out that this situation seems to need some work done that the board doesn't want to do for itself. The board might want, gee, some committee, to help vet proposals, and perhaps to help keep an eye on them once they are running. That's what I meant by wondering 'how much (p) does the board want?' (Aside, as the number of projects grows and grows, it seems to me that the board might need some help supervising all the regular projects.) This brings me back to my idea of a wiki page. If the board is looking for a 'pTLP' to be more self-governing than a 'podling' but still have the IPMC accept some sort of responsibility for it, we need to write down the boundaries as part of proposing to the board. If NiFi wants to try this, I'm still happy to write the 'simple' proposal to the board, and wait upon the board's desires. If the board members in this thread feel that writing the simple proposal is a waste of time and energy, I won't write it. None of this stops the IPMC itself from shifting policy, experimentally, to require Mentors to act as PPMC members. I think I've used my quote of characters for the year on this subject. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Running an experiment with pTLP
On Tue, Dec 30, 2014 at 2:01 PM, Benson Margulies bimargul...@gmail.com wrote: If NiFi wants to try this, I'm still happy to write the 'simple' proposal to the board, and wait upon the board's desires. If the board members in this thread feel that writing the simple proposal is a waste of time and energy, I won't write it. None of this stops the IPMC itself from shifting policy, experimentally, to require Mentors to act as PPMC members. I think I've used my quote of characters for the year on this subject. Speaking of which: given that there appears to be way more background on this plus the fact that my tenure as a Chair is almost up I think it would be best for more experienced folks to run with this. Sorry for the noise -- I just didn't realize the size of the can of worms I was opening with my naive suggestion. Benson, Chris, Rich, please don't mind me guys -- all the projects mentioned on this list would do great. With Zeppelin, at this point I'll be proceeding in the normal way to establish the poddling. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Running an experiment with pTLP
Please note the change of subject. On Mon, Dec 29, 2014 at 6:28 AM, Rich Bowen rbo...@rcbowen.com wrote: On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: 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. Having read more, and understood more, and consumed more coffee ... I wonder if we might implement this proposal with one incoming project, as a test, under close observation by the board and the IPMC? Might be seen as grossly unfair by the project that remain in the old regime (or, who knows, maybe also by the test project), but it might give us some deeper insight into whether this fixes anything? This is very much what others were suggesting on the thread as well. Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board. Perhaps between three of us (Chris, Rich and I) this is all we need. Thoughts? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Running an experiment with pTLP
On Mon, Dec 29, 2014 at 6:14 PM, Roman Shaposhnik r...@apache.org wrote: Please note the change of subject. On Mon, Dec 29, 2014 at 6:28 AM, Rich Bowen rbo...@rcbowen.com wrote: On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: 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. Having read more, and understood more, and consumed more coffee ... I wonder if we might implement this proposal with one incoming project, as a test, under close observation by the board and the IPMC? Might be seen as grossly unfair by the project that remain in the old regime (or, who knows, maybe also by the test project), but it might give us some deeper insight into whether this fixes anything? This is very much what others were suggesting on the thread as well. Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board. Perhaps between three of us (Chris, Rich and I) this is all we need. Thoughts? Any interest in a retroactive retrofit of NiFi? Thanks, Roman. - 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: Running an experiment with pTLP
Benson, Speaking from within the nifi ppmc I'd be happy to try this. Most of us in the nifi ppmc (excluding the mentors) are quite new to Apache so we're either perfect because we lack any of the biases or terrible because we're too ignorant to the good and bad. But I for one would be happy to help however we can. Thanks Joe On Mon, Dec 29, 2014 at 9:49 PM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Dec 29, 2014 at 6:14 PM, Roman Shaposhnik r...@apache.org wrote: Please note the change of subject. On Mon, Dec 29, 2014 at 6:28 AM, Rich Bowen rbo...@rcbowen.com wrote: On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: 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. Having read more, and understood more, and consumed more coffee ... I wonder if we might implement this proposal with one incoming project, as a test, under close observation by the board and the IPMC? Might be seen as grossly unfair by the project that remain in the old regime (or, who knows, maybe also by the test project), but it might give us some deeper insight into whether this fixes anything? This is very much what others were suggesting on the thread as well. Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board. Perhaps between three of us (Chris, Rich and I) this is all we need. Thoughts? Any interest in a retroactive retrofit of NiFi? Thanks, Roman. - 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: Running an experiment with pTLP
As part of the Zeppelin community I would be interested in giving this experiment a try. As Benson mention in prev. thread - having 'Mentors in the Project' (whether directly reporting to the board or not) sounds as a great way to learn how to run Apache project to me. -- Kind regards, Alexander On 30 Dec 2014, at 07:14, Roman Shaposhnik r...@apache.org wrote: Please note the change of subject. On Mon, Dec 29, 2014 at 6:28 AM, Rich Bowen rbo...@rcbowen.com wrote: On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: 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. Having read more, and understood more, and consumed more coffee ... I wonder if we might implement this proposal with one incoming project, as a test, under close observation by the board and the IPMC? Might be seen as grossly unfair by the project that remain in the old regime (or, who knows, maybe also by the test project), but it might give us some deeper insight into whether this fixes anything? This is very much what others were suggesting on the thread as well. Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board. Perhaps between three of us (Chris, Rich and I) this is all we need. Thoughts? Thanks, Roman. - 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: Running an experiment with pTLP
On Mon, Dec 29, 2014 at 3:14 PM, Roman Shaposhnik r...@apache.org wrote: Might be seen as grossly unfair by the project that remain in the old regime There's no structure like no structure! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Running an experiment with pTLP
The structure would still be there - my hypothesis is that the mentors + the board will both uplift structure, and help to identify (more quickly) situations like no report, lack of mentors, etc. Anyhoo this experiment (the 2 that have volunteered so far) would have my board VOTE - prepare a resolution and send it to the board agenda and let’s see what happens.. Cheers, 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: Marvin Humphrey mar...@rectangular.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Monday, December 29, 2014 at 8:36 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Mon, Dec 29, 2014 at 3:14 PM, Roman Shaposhnik r...@apache.org wrote: Might be seen as grossly unfair by the project that remain in the old regime There's no structure like no structure! Marvin Humphrey - 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
