I thought I untangled all that? Is he still having trouble with the new branches I pushed? You need to do this to see my proposed branches:
git remote add scottb https://github.com/dragonsinth/curator.git git remote update You should see several new branches on my remote, including these: * [new branch] 3.0-rejects -> scottb/3.0-rejects * [new branch] CURATOR-160 -> scottb/CURATOR-160 * [new branch] CURATOR-215 -> scottb/CURATOR-215 * [new branch] CURATOR-3.0 -> scottb/CURATOR-3.0 Please take a look at these new proposed branches! For example, you should be able to checkout CURATOR-3.0 and merge in master mostly cleanly (or checkout master and merge in 3.0 mostly cleanly). If we're happy with this, I would push these branches to the apache master. On Thu, Aug 13, 2015 at 11:39 AM, Jordan Zimmerman < [email protected]> wrote: > Cameron said he had trouble with 160. Any ideas? > > ==================== > Jordan Zimmerman > > On Aug 13, 2015, at 10:33 AM, Scott Blum <[email protected]> wrote: > > Any feedback on this? > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <[email protected]> wrote: > >> Okay, I think I'm done. I pushed my work up to my own github mirror, >> https://github.com/dragonsinth/curator >> >> Please note the following branches I pushed: >> >> CURATOR-160: re-history of the original CURATOR-160 branch work, >> simplified. >> CURATOR-215: re-history of the original CURATOR-215 branch work, >> simplified. >> CURATOR-3.0: a proposed new SHA for the new 3.0 branch, contains the >> other 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 >> should consider; the fasterxml work we probably want, and a loose println >> we probably don't >> >> 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 >> overwrite where they now live (we can leave CURATOR-160-old and >> CURATOR-215-old hanging around in the old spots if we really want). >> >> I did verify the branch compiles, and it's now possible to merge with >> master with minimal conflicts. >> >> >> On Wed, Aug 12, 2015 at 4:22 PM, Scott Blum <[email protected]> >> wrote: >> >>> One more... about commit 2c576dc344a167ad4a72d71412c98d76ff4e2d3d, which >>> was part of CURATOR-160. >>> >>> 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 >>> on how exactly the two sides of 160 were resolved. >>> >>> Basically, I got to a complete end state of recreating the 3.0 branch, >>> and this commit is the only one I ended up "missing" because I think I >>> grabbed the wrong "side" of ea1a1684198ca2fa317486a881d5f48466fbf8f8. Any >>> insight appreciated here. >>> >>> On Wed, Aug 12, 2015 at 3:30 PM, Jordan Zimmerman < >>> [email protected]> wrote: >>> >>>> Because it’s a major change and we’re trying to use semantic versioning >>>> it was decided that this change needs to be in 3.0.0. >>>> >>>> -JZ >>>> >>>> >>>> >>>> On August 12, 2015 at 2:29:59 PM, Scott Blum ([email protected]) >>>> wrote: >>>> >>>> Looks like some of the weird issues are around the revert of >>>> CURATOR-186, which was "Port Codehaus Jackson to fasterxml Jackson." Looks >>>> like it was put on trunk, then reverted on trunk, but it is supposed to be >>>> in 3.0? >>>> >>>> Some clarification here would be great, let me know if it's supposed to >>>> be in or out for 3.0. >>>> >>>> On Wed, Aug 12, 2015 at 12:53 PM, Scott Blum <[email protected]> >>>> wrote: >>>> >>>>> My general strategy is going to be something like this. >>>>> >>>>> From what I can tell, the main issue is that there's a super >>>>> complicated development history that's now impossible to do anything with. >>>>> So my goal is to clean up the history in some kind of logical way for each >>>>> of the logical 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. >>>>> >>>>> 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 >>>>> branch, and I'll cherry-pick / rebase changes from the 3.0 branch onto >>>>> that. When I'm done, if I did it right, there should be no textual >>>>> difference between the two branches, but mine should have a sane history. >>>>> At that point, it should be easy enough to just rebase 3.0 onto the >>>>> current >>>>> master. >>>>> >>>>> I'm sure there will be complications but that's my basic plan. gitk >>>>> is my friend for this kind of thing.k >>>>> >>>>> On Wed, Aug 12, 2015 at 12:37 PM, Jordan Zimmerman < >>>>> [email protected]> wrote: >>>>> >>>>>> I'm pretty good with git, and untangling branches and history >>>>>> problems, and I'm happy to take a stab at it, but I don't want to >>>>>> duplicate >>>>>> effort. >>>>>> >>>>>> >>>>>> Well - probably better than me or Cam. So, please have at it. >>>>>> >>>>>> It looks like just CURATOR-215 and CURATOR-160 but I want to be sure >>>>>> I didn't miss anything. >>>>>> >>>>>> There will be more - but start with those. Also, if you could explain >>>>>> what you’re doing so we can learn I’d appreciate it. >>>>>> >>>>>> 2) Why are the changes in the 3.0 branch not on master? Do we want >>>>>> them to get onto master? If so, when? >>>>>> >>>>>> >>>>>> 3.0.0 is tied to the ZK 3.5.x branch which is still alpha. Master >>>>>> will stay tied to 3.4.x until 3.5.x is released. >>>>>> >>>>>> -JZ >>>>>> >>>>>> >>>>>> >>>>>> On August 12, 2015 at 11:33:12 AM, Scott Blum ([email protected]) >>>>>> wrote: >>>>>> >>>>>> Hey guys, I can see indeed the 3.0 branch is indeed a giant mess. :) >>>>>> >>>>>> I'm pretty good with git, and untangling branches and history >>>>>> problems, and I'm happy to take a stab at it, but I don't want to >>>>>> duplicate >>>>>> effort. >>>>>> >>>>>> Two questions though. >>>>>> >>>>>> 1) Can we put together a conceptual list of what's in the 3.0 branch >>>>>> now? It looks like just CURATOR-215 and CURATOR-160 but I want to be >>>>>> sure >>>>>> I didn't miss anything. >>>>>> >>>>>> 2) Why are the changes in the 3.0 branch not on master? Do we want >>>>>> them to get onto master? If so, when? >>>>>> >>>>>> Thanks, >>>>>> Scott >>>>>> >>>>>> >>>>>> On Wed, Aug 12, 2015 at 1:57 AM, Cameron McKenzie < >>>>>> [email protected]> 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 the >>>>>>> 'debugForceFindProtectedNode' member variable which is used by the >>>>>>> TestFrameworkEdges test case. >>>>>>> >>>>>>> Any ideas what's going on here? The version on the CURATOR-160 branch >>>>>>> doesn't have the 'debugForceFindProtectedNode', but it appears that >>>>>>> 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. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> On Wed, Aug 12, 2015 at 2:29 PM, Jordan Zimmerman < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> > Maybe just rename it for now and we can delete it later >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On August 11, 2015 at 11:28:14 PM, Cameron McKenzie ( >>>>>>> > [email protected]) wrote: >>>>>>> > >>>>>>> > So, I will delete the existing CURATOR-3.0 branch? >>>>>>> > >>>>>>> > On Wed, Aug 12, 2015 at 2:04 PM, Cameron McKenzie < >>>>>>> [email protected]> >>>>>>> > wrote: >>>>>>> > >>>>>>> >> Sure thing. >>>>>>> >> >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman < >>>>>>> >> [email protected]> wrote: >>>>>>> >> >>>>>>> >>> Go ahead, if you don’t mind. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On August 11, 2015 at 10:50:52 PM, Cameron McKenzie ( >>>>>>> >>> [email protected]) wrote: >>>>>>> >>> >>>>>>> >>> Ok, I can give that a spin if you like, or I'm happy for you to >>>>>>> do it >>>>>>> >>> and I'll branch from there for CURATOR-214. >>>>>>> >>> >>>>>>> >>> On Wed, Aug 12, 2015 at 1:42 PM, Jordan Zimmerman < >>>>>>> >>> [email protected]> wrote: >>>>>>> >>> >>>>>>> >>>> Is it just a matter of >>>>>>> >>>> branching off master and merging all of the CURATOR-3.0 related >>>>>>> >>>> branches? >>>>>>> >>>> >>>>>>> >>>> Yes, that’s my plan anyway. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> On August 11, 2015 at 10:39:25 PM, Cameron McKenzie ( >>>>>>> >>>> [email protected]) wrote: >>>>>>> >>>> >>>>>>> >>>> My git knowledge is not deep enough to work out what's going on >>>>>>> with the >>>>>>> >>>> CURATOR-3.0 branch, so I'm happy to go from scratch. Is it just >>>>>>> a >>>>>>> >>>> matter of >>>>>>> >>>> branching off master and merging all of the CURATOR-3.0 related >>>>>>> >>>> branches? >>>>>>> >>>> >>>>>>> >>>> On Wed, Aug 12, 2015 at 1:26 PM, Jordan Zimmerman < >>>>>>> >>>> [email protected]> 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 ( >>>>>>> >>>> [email protected]) >>>>>>> >>>> > wrote: >>>>>>> >>>> > >>>>>>> >>>> > Also, which branch should the CURATOR-214 fix come off? From >>>>>>> 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 < >>>>>>> >>>> [email protected]> >>>>>>> >>>> > 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 to >>>>>>> start >>>>>>> >>>> work on >>>>>>> >>>> > it until we have an agreed solution. >>>>>>> >>>> > cheers >>>>>>> >>>> > >>>>>>> >>>> > On Wed, Aug 12, 2015 at 12:23 AM, Jordan Zimmerman < >>>>>>> >>>> > [email protected]> 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 ( >>>>>>> >>>> [email protected]) >>>>>>> >>>> > wrote: >>>>>>> >>>> > >>>>>>> >>>> > Sounds reasonable, what's left for 3.0.0? >>>>>>> >>>> > >>>>>>> >>>> > I think that watcher removal is done. So just the host >>>>>>> provider ( >>>>>>> >>>> > https://issues.apache.org/jira/browse/CURATOR-213) and new >>>>>>> create >>>>>>> >>>> APIs ( >>>>>>> >>>> > https://issues.apache.org/jira/browse/CURATOR-214). >>>>>>> >>>> > >>>>>>> >>>> > I'm happy to pick up the new create APIs if no one else is >>>>>>> looking at >>>>>>> >>>> it. >>>>>>> >>>> > cheers >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > On Mon, Aug 10, 2015 at 9:39 AM, Jordan Zimmerman < >>>>>>> >>>> > [email protected]> wrote: >>>>>>> >>>> > On August 9, 2015 at 5:15:36 PM, Cameron McKenzie ( >>>>>>> >>>> [email protected]) >>>>>>> >>>> > wrote: >>>>>>> >>>> > As for Curator 3.0.0, any ideas when ZK 3.5.x is mean to get >>>>>>> out of >>>>>>> >>>> Alpha? >>>>>>> >>>> > I've seen some grumblings on the ZK mailing list, but nothing >>>>>>> >>>> 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 so >>>>>>> I think >>>>>>> >>>> we >>>>>>> >>>> > should just treat it as released software. >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > -JZ >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
