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 Fri, 14 Aug 2015 19:30:47 GMT
I think dual commits tend to be problematic.  I'd suggest anything for 2.x
goes into master and then we immediately merge master into 3.0.  Anything
for 3.0 stays in 3.0 only.  (There will soon be a discussion to be had
about whether master should become 3.0 in the near future.)


More immediately, has anyone had a chance to look at my proposed history
redo?  I feel like this is starting to stall out.  Can I set a 24 period
starting now for people to object, and if I don't hear anything, I'm going
to go ahead and push the updates.  I will leave "old" branch markers on the
old stuff to avoid being destructive.


On Fri, Aug 14, 2015 at 3:24 PM, Mike Drob <madrob@cloudera.com> wrote:

> Once we have a stable 3.0 branch, should we dual-commit everything to
> master and 3.x? The ZK3.5 "alpha" labelling can scare off some adopters, so
> I think it is important to maintain 2.x for a little while longer.
>
> I can volunteer to do the next 2.x release once the tests are stabilized -
> I'll start a new thread on that sometime this weekend.
>
> On Fri, Aug 14, 2015 at 2:12 AM, Scott Blum <dragonsinth@gmail.com> wrote:
>
> > Yes, the 3.0 branch I created should have everything.  But let me
> emphasize
> > I haven't pushed this to apache yet!  I wanted you guys to check it out
> > first, it's only pushed to my mirror.
> >
> > It's.... complicated to describe what I did.  Mostly rebasing, some
> cherry
> > picking, and fixing merge conflicts.  But using gitk to visualize what I
> > was doing.  I also had to redo it once or twice when something went
> wrong.
> > Sorry I can't really give and exact recount... I worked on this for
> quite a
> > while, like 2 hours maybe.
> >
> > On Thu, Aug 13, 2015 at 11:03 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com
> > >
> > wrote:
> >
> > > 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