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 Thu, 13 Aug 2015 15:49:13 GMT
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