+1
On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org> wrote: > Incubator is the Apache recommended way to handle this. We could be > the sponsor, with the intent that once Curator graduates from the > incubator we would accept it > http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor > anyone could join the curator effort, including existing ZK > committers/contributors. > > if curator felt it should be a tlp (at time of graduation) I think > that would be fine too. > > I would be happy to Champion/Mentor this effort. > > Patrick > > On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: >> Ben, >> >> I think that you are right on target with this. We need to have a wider >> community of developers in order to have the bandwidth to handle recipes >> and the recipes really do need separate release cycles. Independent >> releases should be not much of an issue given how compatible ZK versions >> tend to be. >> >> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <br...@apache.org> wrote: >> >>> 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 >>> > >>>
