curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Blum <dragonsi...@gmail.com>
Subject Re: Next Steps
Date Tue, 18 Aug 2015 03:38:11 GMT
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 <dragonsinth@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 <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
>>> >
>>>
>>
>>
>

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