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 Fri, 14 Aug 2015 03:03:29 GMT
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