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 Tue, 18 Aug 2015 03:42:04 GMT
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 <dragonsinth@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 <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