Re: Retirement decision making
On Fri, Nov 30, 2012 at 4:27 AM, Ross Gardler rgard...@opendirective.comwrote: On 30 November 2012 00:52, Benson Margulies bimargul...@gmail.com wrote: Hard cases make bad law. The rough parameters of the recent 'small graduates' was that they had around 5 initial PMC members, and some detectable evidence that all of them were in the reasonably regular habit of contributing code, let alone voting for releases. If we insist on testing the absolute lower limit of viability, we're may bump into the absurd. +1 (where reasonably regular habit of contributing code should be reasonably regular habit of contributing in some way - that is only being active in PMC duties would be fine, need not be active committer, as long as it is responsible activity (i.e. voting from an informed position) Yes. Particularly for more mature code-bases, I'd put a lot of weight on whether people are around to answer user questions -- quite possibly, explaining the system helps attract new users more than tinkering with it does. --Ari -- Ari Rabkin asrab...@gmail.com Princeton Computer Science Department
Re: What constitute a successful project?
Hi all. I've been following this discussion for a while, collecting my thoughts. I think I've actually come around to Eric Y's feeling here: the project is closer to graduation than to retirement. Chukwa, as a community, has a few distinctive features. The system is specialized big-data infrastructure, and it's mature enough to be used in production. That has a few consequences: 1) It's not going to have a high rate of change; it's more maintenance than new development. 2) It's not going to be an easy project for hobbyists to contribute to, since testing requires access to big infrastructure for extended periods. 3) There is a small set of highly motivated users, who are really using the code, and therefore have strong incentives to keep the project healthy. My sense is that the community is needed more for support and maintenance than for major rewriting. And my sense is that the community is able to do that. As Eric points out, there have been a bunch of patches from people who weren't original core developers. As part of the podling growth strategy: I think it would be good to cut some releases. Let's see if the community has enough energy to test and vote on release candidates. Let's see how well people understand the Apache release process. I'd like, if possible, for somebody new to be the release manager. Eric and I have both cut releases before and I would take it as a strong good sign if somebody new stepped up. If the community has enough energy and activity to respond to user queries and to do regular releases,I would think it was a plausible graduation candidate. --Ari On Wed, Nov 28, 2012 at 2:12 AM, Eric Yang eric...@gmail.com wrote: Continue the retirement vote, and see if it passes in IPMC. If it does, I will gladly setup shop in github. If it doesn't, Chukwa community should prepare for Chukwa 0.6.0 release, and start voting on Chukwa 0.6.0 release, and follow by vote for graduation. Content in Chukwa trunk contains a number of good features and fixes generated by the community. I really appreciate the support by Incubator community to make this possible. Does this sound like a plan? -- Ari Rabkin asrab...@gmail.com Princeton Computer Science Department - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
I agree with Jerome and Chris. I also would opt for plan #2: incubation with TLP names. --Ari On Fri, Jun 25, 2010 at 1:40 PM, Chris Douglas cdoug...@apache.org wrote: I agree with the analysis from Jerome and Greg. All three of Chukwa's current committers are its original contributors. An important- and often difficult- part of Apache community is growing and managing the developers working on the project. Some experience adding people in the Incubator would be valuable to members (both old and new) and would result in a quorum less volatile than three. Given that the team is small and renaming will be expensive and tedious, that requirement seems purely punitive. No positive reason for it has been raised. So I am +1 (non-binding) for option (2), incubation with TLP class naming, but incubation release naming. -- Ari Rabkin asrab...@gmail.com UC Berkeley Computer Science Department - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
Hrm. I think my preference is for 1 or 2. Given that Chukwa already has a fair bit of infrastructure up and running, seems like fewer renames is better and would reduce user confusion. --Ari On Thu, Jun 24, 2010 at 3:21 PM, William A. Rowe Jr. wr...@apache.org wrote: On 6/23/2010 8:12 AM, Bernd Fondermann wrote: On Wed, Jun 23, 2010 at 14:45, ant elder ant.el...@gmail.com wrote: IMHO we should insist on using the incubator naming for the Chukwa website/svn/MLs because I think Chukwa should just go directly to a TLP and if they have to use the incubator naming it may help them decide that the direct to TLP route really is better ;-) I see you blinking here, so I guess this is not just for putting up a strawman ;-) Well folks, it's a fun debate and all, but it isn't helping bring this vote to a conclusion :) Is anyone in agreement with ant? Otherwise we should just move ahead and can hold a separate vote on allowing tlp resource creation at this time. If the proposers want (Eric?) a three choice vote, 1. recommend TLP with guides to help the initial pmc, 2. accept incubating with tlp resource naming, but -incubating release naming, or 3. accept incubating requiring all incubator naming conventions, that might help the incubator simplify this decision. At this point, I personally guess that 1. might be the most sensible in terms of resource creation and management; it would simply require the group to vote for an initial chair/VP. If they are unsure of their group yet, perhaps one of the other mentors would offer to serve as their chair for the first six months, if they rather would do that? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ari Rabkin asrab...@gmail.com UC Berkeley Computer Science Department - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
