You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2015/08/09 17:36:51 UTC
Next Steps
Hey Folks,
First, I apologize for being AWOL from Curator for the past while. But, I’m now available. I’d like to discuss next steps and actions. My personal priorities are: a) release 2.9.0; b) release 3.0.0.
** Issues for 2.9.0
- Remaining bugs.
- Any additional issues to be included
** Issues for 3.0.0
- Fix the merge issues
- Testing/validation
- Any additional issues to be included
Thoughts?
-JZ
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Sounds reasonable, what's left for 3.0.0?
The first most important step is to get a good merge again. We may need to start from scratch, I don’t know.
I'm happy to pick up the new create APIs if no one else is looking at it.
I did work on the new create APIs. I’ll get back 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 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 <jo...@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 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
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I’ll bet you need to merge master into each of the branches first. Have you tried that?
-Jordan
On August 12, 2015 at 12:57:28 AM, Cameron McKenzie (mckenzie.cam@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 <jo...@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.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 <mc...@gmail.com> wrote:
Sure thing.
On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
Go ahead, if you don’t 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 to do it and I'll branch from there for CURATOR-214.
On Wed, Aug 12, 2015 at 1:42 PM, Jordan Zimmerman <jo...@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.cam@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 <
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? 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 <mc...@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 <
> 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 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 <
> 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 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
>
>
>
>
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
Cool, I pushed you a branch named '217-merged' you can try out. It needs a
fix to RemoveWatchesBuilderImpl that I'm sure you know what to do.
On Mon, Aug 17, 2015 at 10:10 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Scoot, I will give that a spin.
> cheers
>
> On Tue, Aug 18, 2015 at 12:09 PM, Scott Blum <dr...@gmail.com>
> wrote:
>
> > I see. Okay, I think I may have an answer for you. Try:
> >
> > watching.getWatcher(client, ZooDefs.CONFIG_NODE)
> >
> >
> > On Mon, Aug 17, 2015 at 9:22 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > Ok, there were a bunch of other conflicts as well which were easy to
> > > resolve.
> > >
> > > On Tue, Aug 18, 2015 at 11:19 AM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > >
> > > > K, lemme take a look. Both of those branches, CURATOR-161 and
> > > CURATOR-217,
> > > > were branched from the old 3.0 branch. I'd like to check if rebasing
> > > them
> > > > makes the problem disappear.
> > > >
> > > >
> > > > On Mon, Aug 17, 2015 at 9:18 PM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com>
> > > > wrote:
> > > >
> > > > > Sorry, typo, yes, I was trying to merge into CURATOR-3.0.
> > > > >
> > > > > On Tue, Aug 18, 2015 at 11:14 AM, Scott Blum <
> dragonsinth@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > One quick thing... both of those JIRAs are marked for 3.0. Are
> you
> > > > sure
> > > > > > you want to merge that branch into master? I think you want to
> > merge
> > > > it
> > > > > > into CURATOR-3.0.
> > > > > >
> > > > > > On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <
> > > > > mckenzie.cam@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I think it's just because the GetConfigBuilderImpl wasn't
> present
> > > in
> > > > > the
> > > > > > > CURATOR-217 branch, so it didn't get updated along with the
> other
> > > > > changes
> > > > > > > that Jordan made when the interface into the Watching class
> > > changed.
> > > > > > >
> > > > > > > On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <
> > > dragonsinth@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Let me take a look... it's possible your branch needed to be
> > > > rebased
> > > > > > > prior
> > > > > > > > to merging.
> > > > > > > > Gimme 30 minutes.
> > > > > > > >
> > > > > > > > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> > > > > > > mckenzie.cam@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks Scott,
> > > > > > > > > I've just merged CURATOR-217 into master and have one small
> > > > issue.
> > > > > > > > >
> > > > > > > > > Jordan, with the changes you made with to the Watching.java
> > > > class,
> > > > > > the
> > > > > > > > > getWatcher() call now takes a CuratorFramework reference
> and
> > a
> > > > path
> > > > > > > > > reference.
> > > > > > > > >
> > > > > > > > > The GetConfigBuilderImpl breaks when merging because it's
> > using
> > > > the
> > > > > > old
> > > > > > > > > getWatcher() call that doesn't exist any more. This isn't
> an
> > > > issue
> > > > > to
> > > > > > > > fix,
> > > > > > > > > but I'm just wondering what path reference should be used
> for
> > > the
> > > > > > > > > configuration case, as it's a different sort of watch. It's
> > > just
> > > > > > passed
> > > > > > > > to
> > > > > > > > > the getConfig() call on the ZooKeeper class. It seems that
> I
> > > > can't
> > > > > > just
> > > > > > > > > pass in a null path as this gets validated. Suggestions?
> > > > > > > > >
> > > > > > > > > cheers
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > > > >
> > > > > > > > > > Great work. Thank you.
> > > > > > > > > >
> > > > > > > > > > ====================
> > > > > > > > > > Jordan Zimmerman
> > > > > > > > > >
> > > > > > > > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <
> > > > > dragonsinth@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > This is now done, sorry for the delay. Let me describe
> > the
> > > > > > current
> > > > > > > > > state
> > > > > > > > > > > of the world:
> > > > > > > > > > >
> > > > > > > > > > > CURATOR-215-original, CURATOR-160-original,
> > > CURATOR-3.0-old,
> > > > > > > > > > > CURATOR-3.0-temp - these are the old versions of all
> the
> > > > > > branches,
> > > > > > > we
> > > > > > > > > > > should consider pruning them at some point.
> > > > > > > > > > >
> > > > > > > > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are
> > > > fixed/rebased
> > > > > > > > > versions
> > > > > > > > > > of
> > > > > > > > > > > the branches we should stick with.
> > > > > > > > > > >
> > > > > > > > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.*
> > > There
> > > > is
> > > > > > > > nothing
> > > > > > > > > > > that has been committed to master that isn't in 3.0
> now.
> > > > > > > > > > >
> > > > > > > > > > > Procedures going forward:
> > > > > > > > > > >
> > > > > > > > > > > - If you're working on stuff for 2.8 / 2.9, branch from
> > > > master
> > > > > > and
> > > > > > > > > > > merge/commit to master.
> > > > > > > > > > >
> > > > > > > > > > > - If you're working on stuff for 3.0, branch from
> > > CURATOR-3.0
> > > > > and
> > > > > > > > > > > merge/commit to CURATOR-3.0.
> > > > > > > > > > >
> > > > > > > > > > > - Periodically, we'll want to get master changes into
> > 3.0.
> > > > To
> > > > > do
> > > > > > > > this,
> > > > > > > > > > *check
> > > > > > > > > > > out CURATOR-3.0*, and merge master into that, then push
> > the
> > > > > > result
> > > > > > > > > after
> > > > > > > > > > > fixing conflicts (which should be small /
> non-existent).
> > > > > *Don't
> > > > > > do
> > > > > > > > it
> > > > > > > > > > the
> > > > > > > > > > > other way, don't check out master and merge 3.0 into
> it.*
> > > > > > > > > > >
> > > > > > > > > > > For discussion: there is a *3.0-rejects* branch. One
> of
> > > the
> > > > > > > commits
> > > > > > > > > > there
> > > > > > > > > > > is and added System.out.println that I think we don't
> > want.
> > > > > The
> > > > > > > > other
> > > > > > > > > > one
> > > > > > > > > > > is the work to migrate to fasterxml Jackson. I think
> we
> > > > > actually
> > > > > > > > want
> > > > > > > > > > this
> > > > > > > > > > > commit on 3.0. Please take a look and let me know, if
> we
> > > > want
> > > > > > this
> > > > > > > > > > commit,
> > > > > > > > > > > we should cherry-pick it onto 3.0. I'm happy to do
> that.
> > > > > > > > > > >
> > > > > > > > > > > Everything I did should be reversible, so let me know
> if
> > I
> > > > > > screwed
> > > > > > > > > > anything
> > > > > > > > > > > up!
> > > > > > > > > > >
> > > > > > > > > > > --Scott
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Scoot, I will give that a spin.
cheers
On Tue, Aug 18, 2015 at 12:09 PM, Scott Blum <dr...@gmail.com> wrote:
> I see. Okay, I think I may have an answer for you. Try:
>
> watching.getWatcher(client, ZooDefs.CONFIG_NODE)
>
>
> On Mon, Aug 17, 2015 at 9:22 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Ok, there were a bunch of other conflicts as well which were easy to
> > resolve.
> >
> > On Tue, Aug 18, 2015 at 11:19 AM, Scott Blum <dr...@gmail.com>
> > wrote:
> >
> > > K, lemme take a look. Both of those branches, CURATOR-161 and
> > CURATOR-217,
> > > were branched from the old 3.0 branch. I'd like to check if rebasing
> > them
> > > makes the problem disappear.
> > >
> > >
> > > On Mon, Aug 17, 2015 at 9:18 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com>
> > > wrote:
> > >
> > > > Sorry, typo, yes, I was trying to merge into CURATOR-3.0.
> > > >
> > > > On Tue, Aug 18, 2015 at 11:14 AM, Scott Blum <dr...@gmail.com>
> > > > wrote:
> > > >
> > > > > One quick thing... both of those JIRAs are marked for 3.0. Are you
> > > sure
> > > > > you want to merge that branch into master? I think you want to
> merge
> > > it
> > > > > into CURATOR-3.0.
> > > > >
> > > > > On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <
> > > > mckenzie.cam@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I think it's just because the GetConfigBuilderImpl wasn't present
> > in
> > > > the
> > > > > > CURATOR-217 branch, so it didn't get updated along with the other
> > > > changes
> > > > > > that Jordan made when the interface into the Watching class
> > changed.
> > > > > >
> > > > > > On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <
> > dragonsinth@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Let me take a look... it's possible your branch needed to be
> > > rebased
> > > > > > prior
> > > > > > > to merging.
> > > > > > > Gimme 30 minutes.
> > > > > > >
> > > > > > > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> > > > > > mckenzie.cam@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks Scott,
> > > > > > > > I've just merged CURATOR-217 into master and have one small
> > > issue.
> > > > > > > >
> > > > > > > > Jordan, with the changes you made with to the Watching.java
> > > class,
> > > > > the
> > > > > > > > getWatcher() call now takes a CuratorFramework reference and
> a
> > > path
> > > > > > > > reference.
> > > > > > > >
> > > > > > > > The GetConfigBuilderImpl breaks when merging because it's
> using
> > > the
> > > > > old
> > > > > > > > getWatcher() call that doesn't exist any more. This isn't an
> > > issue
> > > > to
> > > > > > > fix,
> > > > > > > > but I'm just wondering what path reference should be used for
> > the
> > > > > > > > configuration case, as it's a different sort of watch. It's
> > just
> > > > > passed
> > > > > > > to
> > > > > > > > the getConfig() call on the ZooKeeper class. It seems that I
> > > can't
> > > > > just
> > > > > > > > pass in a null path as this gets validated. Suggestions?
> > > > > > > >
> > > > > > > > cheers
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > > >
> > > > > > > > > Great work. Thank you.
> > > > > > > > >
> > > > > > > > > ====================
> > > > > > > > > Jordan Zimmerman
> > > > > > > > >
> > > > > > > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <
> > > > dragonsinth@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > This is now done, sorry for the delay. Let me describe
> the
> > > > > current
> > > > > > > > state
> > > > > > > > > > of the world:
> > > > > > > > > >
> > > > > > > > > > CURATOR-215-original, CURATOR-160-original,
> > CURATOR-3.0-old,
> > > > > > > > > > CURATOR-3.0-temp - these are the old versions of all the
> > > > > branches,
> > > > > > we
> > > > > > > > > > should consider pruning them at some point.
> > > > > > > > > >
> > > > > > > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are
> > > fixed/rebased
> > > > > > > > versions
> > > > > > > > > of
> > > > > > > > > > the branches we should stick with.
> > > > > > > > > >
> > > > > > > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.*
> > There
> > > is
> > > > > > > nothing
> > > > > > > > > > that has been committed to master that isn't in 3.0 now.
> > > > > > > > > >
> > > > > > > > > > Procedures going forward:
> > > > > > > > > >
> > > > > > > > > > - If you're working on stuff for 2.8 / 2.9, branch from
> > > master
> > > > > and
> > > > > > > > > > merge/commit to master.
> > > > > > > > > >
> > > > > > > > > > - If you're working on stuff for 3.0, branch from
> > CURATOR-3.0
> > > > and
> > > > > > > > > > merge/commit to CURATOR-3.0.
> > > > > > > > > >
> > > > > > > > > > - Periodically, we'll want to get master changes into
> 3.0.
> > > To
> > > > do
> > > > > > > this,
> > > > > > > > > *check
> > > > > > > > > > out CURATOR-3.0*, and merge master into that, then push
> the
> > > > > result
> > > > > > > > after
> > > > > > > > > > fixing conflicts (which should be small / non-existent).
> > > > *Don't
> > > > > do
> > > > > > > it
> > > > > > > > > the
> > > > > > > > > > other way, don't check out master and merge 3.0 into it.*
> > > > > > > > > >
> > > > > > > > > > For discussion: there is a *3.0-rejects* branch. One of
> > the
> > > > > > commits
> > > > > > > > > there
> > > > > > > > > > is and added System.out.println that I think we don't
> want.
> > > > The
> > > > > > > other
> > > > > > > > > one
> > > > > > > > > > is the work to migrate to fasterxml Jackson. I think we
> > > > actually
> > > > > > > want
> > > > > > > > > this
> > > > > > > > > > commit on 3.0. Please take a look and let me know, if we
> > > want
> > > > > this
> > > > > > > > > commit,
> > > > > > > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > > > > > > >
> > > > > > > > > > Everything I did should be reversible, so let me know if
> I
> > > > > screwed
> > > > > > > > > anything
> > > > > > > > > > up!
> > > > > > > > > >
> > > > > > > > > > --Scott
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
I see. Okay, I think I may have an answer for you. Try:
watching.getWatcher(client, ZooDefs.CONFIG_NODE)
On Mon, Aug 17, 2015 at 9:22 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Ok, there were a bunch of other conflicts as well which were easy to
> resolve.
>
> On Tue, Aug 18, 2015 at 11:19 AM, Scott Blum <dr...@gmail.com>
> wrote:
>
> > K, lemme take a look. Both of those branches, CURATOR-161 and
> CURATOR-217,
> > were branched from the old 3.0 branch. I'd like to check if rebasing
> them
> > makes the problem disappear.
> >
> >
> > On Mon, Aug 17, 2015 at 9:18 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > Sorry, typo, yes, I was trying to merge into CURATOR-3.0.
> > >
> > > On Tue, Aug 18, 2015 at 11:14 AM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > >
> > > > One quick thing... both of those JIRAs are marked for 3.0. Are you
> > sure
> > > > you want to merge that branch into master? I think you want to merge
> > it
> > > > into CURATOR-3.0.
> > > >
> > > > On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com>
> > > > wrote:
> > > >
> > > > > I think it's just because the GetConfigBuilderImpl wasn't present
> in
> > > the
> > > > > CURATOR-217 branch, so it didn't get updated along with the other
> > > changes
> > > > > that Jordan made when the interface into the Watching class
> changed.
> > > > >
> > > > > On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <
> dragonsinth@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Let me take a look... it's possible your branch needed to be
> > rebased
> > > > > prior
> > > > > > to merging.
> > > > > > Gimme 30 minutes.
> > > > > >
> > > > > > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> > > > > mckenzie.cam@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks Scott,
> > > > > > > I've just merged CURATOR-217 into master and have one small
> > issue.
> > > > > > >
> > > > > > > Jordan, with the changes you made with to the Watching.java
> > class,
> > > > the
> > > > > > > getWatcher() call now takes a CuratorFramework reference and a
> > path
> > > > > > > reference.
> > > > > > >
> > > > > > > The GetConfigBuilderImpl breaks when merging because it's using
> > the
> > > > old
> > > > > > > getWatcher() call that doesn't exist any more. This isn't an
> > issue
> > > to
> > > > > > fix,
> > > > > > > but I'm just wondering what path reference should be used for
> the
> > > > > > > configuration case, as it's a different sort of watch. It's
> just
> > > > passed
> > > > > > to
> > > > > > > the getConfig() call on the ZooKeeper class. It seems that I
> > can't
> > > > just
> > > > > > > pass in a null path as this gets validated. Suggestions?
> > > > > > >
> > > > > > > cheers
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > >
> > > > > > > > Great work. Thank you.
> > > > > > > >
> > > > > > > > ====================
> > > > > > > > Jordan Zimmerman
> > > > > > > >
> > > > > > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <
> > > dragonsinth@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > This is now done, sorry for the delay. Let me describe the
> > > > current
> > > > > > > state
> > > > > > > > > of the world:
> > > > > > > > >
> > > > > > > > > CURATOR-215-original, CURATOR-160-original,
> CURATOR-3.0-old,
> > > > > > > > > CURATOR-3.0-temp - these are the old versions of all the
> > > > branches,
> > > > > we
> > > > > > > > > should consider pruning them at some point.
> > > > > > > > >
> > > > > > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are
> > fixed/rebased
> > > > > > > versions
> > > > > > > > of
> > > > > > > > > the branches we should stick with.
> > > > > > > > >
> > > > > > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.*
> There
> > is
> > > > > > nothing
> > > > > > > > > that has been committed to master that isn't in 3.0 now.
> > > > > > > > >
> > > > > > > > > Procedures going forward:
> > > > > > > > >
> > > > > > > > > - If you're working on stuff for 2.8 / 2.9, branch from
> > master
> > > > and
> > > > > > > > > merge/commit to master.
> > > > > > > > >
> > > > > > > > > - If you're working on stuff for 3.0, branch from
> CURATOR-3.0
> > > and
> > > > > > > > > merge/commit to CURATOR-3.0.
> > > > > > > > >
> > > > > > > > > - Periodically, we'll want to get master changes into 3.0.
> > To
> > > do
> > > > > > this,
> > > > > > > > *check
> > > > > > > > > out CURATOR-3.0*, and merge master into that, then push the
> > > > result
> > > > > > > after
> > > > > > > > > fixing conflicts (which should be small / non-existent).
> > > *Don't
> > > > do
> > > > > > it
> > > > > > > > the
> > > > > > > > > other way, don't check out master and merge 3.0 into it.*
> > > > > > > > >
> > > > > > > > > For discussion: there is a *3.0-rejects* branch. One of
> the
> > > > > commits
> > > > > > > > there
> > > > > > > > > is and added System.out.println that I think we don't want.
> > > The
> > > > > > other
> > > > > > > > one
> > > > > > > > > is the work to migrate to fasterxml Jackson. I think we
> > > actually
> > > > > > want
> > > > > > > > this
> > > > > > > > > commit on 3.0. Please take a look and let me know, if we
> > want
> > > > this
> > > > > > > > commit,
> > > > > > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > > > > > >
> > > > > > > > > Everything I did should be reversible, so let me know if I
> > > > screwed
> > > > > > > > anything
> > > > > > > > > up!
> > > > > > > > >
> > > > > > > > > --Scott
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Ok, there were a bunch of other conflicts as well which were easy to
resolve.
On Tue, Aug 18, 2015 at 11:19 AM, Scott Blum <dr...@gmail.com> wrote:
> K, lemme take a look. Both of those branches, CURATOR-161 and CURATOR-217,
> were branched from the old 3.0 branch. I'd like to check if rebasing them
> makes the problem disappear.
>
>
> On Mon, Aug 17, 2015 at 9:18 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Sorry, typo, yes, I was trying to merge into CURATOR-3.0.
> >
> > On Tue, Aug 18, 2015 at 11:14 AM, Scott Blum <dr...@gmail.com>
> > wrote:
> >
> > > One quick thing... both of those JIRAs are marked for 3.0. Are you
> sure
> > > you want to merge that branch into master? I think you want to merge
> it
> > > into CURATOR-3.0.
> > >
> > > On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com>
> > > wrote:
> > >
> > > > I think it's just because the GetConfigBuilderImpl wasn't present in
> > the
> > > > CURATOR-217 branch, so it didn't get updated along with the other
> > changes
> > > > that Jordan made when the interface into the Watching class changed.
> > > >
> > > > On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <dr...@gmail.com>
> > > > wrote:
> > > >
> > > > > Let me take a look... it's possible your branch needed to be
> rebased
> > > > prior
> > > > > to merging.
> > > > > Gimme 30 minutes.
> > > > >
> > > > > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> > > > mckenzie.cam@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks Scott,
> > > > > > I've just merged CURATOR-217 into master and have one small
> issue.
> > > > > >
> > > > > > Jordan, with the changes you made with to the Watching.java
> class,
> > > the
> > > > > > getWatcher() call now takes a CuratorFramework reference and a
> path
> > > > > > reference.
> > > > > >
> > > > > > The GetConfigBuilderImpl breaks when merging because it's using
> the
> > > old
> > > > > > getWatcher() call that doesn't exist any more. This isn't an
> issue
> > to
> > > > > fix,
> > > > > > but I'm just wondering what path reference should be used for the
> > > > > > configuration case, as it's a different sort of watch. It's just
> > > passed
> > > > > to
> > > > > > the getConfig() call on the ZooKeeper class. It seems that I
> can't
> > > just
> > > > > > pass in a null path as this gets validated. Suggestions?
> > > > > >
> > > > > > cheers
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > >
> > > > > > > Great work. Thank you.
> > > > > > >
> > > > > > > ====================
> > > > > > > Jordan Zimmerman
> > > > > > >
> > > > > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <
> > dragonsinth@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > This is now done, sorry for the delay. Let me describe the
> > > current
> > > > > > state
> > > > > > > > of the world:
> > > > > > > >
> > > > > > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > > > > > CURATOR-3.0-temp - these are the old versions of all the
> > > branches,
> > > > we
> > > > > > > > should consider pruning them at some point.
> > > > > > > >
> > > > > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are
> fixed/rebased
> > > > > > versions
> > > > > > > of
> > > > > > > > the branches we should stick with.
> > > > > > > >
> > > > > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There
> is
> > > > > nothing
> > > > > > > > that has been committed to master that isn't in 3.0 now.
> > > > > > > >
> > > > > > > > Procedures going forward:
> > > > > > > >
> > > > > > > > - If you're working on stuff for 2.8 / 2.9, branch from
> master
> > > and
> > > > > > > > merge/commit to master.
> > > > > > > >
> > > > > > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0
> > and
> > > > > > > > merge/commit to CURATOR-3.0.
> > > > > > > >
> > > > > > > > - Periodically, we'll want to get master changes into 3.0.
> To
> > do
> > > > > this,
> > > > > > > *check
> > > > > > > > out CURATOR-3.0*, and merge master into that, then push the
> > > result
> > > > > > after
> > > > > > > > fixing conflicts (which should be small / non-existent).
> > *Don't
> > > do
> > > > > it
> > > > > > > the
> > > > > > > > other way, don't check out master and merge 3.0 into it.*
> > > > > > > >
> > > > > > > > For discussion: there is a *3.0-rejects* branch. One of the
> > > > commits
> > > > > > > there
> > > > > > > > is and added System.out.println that I think we don't want.
> > The
> > > > > other
> > > > > > > one
> > > > > > > > is the work to migrate to fasterxml Jackson. I think we
> > actually
> > > > > want
> > > > > > > this
> > > > > > > > commit on 3.0. Please take a look and let me know, if we
> want
> > > this
> > > > > > > commit,
> > > > > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > > > > >
> > > > > > > > Everything I did should be reversible, so let me know if I
> > > screwed
> > > > > > > anything
> > > > > > > > up!
> > > > > > > >
> > > > > > > > --Scott
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
K, lemme take a look. Both of those branches, CURATOR-161 and CURATOR-217,
were branched from the old 3.0 branch. I'd like to check if rebasing them
makes the problem disappear.
On Mon, Aug 17, 2015 at 9:18 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Sorry, typo, yes, I was trying to merge into CURATOR-3.0.
>
> On Tue, Aug 18, 2015 at 11:14 AM, Scott Blum <dr...@gmail.com>
> wrote:
>
> > One quick thing... both of those JIRAs are marked for 3.0. Are you sure
> > you want to merge that branch into master? I think you want to merge it
> > into CURATOR-3.0.
> >
> > On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > I think it's just because the GetConfigBuilderImpl wasn't present in
> the
> > > CURATOR-217 branch, so it didn't get updated along with the other
> changes
> > > that Jordan made when the interface into the Watching class changed.
> > >
> > > On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > >
> > > > Let me take a look... it's possible your branch needed to be rebased
> > > prior
> > > > to merging.
> > > > Gimme 30 minutes.
> > > >
> > > > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com>
> > > > wrote:
> > > >
> > > > > Thanks Scott,
> > > > > I've just merged CURATOR-217 into master and have one small issue.
> > > > >
> > > > > Jordan, with the changes you made with to the Watching.java class,
> > the
> > > > > getWatcher() call now takes a CuratorFramework reference and a path
> > > > > reference.
> > > > >
> > > > > The GetConfigBuilderImpl breaks when merging because it's using the
> > old
> > > > > getWatcher() call that doesn't exist any more. This isn't an issue
> to
> > > > fix,
> > > > > but I'm just wondering what path reference should be used for the
> > > > > configuration case, as it's a different sort of watch. It's just
> > passed
> > > > to
> > > > > the getConfig() call on the ZooKeeper class. It seems that I can't
> > just
> > > > > pass in a null path as this gets validated. Suggestions?
> > > > >
> > > > > cheers
> > > > >
> > > > >
> > > > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > > > jordan@jordanzimmerman.com> wrote:
> > > > >
> > > > > > Great work. Thank you.
> > > > > >
> > > > > > ====================
> > > > > > Jordan Zimmerman
> > > > > >
> > > > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <
> dragonsinth@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > This is now done, sorry for the delay. Let me describe the
> > current
> > > > > state
> > > > > > > of the world:
> > > > > > >
> > > > > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > > > > CURATOR-3.0-temp - these are the old versions of all the
> > branches,
> > > we
> > > > > > > should consider pruning them at some point.
> > > > > > >
> > > > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > > > > versions
> > > > > > of
> > > > > > > the branches we should stick with.
> > > > > > >
> > > > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> > > > nothing
> > > > > > > that has been committed to master that isn't in 3.0 now.
> > > > > > >
> > > > > > > Procedures going forward:
> > > > > > >
> > > > > > > - If you're working on stuff for 2.8 / 2.9, branch from master
> > and
> > > > > > > merge/commit to master.
> > > > > > >
> > > > > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0
> and
> > > > > > > merge/commit to CURATOR-3.0.
> > > > > > >
> > > > > > > - Periodically, we'll want to get master changes into 3.0. To
> do
> > > > this,
> > > > > > *check
> > > > > > > out CURATOR-3.0*, and merge master into that, then push the
> > result
> > > > > after
> > > > > > > fixing conflicts (which should be small / non-existent).
> *Don't
> > do
> > > > it
> > > > > > the
> > > > > > > other way, don't check out master and merge 3.0 into it.*
> > > > > > >
> > > > > > > For discussion: there is a *3.0-rejects* branch. One of the
> > > commits
> > > > > > there
> > > > > > > is and added System.out.println that I think we don't want.
> The
> > > > other
> > > > > > one
> > > > > > > is the work to migrate to fasterxml Jackson. I think we
> actually
> > > > want
> > > > > > this
> > > > > > > commit on 3.0. Please take a look and let me know, if we want
> > this
> > > > > > commit,
> > > > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > > > >
> > > > > > > Everything I did should be reversible, so let me know if I
> > screwed
> > > > > > anything
> > > > > > > up!
> > > > > > >
> > > > > > > --Scott
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Sorry, typo, yes, I was trying to merge into CURATOR-3.0.
On Tue, Aug 18, 2015 at 11:14 AM, Scott Blum <dr...@gmail.com> wrote:
> One quick thing... both of those JIRAs are marked for 3.0. Are you sure
> you want to merge that branch into master? I think you want to merge it
> into CURATOR-3.0.
>
> On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > I think it's just because the GetConfigBuilderImpl wasn't present in the
> > CURATOR-217 branch, so it didn't get updated along with the other changes
> > that Jordan made when the interface into the Watching class changed.
> >
> > On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <dr...@gmail.com>
> > wrote:
> >
> > > Let me take a look... it's possible your branch needed to be rebased
> > prior
> > > to merging.
> > > Gimme 30 minutes.
> > >
> > > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com>
> > > wrote:
> > >
> > > > Thanks Scott,
> > > > I've just merged CURATOR-217 into master and have one small issue.
> > > >
> > > > Jordan, with the changes you made with to the Watching.java class,
> the
> > > > getWatcher() call now takes a CuratorFramework reference and a path
> > > > reference.
> > > >
> > > > The GetConfigBuilderImpl breaks when merging because it's using the
> old
> > > > getWatcher() call that doesn't exist any more. This isn't an issue to
> > > fix,
> > > > but I'm just wondering what path reference should be used for the
> > > > configuration case, as it's a different sort of watch. It's just
> passed
> > > to
> > > > the getConfig() call on the ZooKeeper class. It seems that I can't
> just
> > > > pass in a null path as this gets validated. Suggestions?
> > > >
> > > > cheers
> > > >
> > > >
> > > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > > jordan@jordanzimmerman.com> wrote:
> > > >
> > > > > Great work. Thank you.
> > > > >
> > > > > ====================
> > > > > Jordan Zimmerman
> > > > >
> > > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > This is now done, sorry for the delay. Let me describe the
> current
> > > > state
> > > > > > of the world:
> > > > > >
> > > > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > > > CURATOR-3.0-temp - these are the old versions of all the
> branches,
> > we
> > > > > > should consider pruning them at some point.
> > > > > >
> > > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > > > versions
> > > > > of
> > > > > > the branches we should stick with.
> > > > > >
> > > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> > > nothing
> > > > > > that has been committed to master that isn't in 3.0 now.
> > > > > >
> > > > > > Procedures going forward:
> > > > > >
> > > > > > - If you're working on stuff for 2.8 / 2.9, branch from master
> and
> > > > > > merge/commit to master.
> > > > > >
> > > > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > > > > merge/commit to CURATOR-3.0.
> > > > > >
> > > > > > - Periodically, we'll want to get master changes into 3.0. To do
> > > this,
> > > > > *check
> > > > > > out CURATOR-3.0*, and merge master into that, then push the
> result
> > > > after
> > > > > > fixing conflicts (which should be small / non-existent). *Don't
> do
> > > it
> > > > > the
> > > > > > other way, don't check out master and merge 3.0 into it.*
> > > > > >
> > > > > > For discussion: there is a *3.0-rejects* branch. One of the
> > commits
> > > > > there
> > > > > > is and added System.out.println that I think we don't want. The
> > > other
> > > > > one
> > > > > > is the work to migrate to fasterxml Jackson. I think we actually
> > > want
> > > > > this
> > > > > > commit on 3.0. Please take a look and let me know, if we want
> this
> > > > > commit,
> > > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > > >
> > > > > > Everything I did should be reversible, so let me know if I
> screwed
> > > > > anything
> > > > > > up!
> > > > > >
> > > > > > --Scott
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
One quick thing... both of those JIRAs are marked for 3.0. Are you sure
you want to merge that branch into master? I think you want to merge it
into CURATOR-3.0.
On Mon, Aug 17, 2015 at 9:09 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> I think it's just because the GetConfigBuilderImpl wasn't present in the
> CURATOR-217 branch, so it didn't get updated along with the other changes
> that Jordan made when the interface into the Watching class changed.
>
> On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <dr...@gmail.com>
> wrote:
>
> > Let me take a look... it's possible your branch needed to be rebased
> prior
> > to merging.
> > Gimme 30 minutes.
> >
> > On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > Thanks Scott,
> > > I've just merged CURATOR-217 into master and have one small issue.
> > >
> > > Jordan, with the changes you made with to the Watching.java class, the
> > > getWatcher() call now takes a CuratorFramework reference and a path
> > > reference.
> > >
> > > The GetConfigBuilderImpl breaks when merging because it's using the old
> > > getWatcher() call that doesn't exist any more. This isn't an issue to
> > fix,
> > > but I'm just wondering what path reference should be used for the
> > > configuration case, as it's a different sort of watch. It's just passed
> > to
> > > the getConfig() call on the ZooKeeper class. It seems that I can't just
> > > pass in a null path as this gets validated. Suggestions?
> > >
> > > cheers
> > >
> > >
> > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > jordan@jordanzimmerman.com> wrote:
> > >
> > > > Great work. Thank you.
> > > >
> > > > ====================
> > > > Jordan Zimmerman
> > > >
> > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > > > >
> > > > > This is now done, sorry for the delay. Let me describe the current
> > > state
> > > > > of the world:
> > > > >
> > > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > > CURATOR-3.0-temp - these are the old versions of all the branches,
> we
> > > > > should consider pruning them at some point.
> > > > >
> > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > > versions
> > > > of
> > > > > the branches we should stick with.
> > > > >
> > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> > nothing
> > > > > that has been committed to master that isn't in 3.0 now.
> > > > >
> > > > > Procedures going forward:
> > > > >
> > > > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > > > merge/commit to master.
> > > > >
> > > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > > > merge/commit to CURATOR-3.0.
> > > > >
> > > > > - Periodically, we'll want to get master changes into 3.0. To do
> > this,
> > > > *check
> > > > > out CURATOR-3.0*, and merge master into that, then push the result
> > > after
> > > > > fixing conflicts (which should be small / non-existent). *Don't do
> > it
> > > > the
> > > > > other way, don't check out master and merge 3.0 into it.*
> > > > >
> > > > > For discussion: there is a *3.0-rejects* branch. One of the
> commits
> > > > there
> > > > > is and added System.out.println that I think we don't want. The
> > other
> > > > one
> > > > > is the work to migrate to fasterxml Jackson. I think we actually
> > want
> > > > this
> > > > > commit on 3.0. Please take a look and let me know, if we want this
> > > > commit,
> > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > >
> > > > > Everything I did should be reversible, so let me know if I screwed
> > > > anything
> > > > > up!
> > > > >
> > > > > --Scott
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
I think it's just because the GetConfigBuilderImpl wasn't present in the
CURATOR-217 branch, so it didn't get updated along with the other changes
that Jordan made when the interface into the Watching class changed.
On Tue, Aug 18, 2015 at 11:08 AM, Scott Blum <dr...@gmail.com> wrote:
> Let me take a look... it's possible your branch needed to be rebased prior
> to merging.
> Gimme 30 minutes.
>
> On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Thanks Scott,
> > I've just merged CURATOR-217 into master and have one small issue.
> >
> > Jordan, with the changes you made with to the Watching.java class, the
> > getWatcher() call now takes a CuratorFramework reference and a path
> > reference.
> >
> > The GetConfigBuilderImpl breaks when merging because it's using the old
> > getWatcher() call that doesn't exist any more. This isn't an issue to
> fix,
> > but I'm just wondering what path reference should be used for the
> > configuration case, as it's a different sort of watch. It's just passed
> to
> > the getConfig() call on the ZooKeeper class. It seems that I can't just
> > pass in a null path as this gets validated. Suggestions?
> >
> > cheers
> >
> >
> > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> > > Great work. Thank you.
> > >
> > > ====================
> > > Jordan Zimmerman
> > >
> > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> > wrote:
> > > >
> > > > This is now done, sorry for the delay. Let me describe the current
> > state
> > > > of the world:
> > > >
> > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > > > should consider pruning them at some point.
> > > >
> > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > versions
> > > of
> > > > the branches we should stick with.
> > > >
> > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> nothing
> > > > that has been committed to master that isn't in 3.0 now.
> > > >
> > > > Procedures going forward:
> > > >
> > > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > > merge/commit to master.
> > > >
> > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > > merge/commit to CURATOR-3.0.
> > > >
> > > > - Periodically, we'll want to get master changes into 3.0. To do
> this,
> > > *check
> > > > out CURATOR-3.0*, and merge master into that, then push the result
> > after
> > > > fixing conflicts (which should be small / non-existent). *Don't do
> it
> > > the
> > > > other way, don't check out master and merge 3.0 into it.*
> > > >
> > > > For discussion: there is a *3.0-rejects* branch. One of the commits
> > > there
> > > > is and added System.out.println that I think we don't want. The
> other
> > > one
> > > > is the work to migrate to fasterxml Jackson. I think we actually
> want
> > > this
> > > > commit on 3.0. Please take a look and let me know, if we want this
> > > commit,
> > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > >
> > > > Everything I did should be reversible, so let me know if I screwed
> > > anything
> > > > up!
> > > >
> > > > --Scott
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
Let me take a look... it's possible your branch needed to be rebased prior
to merging.
Gimme 30 minutes.
On Mon, Aug 17, 2015 at 7:18 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Scott,
> I've just merged CURATOR-217 into master and have one small issue.
>
> Jordan, with the changes you made with to the Watching.java class, the
> getWatcher() call now takes a CuratorFramework reference and a path
> reference.
>
> The GetConfigBuilderImpl breaks when merging because it's using the old
> getWatcher() call that doesn't exist any more. This isn't an issue to fix,
> but I'm just wondering what path reference should be used for the
> configuration case, as it's a different sort of watch. It's just passed to
> the getConfig() call on the ZooKeeper class. It seems that I can't just
> pass in a null path as this gets validated. Suggestions?
>
> cheers
>
>
> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Great work. Thank you.
> >
> > ====================
> > Jordan Zimmerman
> >
> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> wrote:
> > >
> > > This is now done, sorry for the delay. Let me describe the current
> state
> > > of the world:
> > >
> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > > should consider pruning them at some point.
> > >
> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> versions
> > of
> > > the branches we should stick with.
> > >
> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> > > that has been committed to master that isn't in 3.0 now.
> > >
> > > Procedures going forward:
> > >
> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > merge/commit to master.
> > >
> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > merge/commit to CURATOR-3.0.
> > >
> > > - Periodically, we'll want to get master changes into 3.0. To do this,
> > *check
> > > out CURATOR-3.0*, and merge master into that, then push the result
> after
> > > fixing conflicts (which should be small / non-existent). *Don't do it
> > the
> > > other way, don't check out master and merge 3.0 into it.*
> > >
> > > For discussion: there is a *3.0-rejects* branch. One of the commits
> > there
> > > is and added System.out.println that I think we don't want. The other
> > one
> > > is the work to migrate to fasterxml Jackson. I think we actually want
> > this
> > > commit on 3.0. Please take a look and let me know, if we want this
> > commit,
> > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > >
> > > Everything I did should be reversible, so let me know if I screwed
> > anything
> > > up!
> > >
> > > --Scott
> >
>
Re: Next Steps
Posted by Mike Drob <md...@apache.org>.
https://builds.apache.org/job/Curator-3.0/
On Fri, Aug 21, 2015 at 12:54 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Good idea. You should have perms to create it. If not, let me know.
>
>
>
> On August 21, 2015 at 12:53:39 PM, Mike Drob (mdrob@apache.org) wrote:
>
> Is there a curator-3.0 jenkins job?
>
> On Wed, Aug 19, 2015 at 4:47 PM, Cameron McKenzie <mc...@gmail.com>
>
> wrote:
>
> > Nope, all sorted.
> > Thanks.
> >
> > On Thu, Aug 20, 2015 at 6:29 AM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> > > Resending - is there something I need to do on watchers?
> > >
> > > -Jordan
> > >
> > >
> > >
> > > On August 17, 2015 at 10:19:48 PM, Jordan Zimmerman (
> > > jordan@jordanzimmerman.com) wrote:
> > >
> > > Sorry - it’s hard to follow this thread. What do I need to do?
> > >
> > > -Jordan
> > >
> > >
> > >
> > > On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
> > mckenzie.cam@gmail.com)
> > > wrote:
> > >
> > > Thanks Scott,
> > > I've just merged CURATOR-217 into master and have one small issue.
> > >
> > > Jordan, with the changes you made with to the Watching.java class, the
> > > getWatcher() call now takes a CuratorFramework reference and a path
> > > reference.
> > >
> > > The GetConfigBuilderImpl breaks when merging because it's using the
> old
> > > getWatcher() call that doesn't exist any more. This isn't an issue to
> > fix,
> > > but I'm just wondering what path reference should be used for the
> > > configuration case, as it's a different sort of watch. It's just
> passed
> > to
> > > the getConfig() call on the ZooKeeper class. It seems that I can't
> just
> > > pass in a null path as this gets validated. Suggestions?
> > >
> > > cheers
> > >
> > >
> > > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > > jordan@jordanzimmerman.com> wrote:
> > >
> > > > Great work. Thank you.
> > > >
> > > > ====================
> > > > Jordan Zimmerman
> > > >
> > > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > > > >
> > > > > This is now done, sorry for the delay. Let me describe the current
> > > state
> > > > > of the world:
> > > > >
> > > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > > CURATOR-3.0-temp - these are the old versions of all the branches,
> we
> > > > > should consider pruning them at some point.
> > > > >
> > > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > > versions
> > > > of
> > > > > the branches we should stick with.
> > > > >
> > > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> > nothing
> > > > > that has been committed to master that isn't in 3.0 now.
> > > > >
> > > > > Procedures going forward:
> > > > >
> > > > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > > > merge/commit to master.
> > > > >
> > > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > > > merge/commit to CURATOR-3.0.
> > > > >
> > > > > - Periodically, we'll want to get master changes into 3.0. To do
> > this,
> > > > *check
> > > > > out CURATOR-3.0*, and merge master into that, then push the result
> > > after
> > > > > fixing conflicts (which should be small / non-existent). *Don't do
> it
> > > > the
> > > > > other way, don't check out master and merge 3.0 into it.*
> > > > >
> > > > > For discussion: there is a *3.0-rejects* branch. One of the
> commits
> > > > there
> > > > > is and added System.out.println that I think we don't want. The
> other
> > > > one
> > > > > is the work to migrate to fasterxml Jackson. I think we actually
> want
> > > > this
> > > > > commit on 3.0. Please take a look and let me know, if we want this
> > > > commit,
> > > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > > >
> > > > > Everything I did should be reversible, so let me know if I screwed
> > > > anything
> > > > > up!
> > > > >
> > > > > --Scott
> > > >
> > >
> > >
> >
>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Good idea. You should have perms to create it. If not, let me know.
On August 21, 2015 at 12:53:39 PM, Mike Drob (mdrob@apache.org) wrote:
Is there a curator-3.0 jenkins job?
On Wed, Aug 19, 2015 at 4:47 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Nope, all sorted.
> Thanks.
>
> On Thu, Aug 20, 2015 at 6:29 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Resending - is there something I need to do on watchers?
> >
> > -Jordan
> >
> >
> >
> > On August 17, 2015 at 10:19:48 PM, Jordan Zimmerman (
> > jordan@jordanzimmerman.com) wrote:
> >
> > Sorry - it’s hard to follow this thread. What do I need to do?
> >
> > -Jordan
> >
> >
> >
> > On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
> mckenzie.cam@gmail.com)
> > wrote:
> >
> > Thanks Scott,
> > I've just merged CURATOR-217 into master and have one small issue.
> >
> > Jordan, with the changes you made with to the Watching.java class, the
> > getWatcher() call now takes a CuratorFramework reference and a path
> > reference.
> >
> > The GetConfigBuilderImpl breaks when merging because it's using the old
> > getWatcher() call that doesn't exist any more. This isn't an issue to
> fix,
> > but I'm just wondering what path reference should be used for the
> > configuration case, as it's a different sort of watch. It's just passed
> to
> > the getConfig() call on the ZooKeeper class. It seems that I can't just
> > pass in a null path as this gets validated. Suggestions?
> >
> > cheers
> >
> >
> > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> > > Great work. Thank you.
> > >
> > > ====================
> > > Jordan Zimmerman
> > >
> > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> > wrote:
> > > >
> > > > This is now done, sorry for the delay. Let me describe the current
> > state
> > > > of the world:
> > > >
> > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > > > should consider pruning them at some point.
> > > >
> > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > versions
> > > of
> > > > the branches we should stick with.
> > > >
> > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> nothing
> > > > that has been committed to master that isn't in 3.0 now.
> > > >
> > > > Procedures going forward:
> > > >
> > > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > > merge/commit to master.
> > > >
> > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > > merge/commit to CURATOR-3.0.
> > > >
> > > > - Periodically, we'll want to get master changes into 3.0. To do
> this,
> > > *check
> > > > out CURATOR-3.0*, and merge master into that, then push the result
> > after
> > > > fixing conflicts (which should be small / non-existent). *Don't do it
> > > the
> > > > other way, don't check out master and merge 3.0 into it.*
> > > >
> > > > For discussion: there is a *3.0-rejects* branch. One of the commits
> > > there
> > > > is and added System.out.println that I think we don't want. The other
> > > one
> > > > is the work to migrate to fasterxml Jackson. I think we actually want
> > > this
> > > > commit on 3.0. Please take a look and let me know, if we want this
> > > commit,
> > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > >
> > > > Everything I did should be reversible, so let me know if I screwed
> > > anything
> > > > up!
> > > >
> > > > --Scott
> > >
> >
> >
>
Re: Next Steps
Posted by Mike Drob <md...@apache.org>.
Is there a curator-3.0 jenkins job?
On Wed, Aug 19, 2015 at 4:47 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Nope, all sorted.
> Thanks.
>
> On Thu, Aug 20, 2015 at 6:29 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Resending - is there something I need to do on watchers?
> >
> > -Jordan
> >
> >
> >
> > On August 17, 2015 at 10:19:48 PM, Jordan Zimmerman (
> > jordan@jordanzimmerman.com) wrote:
> >
> > Sorry - it’s hard to follow this thread. What do I need to do?
> >
> > -Jordan
> >
> >
> >
> > On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
> mckenzie.cam@gmail.com)
> > wrote:
> >
> > Thanks Scott,
> > I've just merged CURATOR-217 into master and have one small issue.
> >
> > Jordan, with the changes you made with to the Watching.java class, the
> > getWatcher() call now takes a CuratorFramework reference and a path
> > reference.
> >
> > The GetConfigBuilderImpl breaks when merging because it's using the old
> > getWatcher() call that doesn't exist any more. This isn't an issue to
> fix,
> > but I'm just wondering what path reference should be used for the
> > configuration case, as it's a different sort of watch. It's just passed
> to
> > the getConfig() call on the ZooKeeper class. It seems that I can't just
> > pass in a null path as this gets validated. Suggestions?
> >
> > cheers
> >
> >
> > On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> > > Great work. Thank you.
> > >
> > > ====================
> > > Jordan Zimmerman
> > >
> > > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> > wrote:
> > > >
> > > > This is now done, sorry for the delay. Let me describe the current
> > state
> > > > of the world:
> > > >
> > > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > > > should consider pruning them at some point.
> > > >
> > > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> > versions
> > > of
> > > > the branches we should stick with.
> > > >
> > > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
> nothing
> > > > that has been committed to master that isn't in 3.0 now.
> > > >
> > > > Procedures going forward:
> > > >
> > > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > > merge/commit to master.
> > > >
> > > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > > merge/commit to CURATOR-3.0.
> > > >
> > > > - Periodically, we'll want to get master changes into 3.0. To do
> this,
> > > *check
> > > > out CURATOR-3.0*, and merge master into that, then push the result
> > after
> > > > fixing conflicts (which should be small / non-existent). *Don't do it
> > > the
> > > > other way, don't check out master and merge 3.0 into it.*
> > > >
> > > > For discussion: there is a *3.0-rejects* branch. One of the commits
> > > there
> > > > is and added System.out.println that I think we don't want. The other
> > > one
> > > > is the work to migrate to fasterxml Jackson. I think we actually want
> > > this
> > > > commit on 3.0. Please take a look and let me know, if we want this
> > > commit,
> > > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > > >
> > > > Everything I did should be reversible, so let me know if I screwed
> > > anything
> > > > up!
> > > >
> > > > --Scott
> > >
> >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Nope, all sorted.
Thanks.
On Thu, Aug 20, 2015 at 6:29 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Resending - is there something I need to do on watchers?
>
> -Jordan
>
>
>
> On August 17, 2015 at 10:19:48 PM, Jordan Zimmerman (
> jordan@jordanzimmerman.com) wrote:
>
> Sorry - it’s hard to follow this thread. What do I need to do?
>
> -Jordan
>
>
>
> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (mckenzie.cam@gmail.com)
> wrote:
>
> Thanks Scott,
> I've just merged CURATOR-217 into master and have one small issue.
>
> Jordan, with the changes you made with to the Watching.java class, the
> getWatcher() call now takes a CuratorFramework reference and a path
> reference.
>
> The GetConfigBuilderImpl breaks when merging because it's using the old
> getWatcher() call that doesn't exist any more. This isn't an issue to fix,
> but I'm just wondering what path reference should be used for the
> configuration case, as it's a different sort of watch. It's just passed to
> the getConfig() call on the ZooKeeper class. It seems that I can't just
> pass in a null path as this gets validated. Suggestions?
>
> cheers
>
>
> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Great work. Thank you.
> >
> > ====================
> > Jordan Zimmerman
> >
> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> wrote:
> > >
> > > This is now done, sorry for the delay. Let me describe the current
> state
> > > of the world:
> > >
> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > > should consider pruning them at some point.
> > >
> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> versions
> > of
> > > the branches we should stick with.
> > >
> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> > > that has been committed to master that isn't in 3.0 now.
> > >
> > > Procedures going forward:
> > >
> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > merge/commit to master.
> > >
> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > merge/commit to CURATOR-3.0.
> > >
> > > - Periodically, we'll want to get master changes into 3.0. To do this,
> > *check
> > > out CURATOR-3.0*, and merge master into that, then push the result
> after
> > > fixing conflicts (which should be small / non-existent). *Don't do it
> > the
> > > other way, don't check out master and merge 3.0 into it.*
> > >
> > > For discussion: there is a *3.0-rejects* branch. One of the commits
> > there
> > > is and added System.out.println that I think we don't want. The other
> > one
> > > is the work to migrate to fasterxml Jackson. I think we actually want
> > this
> > > commit on 3.0. Please take a look and let me know, if we want this
> > commit,
> > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > >
> > > Everything I did should be reversible, so let me know if I screwed
> > anything
> > > up!
> > >
> > > --Scott
> >
>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Resending - is there something I need to do on watchers?
-Jordan
On August 17, 2015 at 10:19:48 PM, Jordan Zimmerman (jordan@jordanzimmerman.com) wrote:
Sorry - it’s hard to follow this thread. What do I need to do?
-Jordan
On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
Thanks Scott,
I've just merged CURATOR-217 into master and have one small issue.
Jordan, with the changes you made with to the Watching.java class, the
getWatcher() call now takes a CuratorFramework reference and a path
reference.
The GetConfigBuilderImpl breaks when merging because it's using the old
getWatcher() call that doesn't exist any more. This isn't an issue to fix,
but I'm just wondering what path reference should be used for the
configuration case, as it's a different sort of watch. It's just passed to
the getConfig() call on the ZooKeeper class. It seems that I can't just
pass in a null path as this gets validated. Suggestions?
cheers
On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Great work. Thank you.
>
> ====================
> Jordan Zimmerman
>
> > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com> wrote:
> >
> > This is now done, sorry for the delay. Let me describe the current state
> > of the world:
> >
> > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > should consider pruning them at some point.
> >
> > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased versions
> of
> > the branches we should stick with.
> >
> > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> > that has been committed to master that isn't in 3.0 now.
> >
> > Procedures going forward:
> >
> > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > merge/commit to master.
> >
> > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > merge/commit to CURATOR-3.0.
> >
> > - Periodically, we'll want to get master changes into 3.0. To do this,
> *check
> > out CURATOR-3.0*, and merge master into that, then push the result after
> > fixing conflicts (which should be small / non-existent). *Don't do it
> the
> > other way, don't check out master and merge 3.0 into it.*
> >
> > For discussion: there is a *3.0-rejects* branch. One of the commits
> there
> > is and added System.out.println that I think we don't want. The other
> one
> > is the work to migrate to fasterxml Jackson. I think we actually want
> this
> > commit on 3.0. Please take a look and let me know, if we want this
> commit,
> > we should cherry-pick it onto 3.0. I'm happy to do that.
> >
> > Everything I did should be reversible, so let me know if I screwed
> anything
> > up!
> >
> > --Scott
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
That seems to have fixed the namespace issues. There are still 2 tests
failing, but these are the ones that Mike has raised JIRA tickets for
already, so nothing additional is broken by the 3.0 changes. I will merge
into 3.0 now.
cheers
On Wed, Aug 19, 2015 at 8:22 AM, Cameron McKenzie <mc...@gmail.com>
wrote:
> So, it seems that this is an issue with the WatcherNamespaceRemovalFacade.
> It doesn't override
>
> String fixForNamespace(String path, boolean isSequential)
>
> which means that instead of using the wrapped CuratorFramework namespace,
> it uses its own instance (which is null), meaning that the namespace fix
> doesn't work.
>
> I think that this version of the fixForNamespace is a new method on the
> CuratorFramework since the CURATOR-217 branch was made.
>
> Anyway, I have fixed it up and it seems to have fixed things. I'll rerun
> all the tests and make sure nothing else is broken then I'll push the
> changes.
> cheers
>
> On Tue, Aug 18, 2015 at 1:42 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
>> Seems like a bunch of tests are failing:
>>
>>
>> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMultiMutex)
>>
>> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMutex)
>>
>> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreMutex)
>> testLockACLs(org.apache.curator.framework.recipes.locks.TestLockACLs)
>>
>> testSimulationWithLocksNamespace(org.apache.curator.framework.recipes.locks.TestReaper)
>>
>> Tests are still running, and I haven't look into them yet, but it would
>> seem based on the test names that something is broken with namespace stuff.
>> Will have a look when I get a minute.
>> cheers
>>
>>
>> On Tue, Aug 18, 2015 at 1:38 PM, Scott Blum <dr...@gmail.com>
>> wrote:
>>
>>> Cool. You should be able to just push a fix and then fast-foward
>>> CURATOR-3.0.
>>>
>>> On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <
>>> mckenzie.cam@gmail.com> wrote:
>>>
>>>> I think it's all good. I've fixed up the couple of build issues on the
>>>> 217-merged branch. Just running the unit tests. If everything's ok then
>>>> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable
>>>> state, and I can start on CURATOR-214.
>>>>
>>>> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dr...@gmail.com>
>>>> wrote:
>>>>
>>>>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher
>>>>> path for getConfig()?
>>>>>
>>>>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>
>>>>>> Sorry - it’s hard to follow this thread. What do I need to do?
>>>>>>
>>>>>> -Jordan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
>>>>>> mckenzie.cam@gmail.com) wrote:
>>>>>>
>>>>>> Thanks Scott,
>>>>>> I've just merged CURATOR-217 into master and have one small issue.
>>>>>>
>>>>>> Jordan, with the changes you made with to the Watching.java class, the
>>>>>> getWatcher() call now takes a CuratorFramework reference and a path
>>>>>> reference.
>>>>>>
>>>>>> The GetConfigBuilderImpl breaks when merging because it's using the
>>>>>> old
>>>>>> getWatcher() call that doesn't exist any more. This isn't an issue to
>>>>>> fix,
>>>>>> but I'm just wondering what path reference should be used for the
>>>>>> configuration case, as it's a different sort of watch. It's just
>>>>>> passed to
>>>>>> the getConfig() call on the ZooKeeper class. It seems that I can't
>>>>>> just
>>>>>> pass in a null path as this gets validated. Suggestions?
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
>>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>>
>>>>>> > Great work. Thank you.
>>>>>> >
>>>>>> > ====================
>>>>>> > Jordan Zimmerman
>>>>>> >
>>>>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
>>>>>> wrote:
>>>>>> > >
>>>>>> > > This is now done, sorry for the delay. Let me describe the
>>>>>> current state
>>>>>> > > of the world:
>>>>>> > >
>>>>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
>>>>>> > > CURATOR-3.0-temp - these are the old versions of all the
>>>>>> branches, we
>>>>>> > > should consider pruning them at some point.
>>>>>> > >
>>>>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
>>>>>> versions
>>>>>> > of
>>>>>> > > the branches we should stick with.
>>>>>> > >
>>>>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
>>>>>> nothing
>>>>>> > > that has been committed to master that isn't in 3.0 now.
>>>>>> > >
>>>>>> > > Procedures going forward:
>>>>>> > >
>>>>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
>>>>>> > > merge/commit to master.
>>>>>> > >
>>>>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
>>>>>> > > merge/commit to CURATOR-3.0.
>>>>>> > >
>>>>>> > > - Periodically, we'll want to get master changes into 3.0. To do
>>>>>> this,
>>>>>> > *check
>>>>>> > > out CURATOR-3.0*, and merge master into that, then push the
>>>>>> result after
>>>>>> > > fixing conflicts (which should be small / non-existent). *Don't
>>>>>> do it
>>>>>> > the
>>>>>> > > other way, don't check out master and merge 3.0 into it.*
>>>>>> > >
>>>>>> > > For discussion: there is a *3.0-rejects* branch. One of the
>>>>>> commits
>>>>>> > there
>>>>>> > > is and added System.out.println that I think we don't want. The
>>>>>> other
>>>>>> > one
>>>>>> > > is the work to migrate to fasterxml Jackson. I think we actually
>>>>>> want
>>>>>> > this
>>>>>> > > commit on 3.0. Please take a look and let me know, if we want this
>>>>>> > commit,
>>>>>> > > we should cherry-pick it onto 3.0. I'm happy to do that.
>>>>>> > >
>>>>>> > > Everything I did should be reversible, so let me know if I screwed
>>>>>> > anything
>>>>>> > > up!
>>>>>> > >
>>>>>> > > --Scott
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
So, it seems that this is an issue with the WatcherNamespaceRemovalFacade.
It doesn't override
String fixForNamespace(String path, boolean isSequential)
which means that instead of using the wrapped CuratorFramework namespace,
it uses its own instance (which is null), meaning that the namespace fix
doesn't work.
I think that this version of the fixForNamespace is a new method on the
CuratorFramework since the CURATOR-217 branch was made.
Anyway, I have fixed it up and it seems to have fixed things. I'll rerun
all the tests and make sure nothing else is broken then I'll push the
changes.
cheers
On Tue, Aug 18, 2015 at 1:42 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Seems like a bunch of tests are failing:
>
>
> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMultiMutex)
>
> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMutex)
>
> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreMutex)
> testLockACLs(org.apache.curator.framework.recipes.locks.TestLockACLs)
>
> testSimulationWithLocksNamespace(org.apache.curator.framework.recipes.locks.TestReaper)
>
> Tests are still running, and I haven't look into them yet, but it would
> seem based on the test names that something is broken with namespace stuff.
> Will have a look when I get a minute.
> cheers
>
>
> On Tue, Aug 18, 2015 at 1:38 PM, Scott Blum <dr...@gmail.com> wrote:
>
>> Cool. You should be able to just push a fix and then fast-foward
>> CURATOR-3.0.
>>
>> On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com> wrote:
>>
>>> I think it's all good. I've fixed up the couple of build issues on the
>>> 217-merged branch. Just running the unit tests. If everything's ok then
>>> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable
>>> state, and I can start on CURATOR-214.
>>>
>>> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dr...@gmail.com>
>>> wrote:
>>>
>>>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher
>>>> path for getConfig()?
>>>>
>>>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
>>>> jordan@jordanzimmerman.com> wrote:
>>>>
>>>>> Sorry - it’s hard to follow this thread. What do I need to do?
>>>>>
>>>>> -Jordan
>>>>>
>>>>>
>>>>>
>>>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
>>>>> mckenzie.cam@gmail.com) wrote:
>>>>>
>>>>> Thanks Scott,
>>>>> I've just merged CURATOR-217 into master and have one small issue.
>>>>>
>>>>> Jordan, with the changes you made with to the Watching.java class, the
>>>>> getWatcher() call now takes a CuratorFramework reference and a path
>>>>> reference.
>>>>>
>>>>> The GetConfigBuilderImpl breaks when merging because it's using the old
>>>>> getWatcher() call that doesn't exist any more. This isn't an issue to
>>>>> fix,
>>>>> but I'm just wondering what path reference should be used for the
>>>>> configuration case, as it's a different sort of watch. It's just
>>>>> passed to
>>>>> the getConfig() call on the ZooKeeper class. It seems that I can't just
>>>>> pass in a null path as this gets validated. Suggestions?
>>>>>
>>>>> cheers
>>>>>
>>>>>
>>>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>
>>>>> > Great work. Thank you.
>>>>> >
>>>>> > ====================
>>>>> > Jordan Zimmerman
>>>>> >
>>>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
>>>>> wrote:
>>>>> > >
>>>>> > > This is now done, sorry for the delay. Let me describe the current
>>>>> state
>>>>> > > of the world:
>>>>> > >
>>>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
>>>>> > > CURATOR-3.0-temp - these are the old versions of all the branches,
>>>>> we
>>>>> > > should consider pruning them at some point.
>>>>> > >
>>>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
>>>>> versions
>>>>> > of
>>>>> > > the branches we should stick with.
>>>>> > >
>>>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
>>>>> nothing
>>>>> > > that has been committed to master that isn't in 3.0 now.
>>>>> > >
>>>>> > > Procedures going forward:
>>>>> > >
>>>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
>>>>> > > merge/commit to master.
>>>>> > >
>>>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
>>>>> > > merge/commit to CURATOR-3.0.
>>>>> > >
>>>>> > > - Periodically, we'll want to get master changes into 3.0. To do
>>>>> this,
>>>>> > *check
>>>>> > > out CURATOR-3.0*, and merge master into that, then push the result
>>>>> after
>>>>> > > fixing conflicts (which should be small / non-existent). *Don't do
>>>>> it
>>>>> > the
>>>>> > > other way, don't check out master and merge 3.0 into it.*
>>>>> > >
>>>>> > > For discussion: there is a *3.0-rejects* branch. One of the commits
>>>>> > there
>>>>> > > is and added System.out.println that I think we don't want. The
>>>>> other
>>>>> > one
>>>>> > > is the work to migrate to fasterxml Jackson. I think we actually
>>>>> want
>>>>> > this
>>>>> > > commit on 3.0. Please take a look and let me know, if we want this
>>>>> > commit,
>>>>> > > we should cherry-pick it onto 3.0. I'm happy to do that.
>>>>> > >
>>>>> > > Everything I did should be reversible, so let me know if I screwed
>>>>> > anything
>>>>> > > up!
>>>>> > >
>>>>> > > --Scott
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Seems like a bunch of tests are failing:
testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMultiMutex)
testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMutex)
testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreMutex)
testLockACLs(org.apache.curator.framework.recipes.locks.TestLockACLs)
testSimulationWithLocksNamespace(org.apache.curator.framework.recipes.locks.TestReaper)
Tests are still running, and I haven't look into them yet, but it would
seem based on the test names that something is broken with namespace stuff.
Will have a look when I get a minute.
cheers
On Tue, Aug 18, 2015 at 1:38 PM, Scott Blum <dr...@gmail.com> wrote:
> Cool. You should be able to just push a fix and then fast-foward
> CURATOR-3.0.
>
> On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <mckenzie.cam@gmail.com
> > wrote:
>
>> I think it's all good. I've fixed up the couple of build issues on the
>> 217-merged branch. Just running the unit tests. If everything's ok then
>> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable
>> state, and I can start on CURATOR-214.
>>
>> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dr...@gmail.com>
>> wrote:
>>
>>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher
>>> path for getConfig()?
>>>
>>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
>>> jordan@jordanzimmerman.com> wrote:
>>>
>>>> Sorry - it’s hard to follow this thread. What do I need to do?
>>>>
>>>> -Jordan
>>>>
>>>>
>>>>
>>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
>>>> mckenzie.cam@gmail.com) wrote:
>>>>
>>>> Thanks Scott,
>>>> I've just merged CURATOR-217 into master and have one small issue.
>>>>
>>>> Jordan, with the changes you made with to the Watching.java class, the
>>>> getWatcher() call now takes a CuratorFramework reference and a path
>>>> reference.
>>>>
>>>> The GetConfigBuilderImpl breaks when merging because it's using the old
>>>> getWatcher() call that doesn't exist any more. This isn't an issue to
>>>> fix,
>>>> but I'm just wondering what path reference should be used for the
>>>> configuration case, as it's a different sort of watch. It's just passed
>>>> to
>>>> the getConfig() call on the ZooKeeper class. It seems that I can't just
>>>> pass in a null path as this gets validated. Suggestions?
>>>>
>>>> cheers
>>>>
>>>>
>>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
>>>> jordan@jordanzimmerman.com> wrote:
>>>>
>>>> > Great work. Thank you.
>>>> >
>>>> > ====================
>>>> > Jordan Zimmerman
>>>> >
>>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
>>>> wrote:
>>>> > >
>>>> > > This is now done, sorry for the delay. Let me describe the current
>>>> state
>>>> > > of the world:
>>>> > >
>>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
>>>> > > CURATOR-3.0-temp - these are the old versions of all the branches,
>>>> we
>>>> > > should consider pruning them at some point.
>>>> > >
>>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
>>>> versions
>>>> > of
>>>> > > the branches we should stick with.
>>>> > >
>>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
>>>> nothing
>>>> > > that has been committed to master that isn't in 3.0 now.
>>>> > >
>>>> > > Procedures going forward:
>>>> > >
>>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
>>>> > > merge/commit to master.
>>>> > >
>>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
>>>> > > merge/commit to CURATOR-3.0.
>>>> > >
>>>> > > - Periodically, we'll want to get master changes into 3.0. To do
>>>> this,
>>>> > *check
>>>> > > out CURATOR-3.0*, and merge master into that, then push the result
>>>> after
>>>> > > fixing conflicts (which should be small / non-existent). *Don't do
>>>> it
>>>> > the
>>>> > > other way, don't check out master and merge 3.0 into it.*
>>>> > >
>>>> > > For discussion: there is a *3.0-rejects* branch. One of the commits
>>>> > there
>>>> > > is and added System.out.println that I think we don't want. The
>>>> other
>>>> > one
>>>> > > is the work to migrate to fasterxml Jackson. I think we actually
>>>> want
>>>> > this
>>>> > > commit on 3.0. Please take a look and let me know, if we want this
>>>> > commit,
>>>> > > we should cherry-pick it onto 3.0. I'm happy to do that.
>>>> > >
>>>> > > Everything I did should be reversible, so let me know if I screwed
>>>> > anything
>>>> > > up!
>>>> > >
>>>> > > --Scott
>>>> >
>>>>
>>>
>>>
>>
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
Cool. You should be able to just push a fix and then fast-foward
CURATOR-3.0.
On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> I think it's all good. I've fixed up the couple of build issues on the
> 217-merged branch. Just running the unit tests. If everything's ok then
> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable
> state, and I can start on CURATOR-214.
>
> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dr...@gmail.com> wrote:
>
>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher path
>> for getConfig()?
>>
>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> Sorry - it’s hard to follow this thread. What do I need to do?
>>>
>>> -Jordan
>>>
>>>
>>>
>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
>>> mckenzie.cam@gmail.com) wrote:
>>>
>>> Thanks Scott,
>>> I've just merged CURATOR-217 into master and have one small issue.
>>>
>>> Jordan, with the changes you made with to the Watching.java class, the
>>> getWatcher() call now takes a CuratorFramework reference and a path
>>> reference.
>>>
>>> The GetConfigBuilderImpl breaks when merging because it's using the old
>>> getWatcher() call that doesn't exist any more. This isn't an issue to
>>> fix,
>>> but I'm just wondering what path reference should be used for the
>>> configuration case, as it's a different sort of watch. It's just passed
>>> to
>>> the getConfig() call on the ZooKeeper class. It seems that I can't just
>>> pass in a null path as this gets validated. Suggestions?
>>>
>>> cheers
>>>
>>>
>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
>>> jordan@jordanzimmerman.com> wrote:
>>>
>>> > Great work. Thank you.
>>> >
>>> > ====================
>>> > Jordan Zimmerman
>>> >
>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
>>> wrote:
>>> > >
>>> > > This is now done, sorry for the delay. Let me describe the current
>>> state
>>> > > of the world:
>>> > >
>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
>>> > > CURATOR-3.0-temp - these are the old versions of all the branches, we
>>> > > should consider pruning them at some point.
>>> > >
>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
>>> versions
>>> > of
>>> > > the branches we should stick with.
>>> > >
>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is
>>> nothing
>>> > > that has been committed to master that isn't in 3.0 now.
>>> > >
>>> > > Procedures going forward:
>>> > >
>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
>>> > > merge/commit to master.
>>> > >
>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
>>> > > merge/commit to CURATOR-3.0.
>>> > >
>>> > > - Periodically, we'll want to get master changes into 3.0. To do
>>> this,
>>> > *check
>>> > > out CURATOR-3.0*, and merge master into that, then push the result
>>> after
>>> > > fixing conflicts (which should be small / non-existent). *Don't do it
>>> > the
>>> > > other way, don't check out master and merge 3.0 into it.*
>>> > >
>>> > > For discussion: there is a *3.0-rejects* branch. One of the commits
>>> > there
>>> > > is and added System.out.println that I think we don't want. The other
>>> > one
>>> > > is the work to migrate to fasterxml Jackson. I think we actually want
>>> > this
>>> > > commit on 3.0. Please take a look and let me know, if we want this
>>> > commit,
>>> > > we should cherry-pick it onto 3.0. I'm happy to do that.
>>> > >
>>> > > Everything I did should be reversible, so let me know if I screwed
>>> > anything
>>> > > up!
>>> > >
>>> > > --Scott
>>> >
>>>
>>
>>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
I think it's all good. I've fixed up the couple of build issues on the
217-merged branch. Just running the unit tests. If everything's ok then
I'll merge it back into CURATOR-3.0 and then I think we're back in a stable
state, and I can start on CURATOR-214.
On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dr...@gmail.com> wrote:
> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher path
> for getConfig()?
>
> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> Sorry - it’s hard to follow this thread. What do I need to do?
>>
>> -Jordan
>>
>>
>>
>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
>> mckenzie.cam@gmail.com) wrote:
>>
>> Thanks Scott,
>> I've just merged CURATOR-217 into master and have one small issue.
>>
>> Jordan, with the changes you made with to the Watching.java class, the
>> getWatcher() call now takes a CuratorFramework reference and a path
>> reference.
>>
>> The GetConfigBuilderImpl breaks when merging because it's using the old
>> getWatcher() call that doesn't exist any more. This isn't an issue to fix,
>> but I'm just wondering what path reference should be used for the
>> configuration case, as it's a different sort of watch. It's just passed to
>> the getConfig() call on the ZooKeeper class. It seems that I can't just
>> pass in a null path as this gets validated. Suggestions?
>>
>> cheers
>>
>>
>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>> > Great work. Thank you.
>> >
>> > ====================
>> > Jordan Zimmerman
>> >
>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
>> wrote:
>> > >
>> > > This is now done, sorry for the delay. Let me describe the current
>> state
>> > > of the world:
>> > >
>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
>> > > CURATOR-3.0-temp - these are the old versions of all the branches, we
>> > > should consider pruning them at some point.
>> > >
>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
>> versions
>> > of
>> > > the branches we should stick with.
>> > >
>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
>> > > that has been committed to master that isn't in 3.0 now.
>> > >
>> > > Procedures going forward:
>> > >
>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
>> > > merge/commit to master.
>> > >
>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
>> > > merge/commit to CURATOR-3.0.
>> > >
>> > > - Periodically, we'll want to get master changes into 3.0. To do this,
>> > *check
>> > > out CURATOR-3.0*, and merge master into that, then push the result
>> after
>> > > fixing conflicts (which should be small / non-existent). *Don't do it
>> > the
>> > > other way, don't check out master and merge 3.0 into it.*
>> > >
>> > > For discussion: there is a *3.0-rejects* branch. One of the commits
>> > there
>> > > is and added System.out.println that I think we don't want. The other
>> > one
>> > > is the work to migrate to fasterxml Jackson. I think we actually want
>> > this
>> > > commit on 3.0. Please take a look and let me know, if we want this
>> > commit,
>> > > we should cherry-pick it onto 3.0. I'm happy to do that.
>> > >
>> > > Everything I did should be reversible, so let me know if I screwed
>> > anything
>> > > up!
>> > >
>> > > --Scott
>> >
>>
>
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher path
for getConfig()?
On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Sorry - it’s hard to follow this thread. What do I need to do?
>
> -Jordan
>
>
>
> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (mckenzie.cam@gmail.com)
> wrote:
>
> Thanks Scott,
> I've just merged CURATOR-217 into master and have one small issue.
>
> Jordan, with the changes you made with to the Watching.java class, the
> getWatcher() call now takes a CuratorFramework reference and a path
> reference.
>
> The GetConfigBuilderImpl breaks when merging because it's using the old
> getWatcher() call that doesn't exist any more. This isn't an issue to fix,
> but I'm just wondering what path reference should be used for the
> configuration case, as it's a different sort of watch. It's just passed to
> the getConfig() call on the ZooKeeper class. It seems that I can't just
> pass in a null path as this gets validated. Suggestions?
>
> cheers
>
>
> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Great work. Thank you.
> >
> > ====================
> > Jordan Zimmerman
> >
> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com>
> wrote:
> > >
> > > This is now done, sorry for the delay. Let me describe the current
> state
> > > of the world:
> > >
> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > > should consider pruning them at some point.
> > >
> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
> versions
> > of
> > > the branches we should stick with.
> > >
> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> > > that has been committed to master that isn't in 3.0 now.
> > >
> > > Procedures going forward:
> > >
> > > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > > merge/commit to master.
> > >
> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > > merge/commit to CURATOR-3.0.
> > >
> > > - Periodically, we'll want to get master changes into 3.0. To do this,
> > *check
> > > out CURATOR-3.0*, and merge master into that, then push the result
> after
> > > fixing conflicts (which should be small / non-existent). *Don't do it
> > the
> > > other way, don't check out master and merge 3.0 into it.*
> > >
> > > For discussion: there is a *3.0-rejects* branch. One of the commits
> > there
> > > is and added System.out.println that I think we don't want. The other
> > one
> > > is the work to migrate to fasterxml Jackson. I think we actually want
> > this
> > > commit on 3.0. Please take a look and let me know, if we want this
> > commit,
> > > we should cherry-pick it onto 3.0. I'm happy to do that.
> > >
> > > Everything I did should be reversible, so let me know if I screwed
> > anything
> > > up!
> > >
> > > --Scott
> >
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Sorry - it’s hard to follow this thread. What do I need to do?
-Jordan
On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
Thanks Scott,
I've just merged CURATOR-217 into master and have one small issue.
Jordan, with the changes you made with to the Watching.java class, the
getWatcher() call now takes a CuratorFramework reference and a path
reference.
The GetConfigBuilderImpl breaks when merging because it's using the old
getWatcher() call that doesn't exist any more. This isn't an issue to fix,
but I'm just wondering what path reference should be used for the
configuration case, as it's a different sort of watch. It's just passed to
the getConfig() call on the ZooKeeper class. It seems that I can't just
pass in a null path as this gets validated. Suggestions?
cheers
On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Great work. Thank you.
>
> ====================
> Jordan Zimmerman
>
> > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com> wrote:
> >
> > This is now done, sorry for the delay. Let me describe the current state
> > of the world:
> >
> > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > should consider pruning them at some point.
> >
> > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased versions
> of
> > the branches we should stick with.
> >
> > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> > that has been committed to master that isn't in 3.0 now.
> >
> > Procedures going forward:
> >
> > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > merge/commit to master.
> >
> > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > merge/commit to CURATOR-3.0.
> >
> > - Periodically, we'll want to get master changes into 3.0. To do this,
> *check
> > out CURATOR-3.0*, and merge master into that, then push the result after
> > fixing conflicts (which should be small / non-existent). *Don't do it
> the
> > other way, don't check out master and merge 3.0 into it.*
> >
> > For discussion: there is a *3.0-rejects* branch. One of the commits
> there
> > is and added System.out.println that I think we don't want. The other
> one
> > is the work to migrate to fasterxml Jackson. I think we actually want
> this
> > commit on 3.0. Please take a look and let me know, if we want this
> commit,
> > we should cherry-pick it onto 3.0. I'm happy to do that.
> >
> > Everything I did should be reversible, so let me know if I screwed
> anything
> > up!
> >
> > --Scott
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Scott,
I've just merged CURATOR-217 into master and have one small issue.
Jordan, with the changes you made with to the Watching.java class, the
getWatcher() call now takes a CuratorFramework reference and a path
reference.
The GetConfigBuilderImpl breaks when merging because it's using the old
getWatcher() call that doesn't exist any more. This isn't an issue to fix,
but I'm just wondering what path reference should be used for the
configuration case, as it's a different sort of watch. It's just passed to
the getConfig() call on the ZooKeeper class. It seems that I can't just
pass in a null path as this gets validated. Suggestions?
cheers
On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Great work. Thank you.
>
> ====================
> Jordan Zimmerman
>
> > On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com> wrote:
> >
> > This is now done, sorry for the delay. Let me describe the current state
> > of the world:
> >
> > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> > CURATOR-3.0-temp - these are the old versions of all the branches, we
> > should consider pruning them at some point.
> >
> > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased versions
> of
> > the branches we should stick with.
> >
> > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> > that has been committed to master that isn't in 3.0 now.
> >
> > Procedures going forward:
> >
> > - If you're working on stuff for 2.8 / 2.9, branch from master and
> > merge/commit to master.
> >
> > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> > merge/commit to CURATOR-3.0.
> >
> > - Periodically, we'll want to get master changes into 3.0. To do this,
> *check
> > out CURATOR-3.0*, and merge master into that, then push the result after
> > fixing conflicts (which should be small / non-existent). *Don't do it
> the
> > other way, don't check out master and merge 3.0 into it.*
> >
> > For discussion: there is a *3.0-rejects* branch. One of the commits
> there
> > is and added System.out.println that I think we don't want. The other
> one
> > is the work to migrate to fasterxml Jackson. I think we actually want
> this
> > commit on 3.0. Please take a look and let me know, if we want this
> commit,
> > we should cherry-pick it onto 3.0. I'm happy to do that.
> >
> > Everything I did should be reversible, so let me know if I screwed
> anything
> > up!
> >
> > --Scott
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Great work. Thank you.
====================
Jordan Zimmerman
> On Aug 17, 2015, at 12:10 PM, Scott Blum <dr...@gmail.com> wrote:
>
> This is now done, sorry for the delay. Let me describe the current state
> of the world:
>
> CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
> CURATOR-3.0-temp - these are the old versions of all the branches, we
> should consider pruning them at some point.
>
> CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased versions of
> the branches we should stick with.
>
> *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
> that has been committed to master that isn't in 3.0 now.
>
> Procedures going forward:
>
> - If you're working on stuff for 2.8 / 2.9, branch from master and
> merge/commit to master.
>
> - If you're working on stuff for 3.0, branch from CURATOR-3.0 and
> merge/commit to CURATOR-3.0.
>
> - Periodically, we'll want to get master changes into 3.0. To do this, *check
> out CURATOR-3.0*, and merge master into that, then push the result after
> fixing conflicts (which should be small / non-existent). *Don't do it the
> other way, don't check out master and merge 3.0 into it.*
>
> For discussion: there is a *3.0-rejects* branch. One of the commits there
> is and added System.out.println that I think we don't want. The other one
> is the work to migrate to fasterxml Jackson. I think we actually want this
> commit on 3.0. Please take a look and let me know, if we want this commit,
> we should cherry-pick it onto 3.0. I'm happy to do that.
>
> Everything I did should be reversible, so let me know if I screwed anything
> up!
>
> --Scott
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
This is now done, sorry for the delay. Let me describe the current state
of the world:
CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
CURATOR-3.0-temp - these are the old versions of all the branches, we
should consider pruning them at some point.
CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased versions of
the branches we should stick with.
*ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is nothing
that has been committed to master that isn't in 3.0 now.
Procedures going forward:
- If you're working on stuff for 2.8 / 2.9, branch from master and
merge/commit to master.
- If you're working on stuff for 3.0, branch from CURATOR-3.0 and
merge/commit to CURATOR-3.0.
- Periodically, we'll want to get master changes into 3.0. To do this, *check
out CURATOR-3.0*, and merge master into that, then push the result after
fixing conflicts (which should be small / non-existent). *Don't do it the
other way, don't check out master and merge 3.0 into it.*
For discussion: there is a *3.0-rejects* branch. One of the commits there
is and added System.out.println that I think we don't want. The other one
is the work to migrate to fasterxml Jackson. I think we actually want this
commit on 3.0. Please take a look and let me know, if we want this commit,
we should cherry-pick it onto 3.0. I'm happy to do that.
Everything I did should be reversible, so let me know if I screwed anything
up!
--Scott
Re: Next Steps
Posted by Mike Drob <ma...@cloudera.com>.
Is there an easy way to get a list of branches that have not been merged
into the 3.0 branch? That would help make sure that we don't miss anything.
On Sun, Aug 16, 2015 at 5:18 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Scott,
> I'll merge in CURATOR-217 when you're done then get started on CURATOR-214.
> cheers
>
> On Sun, Aug 16, 2015 at 6:48 AM, Scott Blum <dr...@gmail.com> wrote:
>
> > Ok, I'll push those branches later today!
> > On Aug 15, 2015 7:48 AM, "Cameron McKenzie" <mc...@gmail.com>
> > wrote:
> >
> > > Scott,
> > > I've had a look at the CURATOR-3.0 branch and I think that it looks ok.
> > We
> > > still need to merge CURATOR-217 into it (CURATOR-217 already has
> > > CURATOR-161 merged into it as it relies on the new watcher removal
> APIs),
> > > but I don't think that should be too problematic.
> > >
> > > So, I'm happy for you to push the changes. Thanks for sorting this out,
> > > this level of git black magic is beyond me.
> > >
> > > cheers
> > >
> > > On Sat, Aug 15, 2015 at 3:46 PM, Scott Blum <dr...@gmail.com>
> > wrote:
> > >
> > > > Git uses a lot of heuristics, particularly when recomputing and
> > > reapplying
> > > > merges. In this case, there were a lot of cross merges between trunk
> > and
> > > > 3.0, cross merges between the two feature branches, and I think some
> > > > incomplete merges. Basically, it just got into a really complicated
> > > state.
> > > >
> > > > On Fri, Aug 14, 2015 at 7:36 PM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com>
> > > > wrote:
> > > >
> > > > > I agree that committing to 2.x and merging to 3.x is the way to go
> > > based
> > > > on
> > > > > previous experience with managing dual versions.
> > > > >
> > > > > Scott, I'll have a look at your 3.0 branch tonight. Again, excuse
> my
> > > > > ignorance of the darker bits of git, but do we know how the 3.0
> > > branches
> > > > > ended up in this state? I would have thought that if they were
> > branched
> > > > off
> > > > > master at some point, then we should be able to do a merge from
> > master
> > > > into
> > > > > the 3.0 branches and not have to do any cherry picking or other
> such
> > > > > shenanigans.
> > > > > cheers
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Aug 15, 2015 at 5:30 AM, Scott Blum <dragonsinth@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > 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 <ma...@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 <
> > dragonsinth@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.cam@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 <
> > > > dragonsinth@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 <
> > > > > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Cameron said he had trouble with 160. Any ideas?
> > > > > > > > > > >
> > > > > > > > > > > ====================
> > > > > > > > > > > Jordan Zimmerman
> > > > > > > > > > >
> > > > > > > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <
> > > > > dragonsinth@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Any feedback on this?
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <
> > > > > > dragonsinth@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 <
> > > > > > > dragonsinth@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 <
> > > > > > > > > > >>> jordan@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 (
> > > > > > > > dragonsinth@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 <
> > > > > > > > dragonsinth@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
> <
> > > > > > > > > > >>>>> jordan@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 (
> > > > > > > > > > dragonsinth@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.cam@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 <
> > > > > > > > > > >>>>>>> jordan@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.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 <
> > > > > > > > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > > > > > > > >>>>>>> > wrote:
> > > > > > > > > > >>>>>>> >
> > > > > > > > > > >>>>>>> >> Sure thing.
> > > > > > > > > > >>>>>>> >>
> > > > > > > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan
> > Zimmerman
> > > <
> > > > > > > > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > > > > > > > >>>>>>> >>
> > > > > > > > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > > > > > > > to
> > > > > > > > > > >>>>>>> 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
> > > > > > > > > > related
> > > > > > > > > > >>>>>>> >>>> branches?
> > > > > > > > > > >>>>>>> >>>>
> > > > > > > > > > >>>>>>> >>>> Yes, that’s 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
> > > > > > > > > > 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
> > > > <
> > > > > > > > > > >>>>>>> >>>> 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?
> > > > > > > > > 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.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
> > > > > > > > > to
> > > > > > > > > > >>>>>>> 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
> > > > > > > > > > >>>>>>> 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
> > > > > <
> > > > > > > > > > >>>>>>> >>>> > 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
> > > > > > > > > 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
> > > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > > >>>>>>> >>>>
> > > > > > > > > > >>>>>>> >>>>
> > > > > > > > > > >>>>>>> >>>
> > > > > > > > > > >>>>>>> >>
> > > > > > > > > > >>>>>>> >
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Scott,
I'll merge in CURATOR-217 when you're done then get started on CURATOR-214.
cheers
On Sun, Aug 16, 2015 at 6:48 AM, Scott Blum <dr...@gmail.com> wrote:
> Ok, I'll push those branches later today!
> On Aug 15, 2015 7:48 AM, "Cameron McKenzie" <mc...@gmail.com>
> wrote:
>
> > Scott,
> > I've had a look at the CURATOR-3.0 branch and I think that it looks ok.
> We
> > still need to merge CURATOR-217 into it (CURATOR-217 already has
> > CURATOR-161 merged into it as it relies on the new watcher removal APIs),
> > but I don't think that should be too problematic.
> >
> > So, I'm happy for you to push the changes. Thanks for sorting this out,
> > this level of git black magic is beyond me.
> >
> > cheers
> >
> > On Sat, Aug 15, 2015 at 3:46 PM, Scott Blum <dr...@gmail.com>
> wrote:
> >
> > > Git uses a lot of heuristics, particularly when recomputing and
> > reapplying
> > > merges. In this case, there were a lot of cross merges between trunk
> and
> > > 3.0, cross merges between the two feature branches, and I think some
> > > incomplete merges. Basically, it just got into a really complicated
> > state.
> > >
> > > On Fri, Aug 14, 2015 at 7:36 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com>
> > > wrote:
> > >
> > > > I agree that committing to 2.x and merging to 3.x is the way to go
> > based
> > > on
> > > > previous experience with managing dual versions.
> > > >
> > > > Scott, I'll have a look at your 3.0 branch tonight. Again, excuse my
> > > > ignorance of the darker bits of git, but do we know how the 3.0
> > branches
> > > > ended up in this state? I would have thought that if they were
> branched
> > > off
> > > > master at some point, then we should be able to do a merge from
> master
> > > into
> > > > the 3.0 branches and not have to do any cherry picking or other such
> > > > shenanigans.
> > > > cheers
> > > >
> > > >
> > > >
> > > > On Sat, Aug 15, 2015 at 5:30 AM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > > >
> > > > > 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 <ma...@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 <
> dragonsinth@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.cam@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 <
> > > dragonsinth@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 <
> > > > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > > > >
> > > > > > > > > > Cameron said he had trouble with 160. Any ideas?
> > > > > > > > > >
> > > > > > > > > > ====================
> > > > > > > > > > Jordan Zimmerman
> > > > > > > > > >
> > > > > > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <
> > > > dragonsinth@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Any feedback on this?
> > > > > > > > > >
> > > > > > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <
> > > > > dragonsinth@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 <
> > > > > > dragonsinth@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 <
> > > > > > > > > >>> jordan@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 (
> > > > > > > dragonsinth@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 <
> > > > > > > dragonsinth@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 <
> > > > > > > > > >>>>> jordan@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 (
> > > > > > > > > dragonsinth@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.cam@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 <
> > > > > > > > > >>>>>>> jordan@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.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 <
> > > > > > > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > > > > > > >>>>>>> > wrote:
> > > > > > > > > >>>>>>> >
> > > > > > > > > >>>>>>> >> Sure thing.
> > > > > > > > > >>>>>>> >>
> > > > > > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan
> Zimmerman
> > <
> > > > > > > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > > > > > > >>>>>>> >>
> > > > > > > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > > > > > > to
> > > > > > > > > >>>>>>> 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
> > > > > > > > > related
> > > > > > > > > >>>>>>> >>>> branches?
> > > > > > > > > >>>>>>> >>>>
> > > > > > > > > >>>>>>> >>>> Yes, that’s 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
> > > > > > > > > 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
> > > <
> > > > > > > > > >>>>>>> >>>> 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?
> > > > > > > > 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.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
> > > > > > > > to
> > > > > > > > > >>>>>>> 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
> > > > > > > > > >>>>>>> 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
> > > > <
> > > > > > > > > >>>>>>> >>>> > 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
> > > > > > > > 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
> > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > >>>>>>> >>>> >
> > > > > > > > > >>>>>>> >>>>
> > > > > > > > > >>>>>>> >>>>
> > > > > > > > > >>>>>>> >>>
> > > > > > > > > >>>>>>> >>
> > > > > > > > > >>>>>>> >
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
Ok, I'll push those branches later today!
On Aug 15, 2015 7:48 AM, "Cameron McKenzie" <mc...@gmail.com> wrote:
> Scott,
> I've had a look at the CURATOR-3.0 branch and I think that it looks ok. We
> still need to merge CURATOR-217 into it (CURATOR-217 already has
> CURATOR-161 merged into it as it relies on the new watcher removal APIs),
> but I don't think that should be too problematic.
>
> So, I'm happy for you to push the changes. Thanks for sorting this out,
> this level of git black magic is beyond me.
>
> cheers
>
> On Sat, Aug 15, 2015 at 3:46 PM, Scott Blum <dr...@gmail.com> wrote:
>
> > Git uses a lot of heuristics, particularly when recomputing and
> reapplying
> > merges. In this case, there were a lot of cross merges between trunk and
> > 3.0, cross merges between the two feature branches, and I think some
> > incomplete merges. Basically, it just got into a really complicated
> state.
> >
> > On Fri, Aug 14, 2015 at 7:36 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > I agree that committing to 2.x and merging to 3.x is the way to go
> based
> > on
> > > previous experience with managing dual versions.
> > >
> > > Scott, I'll have a look at your 3.0 branch tonight. Again, excuse my
> > > ignorance of the darker bits of git, but do we know how the 3.0
> branches
> > > ended up in this state? I would have thought that if they were branched
> > off
> > > master at some point, then we should be able to do a merge from master
> > into
> > > the 3.0 branches and not have to do any cherry picking or other such
> > > shenanigans.
> > > cheers
> > >
> > >
> > >
> > > On Sat, Aug 15, 2015 at 5:30 AM, Scott Blum <dr...@gmail.com>
> > wrote:
> > >
> > > > 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 <ma...@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 <dragonsinth@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.cam@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 <
> > dragonsinth@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 <
> > > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > > >
> > > > > > > > > Cameron said he had trouble with 160. Any ideas?
> > > > > > > > >
> > > > > > > > > ====================
> > > > > > > > > Jordan Zimmerman
> > > > > > > > >
> > > > > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <
> > > dragonsinth@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Any feedback on this?
> > > > > > > > >
> > > > > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <
> > > > dragonsinth@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 <
> > > > > dragonsinth@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 <
> > > > > > > > >>> jordan@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 (
> > > > > > dragonsinth@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 <
> > > > > > dragonsinth@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 <
> > > > > > > > >>>>> jordan@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 (
> > > > > > > > dragonsinth@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.cam@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 <
> > > > > > > > >>>>>>> jordan@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.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 <
> > > > > > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > > > > > >>>>>>> > wrote:
> > > > > > > > >>>>>>> >
> > > > > > > > >>>>>>> >> Sure thing.
> > > > > > > > >>>>>>> >>
> > > > > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman
> <
> > > > > > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > > > > > >>>>>>> >>
> > > > > > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > > > > > to
> > > > > > > > >>>>>>> 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
> > > > > > > > related
> > > > > > > > >>>>>>> >>>> branches?
> > > > > > > > >>>>>>> >>>>
> > > > > > > > >>>>>>> >>>> Yes, that’s 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
> > > > > > > > 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
> > <
> > > > > > > > >>>>>>> >>>> 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?
> > > > > > > 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.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
> > > > > > > to
> > > > > > > > >>>>>>> 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
> > > > > > > > >>>>>>> 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
> > > <
> > > > > > > > >>>>>>> >>>> > 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
> > > > > > > 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
> > > > > > > > >>>>>>> >>>> >
> > > > > > > > >>>>>>> >>>> >
> > > > > > > > >>>>>>> >>>> >
> > > > > > > > >>>>>>> >>>> >
> > > > > > > > >>>>>>> >>>> >
> > > > > > > > >>>>>>> >>>>
> > > > > > > > >>>>>>> >>>>
> > > > > > > > >>>>>>> >>>
> > > > > > > > >>>>>>> >>
> > > > > > > > >>>>>>> >
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Scott,
I've had a look at the CURATOR-3.0 branch and I think that it looks ok. We
still need to merge CURATOR-217 into it (CURATOR-217 already has
CURATOR-161 merged into it as it relies on the new watcher removal APIs),
but I don't think that should be too problematic.
So, I'm happy for you to push the changes. Thanks for sorting this out,
this level of git black magic is beyond me.
cheers
On Sat, Aug 15, 2015 at 3:46 PM, Scott Blum <dr...@gmail.com> wrote:
> Git uses a lot of heuristics, particularly when recomputing and reapplying
> merges. In this case, there were a lot of cross merges between trunk and
> 3.0, cross merges between the two feature branches, and I think some
> incomplete merges. Basically, it just got into a really complicated state.
>
> On Fri, Aug 14, 2015 at 7:36 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > I agree that committing to 2.x and merging to 3.x is the way to go based
> on
> > previous experience with managing dual versions.
> >
> > Scott, I'll have a look at your 3.0 branch tonight. Again, excuse my
> > ignorance of the darker bits of git, but do we know how the 3.0 branches
> > ended up in this state? I would have thought that if they were branched
> off
> > master at some point, then we should be able to do a merge from master
> into
> > the 3.0 branches and not have to do any cherry picking or other such
> > shenanigans.
> > cheers
> >
> >
> >
> > On Sat, Aug 15, 2015 at 5:30 AM, Scott Blum <dr...@gmail.com>
> wrote:
> >
> > > 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 <ma...@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 <dr...@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.cam@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 <
> dragonsinth@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 <
> > > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > > >
> > > > > > > > Cameron said he had trouble with 160. Any ideas?
> > > > > > > >
> > > > > > > > ====================
> > > > > > > > Jordan Zimmerman
> > > > > > > >
> > > > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <
> > dragonsinth@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Any feedback on this?
> > > > > > > >
> > > > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <
> > > dragonsinth@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 <
> > > > dragonsinth@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 <
> > > > > > > >>> jordan@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 (
> > > > > dragonsinth@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 <
> > > > > dragonsinth@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 <
> > > > > > > >>>>> jordan@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 (
> > > > > > > dragonsinth@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.cam@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 <
> > > > > > > >>>>>>> jordan@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.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 <
> > > > > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > > > > >>>>>>> > wrote:
> > > > > > > >>>>>>> >
> > > > > > > >>>>>>> >> Sure thing.
> > > > > > > >>>>>>> >>
> > > > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> > > > > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > > > > >>>>>>> >>
> > > > > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > > > > to
> > > > > > > >>>>>>> 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
> > > > > > > related
> > > > > > > >>>>>>> >>>> branches?
> > > > > > > >>>>>>> >>>>
> > > > > > > >>>>>>> >>>> Yes, that’s 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
> > > > > > > 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
> <
> > > > > > > >>>>>>> >>>> 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?
> > > > > > 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.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
> > > > > > to
> > > > > > > >>>>>>> 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
> > > > > > > >>>>>>> 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
> > <
> > > > > > > >>>>>>> >>>> > 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
> > > > > > 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
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>>
> > > > > > > >>>>>>> >>>>
> > > > > > > >>>>>>> >>>
> > > > > > > >>>>>>> >>
> > > > > > > >>>>>>> >
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
Git uses a lot of heuristics, particularly when recomputing and reapplying
merges. In this case, there were a lot of cross merges between trunk and
3.0, cross merges between the two feature branches, and I think some
incomplete merges. Basically, it just got into a really complicated state.
On Fri, Aug 14, 2015 at 7:36 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> I agree that committing to 2.x and merging to 3.x is the way to go based on
> previous experience with managing dual versions.
>
> Scott, I'll have a look at your 3.0 branch tonight. Again, excuse my
> ignorance of the darker bits of git, but do we know how the 3.0 branches
> ended up in this state? I would have thought that if they were branched off
> master at some point, then we should be able to do a merge from master into
> the 3.0 branches and not have to do any cherry picking or other such
> shenanigans.
> cheers
>
>
>
> On Sat, Aug 15, 2015 at 5:30 AM, Scott Blum <dr...@gmail.com> wrote:
>
> > 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 <ma...@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 <dr...@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.cam@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 <dragonsinth@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 <
> > > > > > jordan@jordanzimmerman.com> wrote:
> > > > > >
> > > > > > > Cameron said he had trouble with 160. Any ideas?
> > > > > > >
> > > > > > > ====================
> > > > > > > Jordan Zimmerman
> > > > > > >
> > > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <
> dragonsinth@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Any feedback on this?
> > > > > > >
> > > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <
> > dragonsinth@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 <
> > > dragonsinth@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 <
> > > > > > >>> jordan@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 (
> > > > dragonsinth@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 <
> > > > dragonsinth@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 <
> > > > > > >>>>> jordan@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 (
> > > > > > dragonsinth@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.cam@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 <
> > > > > > >>>>>>> jordan@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.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 <
> > > > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > > > >>>>>>> > wrote:
> > > > > > >>>>>>> >
> > > > > > >>>>>>> >> Sure thing.
> > > > > > >>>>>>> >>
> > > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> > > > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > > > >>>>>>> >>
> > > > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > > > to
> > > > > > >>>>>>> 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
> > > > > > related
> > > > > > >>>>>>> >>>> branches?
> > > > > > >>>>>>> >>>>
> > > > > > >>>>>>> >>>> Yes, that’s 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
> > > > > > 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 <
> > > > > > >>>>>>> >>>> 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?
> > > > > 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.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
> > > > > to
> > > > > > >>>>>>> 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
> > > > > > >>>>>>> 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
> <
> > > > > > >>>>>>> >>>> > 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
> > > > > 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
> > > > > > >>>>>>> >>>> >
> > > > > > >>>>>>> >>>> >
> > > > > > >>>>>>> >>>> >
> > > > > > >>>>>>> >>>> >
> > > > > > >>>>>>> >>>> >
> > > > > > >>>>>>> >>>>
> > > > > > >>>>>>> >>>>
> > > > > > >>>>>>> >>>
> > > > > > >>>>>>> >>
> > > > > > >>>>>>> >
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
I agree that committing to 2.x and merging to 3.x is the way to go based on
previous experience with managing dual versions.
Scott, I'll have a look at your 3.0 branch tonight. Again, excuse my
ignorance of the darker bits of git, but do we know how the 3.0 branches
ended up in this state? I would have thought that if they were branched off
master at some point, then we should be able to do a merge from master into
the 3.0 branches and not have to do any cherry picking or other such
shenanigans.
cheers
On Sat, Aug 15, 2015 at 5:30 AM, Scott Blum <dr...@gmail.com> wrote:
> 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 <ma...@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 <dr...@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.cam@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 <dr...@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 <
> > > > > jordan@jordanzimmerman.com> wrote:
> > > > >
> > > > > > Cameron said he had trouble with 160. Any ideas?
> > > > > >
> > > > > > ====================
> > > > > > Jordan Zimmerman
> > > > > >
> > > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Any feedback on this?
> > > > > >
> > > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <
> dragonsinth@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 <
> > dragonsinth@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 <
> > > > > >>> jordan@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 (
> > > dragonsinth@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 <
> > > dragonsinth@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 <
> > > > > >>>>> jordan@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 (
> > > > > dragonsinth@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.cam@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 <
> > > > > >>>>>>> jordan@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.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 <
> > > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > > >>>>>>> > wrote:
> > > > > >>>>>>> >
> > > > > >>>>>>> >> Sure thing.
> > > > > >>>>>>> >>
> > > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> > > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > > >>>>>>> >>
> > > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > > to
> > > > > >>>>>>> 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
> > > > > related
> > > > > >>>>>>> >>>> branches?
> > > > > >>>>>>> >>>>
> > > > > >>>>>>> >>>> Yes, that’s 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
> > > > > 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 <
> > > > > >>>>>>> >>>> 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?
> > > > 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.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
> > > > to
> > > > > >>>>>>> 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
> > > > > >>>>>>> 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 <
> > > > > >>>>>>> >>>> > 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
> > > > 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
> > > > > >>>>>>> >>>> >
> > > > > >>>>>>> >>>> >
> > > > > >>>>>>> >>>> >
> > > > > >>>>>>> >>>> >
> > > > > >>>>>>> >>>> >
> > > > > >>>>>>> >>>>
> > > > > >>>>>>> >>>>
> > > > > >>>>>>> >>>
> > > > > >>>>>>> >>
> > > > > >>>>>>> >
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
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 <ma...@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 <dr...@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.cam@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 <dr...@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 <
> > > > jordan@jordanzimmerman.com> wrote:
> > > >
> > > > > Cameron said he had trouble with 160. Any ideas?
> > > > >
> > > > > ====================
> > > > > Jordan Zimmerman
> > > > >
> > > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com>
> > > wrote:
> > > > >
> > > > > Any feedback on this?
> > > > >
> > > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dragonsinth@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 <
> dragonsinth@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 <
> > > > >>> jordan@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 (
> > dragonsinth@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 <
> > dragonsinth@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 <
> > > > >>>>> jordan@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 (
> > > > dragonsinth@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.cam@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 <
> > > > >>>>>>> jordan@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.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 <
> > > > >>>>>>> mckenzie.cam@gmail.com>
> > > > >>>>>>> > wrote:
> > > > >>>>>>> >
> > > > >>>>>>> >> Sure thing.
> > > > >>>>>>> >>
> > > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> > > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > > >>>>>>> >>
> > > > >>>>>>> >>> Go ahead, if you don’t 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
> > > to
> > > > >>>>>>> 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
> > > > related
> > > > >>>>>>> >>>> branches?
> > > > >>>>>>> >>>>
> > > > >>>>>>> >>>> Yes, that’s 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
> > > > 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 <
> > > > >>>>>>> >>>> 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?
> > > 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.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
> > > to
> > > > >>>>>>> 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
> > > > >>>>>>> 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 <
> > > > >>>>>>> >>>> > 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
> > > 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
> > > > >>>>>>> >>>> >
> > > > >>>>>>> >>>> >
> > > > >>>>>>> >>>> >
> > > > >>>>>>> >>>> >
> > > > >>>>>>> >>>> >
> > > > >>>>>>> >>>>
> > > > >>>>>>> >>>>
> > > > >>>>>>> >>>
> > > > >>>>>>> >>
> > > > >>>>>>> >
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Next Steps
Posted by Mike Drob <ma...@cloudera.com>.
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 <dr...@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.cam@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 <dr...@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 <
> > > jordan@jordanzimmerman.com> wrote:
> > >
> > > > Cameron said he had trouble with 160. Any ideas?
> > > >
> > > > ====================
> > > > Jordan Zimmerman
> > > >
> > > > On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com>
> > wrote:
> > > >
> > > > Any feedback on this?
> > > >
> > > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dr...@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 <dr...@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 <
> > > >>> jordan@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 (
> dragonsinth@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 <
> dragonsinth@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 <
> > > >>>>> jordan@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 (
> > > dragonsinth@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.cam@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 <
> > > >>>>>>> jordan@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.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 <
> > > >>>>>>> mckenzie.cam@gmail.com>
> > > >>>>>>> > wrote:
> > > >>>>>>> >
> > > >>>>>>> >> Sure thing.
> > > >>>>>>> >>
> > > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> > > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > > >>>>>>> >>
> > > >>>>>>> >>> Go ahead, if you don’t 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
> > to
> > > >>>>>>> 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
> > > related
> > > >>>>>>> >>>> branches?
> > > >>>>>>> >>>>
> > > >>>>>>> >>>> Yes, that’s 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
> > > 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 <
> > > >>>>>>> >>>> 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?
> > 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.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
> > to
> > > >>>>>>> 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
> > > >>>>>>> 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 <
> > > >>>>>>> >>>> > 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
> > 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
> > > >>>>>>> >>>> >
> > > >>>>>>> >>>> >
> > > >>>>>>> >>>> >
> > > >>>>>>> >>>> >
> > > >>>>>>> >>>> >
> > > >>>>>>> >>>>
> > > >>>>>>> >>>>
> > > >>>>>>> >>>
> > > >>>>>>> >>
> > > >>>>>>> >
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
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 <mc...@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 <dr...@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 <
> > jordan@jordanzimmerman.com> wrote:
> >
> > > Cameron said he had trouble with 160. Any ideas?
> > >
> > > ====================
> > > Jordan Zimmerman
> > >
> > > On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com>
> wrote:
> > >
> > > Any feedback on this?
> > >
> > > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dr...@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 <dr...@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 <
> > >>> jordan@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 (dragonsinth@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 <dragonsinth@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 <
> > >>>>> jordan@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 (
> > dragonsinth@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.cam@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 <
> > >>>>>>> jordan@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.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 <
> > >>>>>>> mckenzie.cam@gmail.com>
> > >>>>>>> > wrote:
> > >>>>>>> >
> > >>>>>>> >> Sure thing.
> > >>>>>>> >>
> > >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> > >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> > >>>>>>> >>
> > >>>>>>> >>> Go ahead, if you don’t 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
> to
> > >>>>>>> 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
> > related
> > >>>>>>> >>>> branches?
> > >>>>>>> >>>>
> > >>>>>>> >>>> Yes, that’s 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
> > 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 <
> > >>>>>>> >>>> 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?
> 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.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
> to
> > >>>>>>> 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
> > >>>>>>> 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 <
> > >>>>>>> >>>> > 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
> 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
> > >>>>>>> >>>> >
> > >>>>>>> >>>> >
> > >>>>>>> >>>> >
> > >>>>>>> >>>> >
> > >>>>>>> >>>> >
> > >>>>>>> >>>>
> > >>>>>>> >>>>
> > >>>>>>> >>>
> > >>>>>>> >>
> > >>>>>>> >
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <dr...@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 <
> jordan@jordanzimmerman.com> wrote:
>
> > Cameron said he had trouble with 160. Any ideas?
> >
> > ====================
> > Jordan Zimmerman
> >
> > On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com> wrote:
> >
> > Any feedback on this?
> >
> > On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dr...@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 <dr...@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 <
> >>> jordan@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 (dragonsinth@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 <dr...@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 <
> >>>>> jordan@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 (
> dragonsinth@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.cam@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 <
> >>>>>>> jordan@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.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 <
> >>>>>>> mckenzie.cam@gmail.com>
> >>>>>>> > wrote:
> >>>>>>> >
> >>>>>>> >> Sure thing.
> >>>>>>> >>
> >>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> >>>>>>> >> jordan@jordanzimmerman.com> wrote:
> >>>>>>> >>
> >>>>>>> >>> Go ahead, if you don’t 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 to
> >>>>>>> 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
> related
> >>>>>>> >>>> branches?
> >>>>>>> >>>>
> >>>>>>> >>>> Yes, that’s 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
> 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 <
> >>>>>>> >>>> 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? 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.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 to
> >>>>>>> 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
> >>>>>>> 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 <
> >>>>>>> >>>> > 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 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
> >>>>>>> >>>> >
> >>>>>>> >>>> >
> >>>>>>> >>>> >
> >>>>>>> >>>> >
> >>>>>>> >>>> >
> >>>>>>> >>>>
> >>>>>>> >>>>
> >>>>>>> >>>
> >>>>>>> >>
> >>>>>>> >
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
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 <
jordan@jordanzimmerman.com> wrote:
> Cameron said he had trouble with 160. Any ideas?
>
> ====================
> Jordan Zimmerman
>
> On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com> wrote:
>
> Any feedback on this?
>
> On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dr...@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 <dr...@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 <
>>> jordan@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 (dragonsinth@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 <dr...@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 <
>>>>> jordan@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 (dragonsinth@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.cam@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 <
>>>>>>> jordan@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.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 <
>>>>>>> mckenzie.cam@gmail.com>
>>>>>>> > wrote:
>>>>>>> >
>>>>>>> >> Sure thing.
>>>>>>> >>
>>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
>>>>>>> >> jordan@jordanzimmerman.com> wrote:
>>>>>>> >>
>>>>>>> >>> Go ahead, if you don’t 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 to
>>>>>>> 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 related
>>>>>>> >>>> branches?
>>>>>>> >>>>
>>>>>>> >>>> Yes, that’s 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 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 <
>>>>>>> >>>> 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? 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.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 to
>>>>>>> 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
>>>>>>> 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 <
>>>>>>> >>>> > 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 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
>>>>>>> >>>> >
>>>>>>> >>>> >
>>>>>>> >>>> >
>>>>>>> >>>> >
>>>>>>> >>>> >
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Cameron said he had trouble with 160. Any ideas?
====================
Jordan Zimmerman
> On Aug 13, 2015, at 10:33 AM, Scott Blum <dr...@gmail.com> wrote:
>
> Any feedback on this?
>
>> On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dr...@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 <dr...@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 <jo...@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 (dragonsinth@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 <dr...@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 <jo...@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 (dragonsinth@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 <mc...@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 <
>>>>>>>>> jordan@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.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 <mc...@gmail.com>
>>>>>>>>> > wrote:
>>>>>>>>> >
>>>>>>>>> >> Sure thing.
>>>>>>>>> >>
>>>>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
>>>>>>>>> >> jordan@jordanzimmerman.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >>> Go ahead, if you don’t 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 to 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 related
>>>>>>>>> >>>> branches?
>>>>>>>>> >>>>
>>>>>>>>> >>>> Yes, that’s 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 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 <
>>>>>>>>> >>>> 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? 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.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 to 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 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 <
>>>>>>>>> >>>> > 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 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
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>
>>>>>>>>> >>
>>>>>>>>> >
>
Re: Next Steps
Posted by Scott Blum <dr...@gmail.com>.
Any feedback on this?
On Wed, Aug 12, 2015 at 5:45 PM, Scott Blum <dr...@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 <dr...@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 <
>> jordan@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 (dragonsinth@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 <dr...@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 <
>>>> jordan@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 (dragonsinth@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.cam@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 <
>>>>>> jordan@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.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 <
>>>>>> mckenzie.cam@gmail.com>
>>>>>> > wrote:
>>>>>> >
>>>>>> >> Sure thing.
>>>>>> >>
>>>>>> >> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
>>>>>> >> jordan@jordanzimmerman.com> wrote:
>>>>>> >>
>>>>>> >>> Go ahead, if you don’t 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 to
>>>>>> 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 related
>>>>>> >>>> branches?
>>>>>> >>>>
>>>>>> >>>> Yes, that’s 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 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 <
>>>>>> >>>> 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? 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.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 to
>>>>>> 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
>>>>>> 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 <
>>>>>> >>>> > 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 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
>>>>>> >>>> >
>>>>>> >>>> >
>>>>>> >>>> >
>>>>>> >>>> >
>>>>>> >>>> >
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <
jordan@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.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 <mc...@gmail.com>
> wrote:
>
>> Sure thing.
>>
>> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> Go ahead, if you don’t 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 to 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 related
>>>> branches?
>>>>
>>>> Yes, that’s 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 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 <
>>>> 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? 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.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 to 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 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 <
>>>> > 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 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
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <mc...@gmail.com> wrote:
Sure thing.
On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
Go ahead, if you don’t 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 to do it and I'll branch from there for CURATOR-214.
On Wed, Aug 12, 2015 at 1:42 PM, Jordan Zimmerman <jo...@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.cam@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 <
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? 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 <mc...@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 <
> 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 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 <
> 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 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
>
>
>
>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
So, I will delete the existing CURATOR-3.0 branch?
On Wed, Aug 12, 2015 at 2:04 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Sure thing.
>
> On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> Go ahead, if you don’t 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 to 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 related
>>> branches?
>>>
>>> Yes, that’s 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 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 <
>>> 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? 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.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 to 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 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 <
>>> > 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 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Sure thing.
On Wed, Aug 12, 2015 at 1:55 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Go ahead, if you don’t 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 to 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 related branches?
>>
>> Yes, that’s 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 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 <
>> 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? 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.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 to 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 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 <
>> > 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 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
>> >
>> >
>> >
>> >
>> >
>>
>>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Go ahead, if you don’t 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 to do it and I'll branch from there for CURATOR-214.
On Wed, Aug 12, 2015 at 1:42 PM, Jordan Zimmerman <jo...@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.cam@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 <
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? 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 <mc...@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 <
> 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 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 <
> 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 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
>
>
>
>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <
jordan@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.cam@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 <
> 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? 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.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 to 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 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 <
> > 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 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
> >
> >
> >
> >
> >
>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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.cam@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 <
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? 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 <mc...@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 <
> 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 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 <
> 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 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
>
>
>
>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <
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? 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 <mc...@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 <
> 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 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 <
> 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 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
>
>
>
>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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? 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 <mc...@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 <jo...@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 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 <jo...@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 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
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <mc...@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 <
> 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 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 <
>> 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 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
>>>
>>
>>
>
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <
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 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 <
> 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 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
>>
>
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 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 <jo...@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 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
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <
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 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
>
Re: Next Steps
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 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
Re: Next Steps
Posted by Cameron McKenzie <mc...@gmail.com>.
Sounds good to me,
I would like to get a fix to CURATOR-228 into this release if possible, but
I'm still working through possible solutions. As discussed on the mailing
list I think that the most promising approach is to allow retry codes to be
specified via the client framework. Any input would be appreciated
I'll merge CURATOR-241 into master shortly.
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
On Mon, Aug 10, 2015 at 1:36 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Hey Folks,
>
> First, I apologize for being AWOL from Curator for the past while. But,
> I’m now available. I’d like to discuss next steps and actions. My personal
> priorities are: a) release 2.9.0; b) release 3.0.0.
>
> ** Issues for 2.9.0
>
> - Remaining bugs.
> - Any additional issues to be included
>
> ** Issues for 3.0.0
>
> - Fix the merge issues
> - Testing/validation
> - Any additional issues to be included
>
> Thoughts?
>
> -JZ