Return-Path: X-Original-To: apmail-curator-dev-archive@minotaur.apache.org Delivered-To: apmail-curator-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 02B8F18BA8 for ; Thu, 13 Aug 2015 18:07:22 +0000 (UTC) Received: (qmail 64442 invoked by uid 500); 13 Aug 2015 18:07:21 -0000 Delivered-To: apmail-curator-dev-archive@curator.apache.org Received: (qmail 64397 invoked by uid 500); 13 Aug 2015 18:07:21 -0000 Mailing-List: contact dev-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@curator.apache.org Delivered-To: mailing list dev@curator.apache.org Received: (qmail 64385 invoked by uid 99); 13 Aug 2015 18:07:21 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Aug 2015 18:07:21 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 32B1F771B for ; Thu, 13 Aug 2015 18:07:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.002 X-Spam-Level: **** X-Spam-Status: No, score=4.002 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, KAM_LAZY_DOMAIN_SECURITY=1, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 0izO4zqFRf18 for ; Thu, 13 Aug 2015 18:07:05 +0000 (UTC) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 77FD136E3F for ; Thu, 13 Aug 2015 15:39:33 +0000 (UTC) Received: by ykdt205 with SMTP id t205so44552466ykd.1 for ; Thu, 13 Aug 2015 08:39:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MTXEpU/hYsse6XUcuj8MyTIzfWK8iWaMv8lFLguxxSo=; b=X5jOWt5l8S3rhK4DA4GtmDgCEgtrGPFIBivoamOabxeONw2K7+kDVkK4kLq59K7kh5 bmawvMf+s+ceIzDiI/EWS/bObQhL7sZAI+AQCQfaCvrM2oTopTUcRWShaK4WbpPaiU8z 1gGPXNuI6cdz7xDSo58TWTw9bpUvswHG2WhSQc8z04gG7QEF44x3zNGD+uSY+8cwssTo YAR0o+gAa+Gp2uIjolXeEv5Xb7lOq1jP4v/N2aD1c+P6IcQTZH7IECW4WkzWdk+Ovl8P +xQPcqjvuLUKRdrN51bBnsRuQaJEHwb+Prpu+/Yek6Tgi8h4eLssLs6SQ3OEA0AveVRF 2l4A== X-Gm-Message-State: ALoCoQmg7LjnYIXqShlD2rxIMK5c5YIDeuQmG6Dl+x3EXV4MEweR7g1zLSRGzkrIQh8q5seN1L8/ X-Received: by 10.170.229.132 with SMTP id v126mr4600440ykf.36.1439480371763; Thu, 13 Aug 2015 08:39:31 -0700 (PDT) Received: from [10.162.76.234] ([201.227.226.146]) by smtp.gmail.com with ESMTPSA id l6sm2335838ywe.33.2015.08.13.08.39.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Aug 2015 08:39:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AA9099D1-7CEB-4B7E-A91B-95B10DBAD39A Mime-Version: 1.0 (1.0) Subject: Re: Next Steps From: Jordan Zimmerman X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Thu, 13 Aug 2015 10:39:27 -0500 Cc: "dev@curator.apache.org" Content-Transfer-Encoding: 7bit Message-Id: <6A96E809-8DC6-4BBF-B40D-B542B6E4D888@jordanzimmerman.com> References: To: Scott Blum --Apple-Mail-AA9099D1-7CEB-4B7E-A91B-95B10DBAD39A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cameron said he had trouble with 160. Any ideas? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jordan Zimmerman > On Aug 13, 2015, at 10:33 AM, Scott Blum wrote: >=20 > Any feedback on this? >=20 >> On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum wrote= : >> Okay, I think I'm done. I pushed my work up to my own github mirror, htt= ps://github.com/dragonsinth/curator >>=20 >> Please note the following branches I pushed: >>=20 >> CURATOR-160: re-history of the original CURATOR-160 branch work, simplifi= ed. >> CURATOR-215: re-history of the original CURATOR-215 branch work, simplifi= ed. >> CURATOR-3.0: a proposed new SHA for the new 3.0 branch, contains the othe= r two branches as well as several "loose" commits >> 3.0-rejects: a couple of final commits I didn't put into 3.0 but we shoul= d consider; the fasterxml work we probably want, and a loose println we prob= ably don't >>=20 >> Please take a look, and if we think we're in good shape, I can force-push= these to branches of the same name in the master repository, which will ove= rwrite where they now live (we can leave CURATOR-160-old and CURATOR-215-old= hanging around in the old spots if we really want). >>=20 >> I did verify the branch compiles, and it's now possible to merge with mas= ter with minimal conflicts. >>=20 >>=20 >>> On Wed, Aug 12, 2015 at 4:22 PM, Scott Blum wrot= e: >>> One more... about commit 2c576dc344a167ad4a72d71412c98d76ff4e2d3d, which= was part of CURATOR-160. >>>=20 >>> The history here is a little unclear. There are several new files added= (like AsyncReconfigurable.java) that aren't used anywhere, and I'm unclear o= n how exactly the two sides of 160 were resolved. >>>=20 >>> Basically, I got to a complete end state of recreating the 3.0 branch, a= nd this commit is the only one I ended up "missing" because I think I grabbe= d the wrong "side" of ea1a1684198ca2fa317486a881d5f48466fbf8f8. Any insight= appreciated here. >>>=20 >>>> On Wed, Aug 12, 2015 at 3:30 PM, Jordan Zimmerman wrote: >>>> Because it=E2=80=99s a major change and we=E2=80=99re trying to use sem= antic versioning it was decided that this change needs to be in 3.0.0. >>>>=20 >>>> -JZ >>>>=20 >>>>=20 >>>>=20 >>>>> On August 12, 2015 at 2:29:59 PM, Scott Blum (dragonsinth@gmail.com) w= rote: >>>>>=20 >>>>> Looks like some of the weird issues are around the revert of CURATOR-1= 86, which was "Port Codehaus Jackson to fasterxml Jackson." Looks like it w= as put on trunk, then reverted on trunk, but it is supposed to be in 3.0? >>>>>=20 >>>>> Some clarification here would be great, let me know if it's supposed t= o be in or out for 3.0. >>>>>=20 >>>>>> On Wed, Aug 12, 2015 at 12:53 PM, Scott Blum w= rote: >>>>>> My general strategy is going to be something like this. >>>>>>=20 >>>>>> =46rom what I can tell, the main issue is that there's a super compli= cated development history that's now impossible to do anything with. So my g= oal is to clean up the history in some kind of logical way for each of the l= ogical changes. I don't know if that means squashing each change on the 3.0= branch down to a single commit, or just paring the history down in some way= . >>>>>>=20 >>>>>> Next, I need to find the most recent time master was merged into the 3= .0 branch. That's actually going to be my starting point for a new 3.0 bran= ch, and I'll cherry-pick / rebase changes from the 3.0 branch onto that. Wh= en I'm done, if I did it right, there should be no textual difference betwee= n the two branches, but mine should have a sane history. At that point, it s= hould be easy enough to just rebase 3.0 onto the current master. >>>>>>=20 >>>>>> I'm sure there will be complications but that's my basic plan. gitk i= s my friend for this kind of thing.k >>>>>>=20 >>>>>>> On Wed, Aug 12, 2015 at 12:37 PM, Jordan Zimmerman wrote: >>>>>>>> I'm pretty good with git, and untangling branches and history probl= ems, and I'm happy to take a stab at it, but I don't want to duplicate effor= t. >>>>>>>=20 >>>>>>> Well - probably better than me or Cam. So, please have at it. >>>>>>>=20 >>>>>>>> It looks like just CURATOR-215 and CURATOR-160 but I want to be sur= e I didn't miss anything. >>>>>>>=20 >>>>>>> There will be more - but start with those. Also, if you could explai= n what you=E2=80=99re doing so we can learn I=E2=80=99d appreciate it. >>>>>>>=20 >>>>>>>> 2) Why are the changes in the 3.0 branch not on master? Do we want= them to get onto master? If so, when? >>>>>>>=20 >>>>>>>=20 >>>>>>> 3.0.0 is tied to the ZK 3.5.x branch which is still alpha. Master wi= ll stay tied to 3.4.x until 3.5.x is released. >>>>>>>=20 >>>>>>> -JZ >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On August 12, 2015 at 11:33:12 AM, Scott Blum (dragonsinth@gmail.co= m) wrote: >>>>>>>>=20 >>>>>>>> Hey guys, I can see indeed the 3.0 branch is indeed a giant mess. := ) >>>>>>>>=20 >>>>>>>> I'm pretty good with git, and untangling branches and history probl= ems, and I'm happy to take a stab at it, but I don't want to duplicate effor= t. >>>>>>>>=20 >>>>>>>> Two questions though. >>>>>>>>=20 >>>>>>>> 1) Can we put together a conceptual list of what's in the 3.0 branc= h now? It looks like just CURATOR-215 and CURATOR-160 but I want to be sure= I didn't miss anything. >>>>>>>>=20 >>>>>>>> 2) Why are the changes in the 3.0 branch not on master? Do we want= them to get onto master? If so, when? >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Scott >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Wed, Aug 12, 2015 at 1:57 AM, Cameron McKenzie wrote: >>>>>>>>> Right, I'm a bit stuck. I have renamed the old branch and created a= new >>>>>>>>> CURATOR-3.0 off master. When I try and merge CURATOR-160, a change= to >>>>>>>>> CreateBuilderImpl.java gets merged (I'm not sure why as it doesn't= appear >>>>>>>>> on the list of affected files by CURATOR-160), and this removes th= e >>>>>>>>> 'debugForceFindProtectedNode' member variable which is used by the= >>>>>>>>> TestFrameworkEdges test case. >>>>>>>>>=20 >>>>>>>>> Any ideas what's going on here? The version on the CURATOR-160 bra= nch >>>>>>>>> doesn't have the 'debugForceFindProtectedNode', but it appears tha= t the >>>>>>>>> auto merge when it comes back into the CURATOR-3.0 branch somehow >>>>>>>>> overwrites what's in CURATOR-3.0 instead of merging it. >>>>>>>>>=20 >>>>>>>>> Any ideas? >>>>>>>>>=20 >>>>>>>>> On Wed, Aug 12, 2015 at 2:29 PM, Jordan Zimmerman < >>>>>>>>> jordan@jordanzimmerman.com> wrote: >>>>>>>>>=20 >>>>>>>>> > Maybe just rename it for now and we can delete it later >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On August 11, 2015 at 11:28:14 PM, Cameron McKenzie ( >>>>>>>>> > mckenzie.cam@gmail.com) wrote: >>>>>>>>> > >>>>>>>>> > So, I will delete the existing CURATOR-3.0 branch? >>>>>>>>> > >>>>>>>>> > On Wed, Aug 12, 2015 at 2:04 PM, Cameron McKenzie >>>>>>>>> > wrote: >>>>>>>>> > >>>>>>>>> >> Sure thing. >>>>>>>>> >> >>>>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman < >>>>>>>>> >> jordan@jordanzimmerman.com> wrote: >>>>>>>>> >> >>>>>>>>> >>> Go ahead, if you don=E2=80=99t mind. >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> On August 11, 2015 at 10:50:52 PM, Cameron McKenzie ( >>>>>>>>> >>> mckenzie.cam@gmail.com) wrote: >>>>>>>>> >>> >>>>>>>>> >>> Ok, I can give that a spin if you like, or I'm happy for you t= o do it >>>>>>>>> >>> and I'll branch from there for CURATOR-214. >>>>>>>>> >>> >>>>>>>>> >>> On Wed, Aug 12, 2015 at 1:42 PM, Jordan Zimmerman < >>>>>>>>> >>> jordan@jordanzimmerman.com> wrote: >>>>>>>>> >>> >>>>>>>>> >>>> Is it just a matter of >>>>>>>>> >>>> branching off master and merging all of the CURATOR-3.0 relat= ed >>>>>>>>> >>>> branches? >>>>>>>>> >>>> >>>>>>>>> >>>> Yes, that=E2=80=99s my plan anyway. >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> On August 11, 2015 at 10:39:25 PM, Cameron McKenzie ( >>>>>>>>> >>>> mckenzie.cam@gmail.com) wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> My git knowledge is not deep enough to work out what's going o= n with the >>>>>>>>> >>>> CURATOR-3.0 branch, so I'm happy to go from scratch. Is it ju= st a >>>>>>>>> >>>> matter of >>>>>>>>> >>>> branching off master and merging all of the CURATOR-3.0 relat= ed >>>>>>>>> >>>> branches? >>>>>>>>> >>>> >>>>>>>>> >>>> On Wed, Aug 12, 2015 at 1:26 PM, Jordan Zimmerman < >>>>>>>>> >>>> jordan@jordanzimmerman.com> wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> > We need to come to a decision on the CURATOR-3.0 branch. My= gut >>>>>>>>> >>>> instinct >>>>>>>>> >>>> > is to start from scratch. Any other ideas? >>>>>>>>> >>>> > >>>>>>>>> >>>> > -JZ >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > On August 11, 2015 at 5:28:30 PM, Cameron McKenzie ( >>>>>>>>> >>>> mckenzie.cam@gmail.com) >>>>>>>>> >>>> > wrote: >>>>>>>>> >>>> > >>>>>>>>> >>>> > Also, which branch should the CURATOR-214 fix come off? =46rom= memory >>>>>>>>> >>>> the >>>>>>>>> >>>> > CURATOR-3.0 branch was broken in some capacity. Should I be= branching >>>>>>>>> >>>> off >>>>>>>>> >>>> > CURATOR-3.0-temp or something else? >>>>>>>>> >>>> > cheers >>>>>>>>> >>>> > >>>>>>>>> >>>> > On Wed, Aug 12, 2015 at 8:09 AM, Cameron McKenzie < >>>>>>>>> >>>> mckenzie.cam@gmail.com> >>>>>>>>> >>>> > wrote: >>>>>>>>> >>>> > Will do. In the meantime could you please have a look at my= suggested >>>>>>>>> >>>> > solution for CURATOR-228 (It's in the JIRA)? I don't want t= o start >>>>>>>>> >>>> work on >>>>>>>>> >>>> > it until we have an agreed solution. >>>>>>>>> >>>> > cheers >>>>>>>>> >>>> > >>>>>>>>> >>>> > On Wed, Aug 12, 2015 at 12:23 AM, Jordan Zimmerman < >>>>>>>>> >>>> > jordan@jordanzimmerman.com> wrote: >>>>>>>>> >>>> > Hi Cameron, >>>>>>>>> >>>> > >>>>>>>>> >>>> > Go ahead and do CURATOR-214 - I assigned it to you. >>>>>>>>> >>>> > >>>>>>>>> >>>> > -JZ >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > On August 9, 2015 at 6:47:50 PM, Cameron McKenzie ( >>>>>>>>> >>>> mckenzie.cam@gmail.com) >>>>>>>>> >>>> > wrote: >>>>>>>>> >>>> > >>>>>>>>> >>>> > Sounds reasonable, what's left for 3.0.0? >>>>>>>>> >>>> > >>>>>>>>> >>>> > I think that watcher removal is done. So just the host prov= ider ( >>>>>>>>> >>>> > https://issues.apache.org/jira/browse/CURATOR-213) and new c= reate >>>>>>>>> >>>> APIs ( >>>>>>>>> >>>> > https://issues.apache.org/jira/browse/CURATOR-214). >>>>>>>>> >>>> > >>>>>>>>> >>>> > I'm happy to pick up the new create APIs if no one else is l= ooking at >>>>>>>>> >>>> it. >>>>>>>>> >>>> > cheers >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > On Mon, Aug 10, 2015 at 9:39 AM, Jordan Zimmerman < >>>>>>>>> >>>> > jordan@jordanzimmerman.com> wrote: >>>>>>>>> >>>> > On August 9, 2015 at 5:15:36 PM, Cameron McKenzie ( >>>>>>>>> >>>> mckenzie.cam@gmail.com) >>>>>>>>> >>>> > wrote: >>>>>>>>> >>>> > As for Curator 3.0.0, any ideas when ZK 3.5.x is mean to ge= t out of >>>>>>>>> >>>> Alpha? >>>>>>>>> >>>> > I've seen some grumblings on the ZK mailing list, but nothi= ng >>>>>>>>> >>>> concrete. I >>>>>>>>> >>>> > guess we just need to be ready for that date whenever it is= . >>>>>>>>> >>>> > cheers >>>>>>>>> >>>> > Cam >>>>>>>>> >>>> > Who knows :) But, I know people are using it in Production s= o I think >>>>>>>>> >>>> we >>>>>>>>> >>>> > should just treat it as released software. >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > -JZ >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> > >=20 --Apple-Mail-AA9099D1-7CEB-4B7E-A91B-95B10DBAD39A--