curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Next Steps
Date Thu, 13 Aug 2015 15:39:27 GMT
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, 7-Bit, 0 bytes)
View raw message