curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Next Steps
Date Sat, 15 Aug 2015 11:47:48 GMT
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 <dragonsinth@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 <madrob@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
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>> >
> > > > > > > >>>>>>> >>>>
> > > > > > > >>>>>>> >>>>
> > > > > > > >>>>>>> >>>
> > > > > > > >>>>>>> >>
> > > > > > > >>>>>>> >
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message