i also agreed that it would be great to build a community around curator especially if it could pull in other zk recipes. i've felt for a while that the core developers don't have the bandwidth to really keep track of recipe development and recipes are a very important aspect of zk. so, having a self sustaining community of developers focused on that would be awesome. being able to have a separate release cycle is also important i think. (i may be reading too much into the proposal though :)
ben On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <f...@yahoo-inc.com> wrote: > I suppose you're just trying to sense if others think that it would be a > good idea to have it as a subproject. If so, I'm in favor of putting a > proposal together, +1. > > -Flavio > > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote: > >> Somehow this got off list, Jordan and I just noticed, summary so far: >> >> ---------- Forwarded message ---------- >> From: Patrick Hunt <ph...@apache.org> >> Date: Fri, Dec 2, 2011 at 9:56 AM >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for >> recipes >> To: Jordan Zimmerman <jzimmer...@netflix.com> >> >> >> Did you mean to reply just to me? I think this is a great idea btw, >> just need to work out the mechanics of getting it integrated and get >> the others on board. Would it help to talk f2f? >> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <jzimmer...@netflix.com> >> wrote: >>> >>> From talking to folks here (and my own feeling), I'd like to have Curator >>> get as wide use as possible. Some sort of sanction from the ZooKeeper >>> team >>> would do that. I don't see a lot of downside to getting a community >>> around >>> it either. Sure, it's nice to be the only guy I need to please, but the >>> benefits of a community outweigh that. >>> >>> I think the beauty of folding it in to ZooKeeper is that the structure is >>> already there: Jira, website, etc. I (and probably one other from >>> Netflix) >>> could take on the role of managing the Curator portion so that it doesn't >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly, >>> it >>> sounds like fun (famous last words). >>> >>> -Jordan >>> >>> On 12/1/11 5:36 PM, "Patrick Hunt" <ph...@apache.org> wrote: >>> >>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman >>>> <jzimmer...@netflix.com> >>>> wrote: >>>>> >>>>> The feeling here is that it would be nice to push Curator into ZK. >>>>> However, we'd still like to contribute to it. If you don't want >>>>> separate >>>>> contributor lists, I could be a ZK contributor but explicitly only work >>>>> on >>>>> Curator. Of course, we're open to your suggestions on this as well. >>>> >>>> >>>> Don't get me wrong, I don't mind having one list of >>>> contributors/committers for ZK/Curator, I'm personally fine with >>>> having one. If you notice in my original proposal I lean towards that >>>> direction (single set of committers with multiple artifacts) >>>> >>>> I see a benefit to having something like Curator available to users, >>>> open sourcing it on GH accomplishes this. Bringing something to Apache >>>> means building a community around it though, not just making the code >>>> open source. This is analogous to when ZK itself was on sourceforge, >>>> eventually moving to Apache. >>>> >>>> Here's the issue: building community adds overhead, which you might >>>> not be willing to sign up for. I'm not sure we (zk community) can take >>>> on this additional cost alone. Hence my question -- I _wouldn't_ want >>>> to you leave, that's the point. We'd need some set of core "Curator >>>> contributors" who would continue to work on Curator, answer questions, >>>> shepherd new contributor/committers/etc... If that doesn't happen the >>>> code will get imported, see some use, but never really reach it's full >>>> potential. >>>> >>>> Hope that helps. LMK. >>>> >>>> Patrick >>>> >>>>> >>>>> On 12/1/11 2:01 PM, "Patrick Hunt" <ph...@apache.org> wrote: >>>>> >>>>>> On Thu, Dec 1, 2011 at 1:26 PM, Jordan Zimmerman >>>>>> <jzimmer...@netflix.com> >>>>>> wrote: >>>>>>> >>>>>>> I've spoken about this with the appropriate folks here at Netflix and >>>>>>> we're interested in pursuing this. What are the next steps? >>>>>> >>>>>> >>>>>> Hi Jordan, what are your intentions. Do you want to build a community >>>>>> around "Apache Curator" or are you just looking to push the source >>>>>> into ZK and move on to other things? >>>>>> >>>>>> Patrick >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/30/11 5:42 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote: >>>>>>> >>>>>>>> Separator committer lists are generally frowned on by Apache (ref >>>>>>>> Lucene/Solr and also Mahout). >>>>>>>> >>>>>>>> They also are essentially unnecessary. It isn't that big a deal to >>>>>>>> have a >>>>>>>> single committer list and depend on reversion to enforce community >>>>>>>> standards. Core ZK is review-then-commit and should continue to be. >>>>>>>> Add-on modules that are relatively independent of the core can quite >>>>>>>> reasonably be commit-then-review or whatever level of care is >>>>>>>> implied >>>>>>>> by >>>>>>>> module's content. The review can include a determination of who >>>>>>>> should >>>>>>>> actually do the commit. >>>>>>>> >>>>>>>> Moreover, projects can easily have more than one artifact. Mahout >>>>>>>> has >>>>>>>> three independent artifacts (mahout-math, mahout-collections and the >>>>>>>> core >>>>>>>> stuff with examples and integration code). That works well. There >>>>>>>> are >>>>>>>> different sets of committers who are typically the ones who work on >>>>>>>> different components. The overall level of diligence required in >>>>>>>> Mahout >>>>>>>> is >>>>>>>> much lower than for Zookeeper as you might expect, but the principle >>>>>>>> that >>>>>>>> multiple artifacts are fine is still the same. Likewise, the idea >>>>>>>> of >>>>>>>> committers with specialized expertise also applies here. >>>>>>>> >>>>>>>> There is a tradition in Zookeeper of having a very high bar for >>>>>>>> committership, but experience in some other projects indicates that >>>>>>>> this >>>>>>>> doesn't actually help quality or security all that much and it can >>>>>>>> be >>>>>>>> argued to decrease community involvement a bit. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 30, 2011 at 5:11 PM, Patrick Hunt <ph...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Curator has been getting a lot of interest and was just officially >>>>>>>>> announced by Netflix: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://techblog.netflix.com/2011/11/introducing-curator-netflix-zooke >>>>>>>>> ep >>>>>>>>> er >>>>>>>>> .html >>>>>>>>> >>>>>>>>> I chatted briefly with @adrianco @chad_walters @randgalt (Jordan >>>>>>>>> Zimmerman) on twitter and the idea of moving Curator into >>>>>>>>> Apache/ZooKeeper came up: >>>>>>>>> https://twitter.com/#!/search/phunt%20curator >>>>>>>>> >>>>>>>>> I wanted to restart this thread as a way of discussing this idea in >>>>>>>>> more depth, and to gauge the interest of both communities. I >>>>>>>>> personally think this would be a great thing: both for users and >>>>>>>>> for >>>>>>>>> the development community itself. Thoughts? >>>>>>>>> >>>>>>>>> Re the mechanics. See my original post below. Seems to me we (ZK >>>>>>>>> PMC) >>>>>>>>> could sponsor Curator as an incubator project with the intent to >>>>>>>>> bring >>>>>>>>> it to ZK as either a subproject (it's own committer list) or as a >>>>>>>>> separate release artifact of the ZK TLP itself. Or just shortcut >>>>>>>>> the >>>>>>>>> incubator process altogether. My preference would be to go >>>>>>>>> incubator >>>>>>>>> first. At some point we would deprecate the existing ZK recipes >>>>>>>>> (ala >>>>>>>>> Curator had suitable replacements). >>>>>>>>> >>>>>>>>> Patrick >>>>>>>>> >>>>>>>>> On Fri, Jul 22, 2011 at 10:59 AM, Benjamin Reed <br...@apache.org> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> while i agree with the sentiment of not fragmenting the zookeeper >>>>>>>>>> community and recipe committers also moving into core >>>>>>>>> >>>>>>>>> development, i >>>>>>>>>> >>>>>>>>>> also think it would be good if a strong community of developers >>>>>>>>> >>>>>>>>> grew >>>>>>>>>> >>>>>>>>>> up around zookeeper recipes. to do that they need a sense of >>>>>>>>> >>>>>>>>> identity, >>>>>>>>>> >>>>>>>>>> and i'm not sure if they can get that with this proposal. >>>>>>>>>> >>>>>>>>>> on the other hand the proposal does address all of the other >>>>>>>>> >>>>>>>>> issues >>>>>>>>> i >>>>>>>>>> >>>>>>>>>> have with recipe maintenance. the key is to grow a committer base. >>>>>>>>>> >>>>>>>>>> ben >>>>>>>>>> >>>>>>>>>> On Wed, Jul 13, 2011 at 11:04 AM, Patrick Hunt <ph...@apache.org> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> During the recent developer meetup we discussed how to more >>>>>>>>>>> effectively grow the recipes. >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/June2011Develop >>>>>>>>> er >>>>>>>>> Me >>>>>>>>> eting >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The concerns seemed to be around managing changes, community >>>>>>>>> >>>>>>>>> growth, >>>>>>>>>>> >>>>>>>>>>> and releases. We discussed a number of approaches: >>>>>>>>>>> * move recipes into apache-extras >>>>>>>>>>> * or github >>>>>>>>>>> * or incubator >>>>>>>>>>> * or sub-project >>>>>>>>>>> >>>>>>>>>>> each of these has it's good and bad points. One alternative that >>>>>>>>> >>>>>>>>> I >>>>>>>>> put >>>>>>>>>>> >>>>>>>>>>> forth was to create a separate release artifact for recipes as >>>>>>>>> >>>>>>>>> part >>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>> the ZooKeeper project itself. What would this look like? >>>>>>>>>>> >>>>>>>>>>> * zookeeper/trunk/src/recipes would move to >>>>>>>>>>> zookeeper/recipes/{trunk,branches,tags,...} >>>>>>>>>>> * there would be distinct/separate releases of zookeeper and >>>>>>>>>>> zookeeper-recipes artifacts >>>>>>>>>>> ** these releases would not necessarily be synchronized, although >>>>>>>>> >>>>>>>>> we'd >>>>>>>>>>> >>>>>>>>>>> want to ensure that particular versions of each release work >>>>>>>>> >>>>>>>>> together >>>>>>>>>>> >>>>>>>>>>> ** these releases would go through our standard release process - >>>>>>>>> >>>>>>>>> ie >>>>>>>>>>> >>>>>>>>>>> creation of release candidate by a committer and approval by the >>>>>>>>> >>>>>>>>> PMC >>>>>>>>>>> >>>>>>>>>>> ** recipes would no longer be included in "zookeeper" (core) >>>>>>>>> >>>>>>>>> releases >>>>>>>>>>> >>>>>>>>>>> * continue to use the ZOOKEEPER jira, with "recipes" component >>>>>>>>>>> * space in the web and wiki sites for recipes specific pages >>>>>>>>>>> * recipes continue to use the std zookeeper mailing lists >>>>>>>>>>> * commits to recipes would continue to use our regular commit >>>>>>>>> >>>>>>>>> process >>>>>>>>>>> >>>>>>>>>>> (jira, rtc, etc...) >>>>>>>>>>> * we would accept new "ZooKeeper committers" with the intent that >>>>>>>>> >>>>>>>>> they >>>>>>>>>>> >>>>>>>>>>> focus on their area of expertise, whether this be core (zookeeper >>>>>>>>>>> trunk) or recipes. >>>>>>>>>>> >>>>>>>>>>> This last item is the more interesting I think, the other issues >>>>>>>>> >>>>>>>>> are >>>>>>>>>>> >>>>>>>>>>> all pretty straightforward. Although moving to sub (or out >>>>>>>>> >>>>>>>>> entirely) >>>>>>>>>>> >>>>>>>>>>> would allow us to have a separate commit list it would fragment >>>>>>>>> >>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> ZooKeeper community. I also believe that over time committers to >>>>>>>>>>> recipes would more likely get experience with core and start >>>>>>>>>>> contributing there as well. The only issue really, if you want to >>>>>>>>> >>>>>>>>> call >>>>>>>>>>> >>>>>>>>>>> it that, is that we'd have committers with "guardrails" implied. >>>>>>>>> >>>>>>>>> ie >>>>>>>>>>> >>>>>>>>>>> someone with more expertise in recipes than core. However there >>>>>>>>> >>>>>>>>> are >>>>>>>>>>> >>>>>>>>>>> many other Apache projects that take this approach, and do it >>>>>>>>>>> successfully. Regardless RTC allows for review both before and >>>>>>>>> >>>>>>>>> after >>>>>>>>> a >>>>>>>>>>> >>>>>>>>>>> change is committed. >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Patrick >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > > flavio > junqueira > > research scientist > > f...@yahoo-inc.com > direct +34 93-183-8828 > > avinguda diagonal 177, 8th floor, barcelona, 08018, es > phone (408) 349 3300 fax (408) 349 3301 >
