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 >>>>>>> >> >>>>>>> >>>>> >>>> >>> >> >
