I think dual commits tend to be problematic. I'd suggest anything for 2.x goes into master and then we immediately merge master into 3.0. Anything for 3.0 stays in 3.0 only. (There will soon be a discussion to be had about whether master should become 3.0 in the near future.)
More immediately, has anyone had a chance to look at my proposed history redo? I feel like this is starting to stall out. Can I set a 24 period starting now for people to object, and if I don't hear anything, I'm going to go ahead and push the updates. I will leave "old" branch markers on the old stuff to avoid being destructive. On Fri, Aug 14, 2015 at 3:24 PM, Mike Drob <mad...@cloudera.com> wrote: > Once we have a stable 3.0 branch, should we dual-commit everything to > master and 3.x? The ZK3.5 "alpha" labelling can scare off some adopters, so > I think it is important to maintain 2.x for a little while longer. > > I can volunteer to do the next 2.x release once the tests are stabilized - > I'll start a new thread on that sometime this weekend. > > On Fri, Aug 14, 2015 at 2:12 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > > Yes, the 3.0 branch I created should have everything. But let me > emphasize > > I haven't pushed this to apache yet! I wanted you guys to check it out > > first, it's only pushed to my mirror. > > > > It's.... complicated to describe what I did. Mostly rebasing, some > cherry > > picking, and fixing merge conflicts. But using gitk to visualize what I > > was doing. I also had to redo it once or twice when something went > wrong. > > Sorry I can't really give and exact recount... I worked on this for > quite a > > while, like 2 hours maybe. > > > > On Thu, Aug 13, 2015 at 11:03 PM, Cameron McKenzie < > mckenzie....@gmail.com > > > > > wrote: > > > > > hey Scott, > > > Didn't realise that you'd pushed new CURATOR-3.0 branches. So your > > > CURATOR-3.0 branch has all the CURATOR-3.0 related branches merged in. > > Can > > > I ask how you fixed the issues, as my git knowledge about weird merge > > > issues is basically non existent? > > > > > > When I tried to merge master into CURATOR-160 (which was the first of > the > > > CURATOR-3.0 related branches, and I believe all the others were > branched > > > off this), it seems like a few of the fast forward merges didn't merge > > > everything, which thankfully was obvious because the build failed. > > > cheers > > > > > > On Fri, Aug 14, 2015 at 1:49 AM, Scott Blum <dragonsi...@gmail.com> > > wrote: > > > > > > > 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 < > > > > jor...@jordanzimmerman.com> wrote: > > > > > > > > > Cameron said he had trouble with 160. Any ideas? > > > > > > > > > > ==================== > > > > > Jordan Zimmerman > > > > > > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <dragonsi...@gmail.com> > > > wrote: > > > > > > > > > > Any feedback on this? > > > > > > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dragonsi...@gmail.com > > > > > > 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 < > dragonsi...@gmail.com> > > > > >> 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 < > > > > >>> jor...@jordanzimmerman.com> 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 ( > > dragonsi...@gmail.com > > > ) > > > > >>>> 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 < > > dragonsi...@gmail.com > > > > > > > > >>>> 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 < > > > > >>>>> jor...@jordanzimmerman.com> 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 ( > > > > dragonsi...@gmail.com) > > > > >>>>>> 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 < > > > > >>>>>> mckenzie....@gmail.com> 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 < > > > > >>>>>>> jor...@jordanzimmerman.com> wrote: > > > > >>>>>>> > > > > >>>>>>> > Maybe just rename it for now and we can delete it later > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > On August 11, 2015 at 11:28:14 PM, Cameron McKenzie ( > > > > >>>>>>> > mckenzie....@gmail.com) wrote: > > > > >>>>>>> > > > > > >>>>>>> > So, I will delete the existing CURATOR-3.0 branch? > > > > >>>>>>> > > > > > >>>>>>> > On Wed, Aug 12, 2015 at 2:04 PM, Cameron McKenzie < > > > > >>>>>>> mckenzie....@gmail.com> > > > > >>>>>>> > wrote: > > > > >>>>>>> > > > > > >>>>>>> >> Sure thing. > > > > >>>>>>> >> > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman < > > > > >>>>>>> >> jor...@jordanzimmerman.com> wrote: > > > > >>>>>>> >> > > > > >>>>>>> >>> Go ahead, if you don’t mind. > > > > >>>>>>> >>> > > > > >>>>>>> >>> > > > > >>>>>>> >>> > > > > >>>>>>> >>> On August 11, 2015 at 10:50:52 PM, Cameron McKenzie ( > > > > >>>>>>> >>> mckenzie....@gmail.com) 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 < > > > > >>>>>>> >>> jor...@jordanzimmerman.com> 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 ( > > > > >>>>>>> >>>> mckenzie....@gmail.com) 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 < > > > > >>>>>>> >>>> jor...@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....@gmail.com) > > > > >>>>>>> >>>> > 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 < > > > > >>>>>>> >>>> mckenzie....@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 > > > to > > > > >>>>>>> start > > > > >>>>>>> >>>> work on > > > > >>>>>>> >>>> > it until we have an agreed solution. > > > > >>>>>>> >>>> > cheers > > > > >>>>>>> >>>> > > > > > >>>>>>> >>>> > On Wed, Aug 12, 2015 at 12:23 AM, Jordan Zimmerman < > > > > >>>>>>> >>>> > jor...@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....@gmail.com) > > > > >>>>>>> >>>> > 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 < > > > > >>>>>>> >>>> > jor...@jordanzimmerman.com> wrote: > > > > >>>>>>> >>>> > On August 9, 2015 at 5:15:36 PM, Cameron McKenzie ( > > > > >>>>>>> >>>> mckenzie....@gmail.com) > > > > >>>>>>> >>>> > 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 > > > > >>>>>>> >>>> > > > > > >>>>>>> >>>> > > > > > >>>>>>> >>>> > > > > > >>>>>>> >>>> > > > > > >>>>>>> >>>> > > > > > >>>>>>> >>>> > > > > >>>>>>> >>>> > > > > >>>>>>> >>> > > > > >>>>>>> >> > > > > >>>>>>> > > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > > >
