Merge strategy now that CURATOR-3.0 is master

[Jordan Zimmerman <jo...@jordanzimmerman.com>]

Folks,

Now that CURATOR-3.0 is master, how should we deal with keeping CURATOR-2.0 in sync. It's no longer possible to do simple merges. Should we cherry-pick changes into CURATOR-2.0? Should we require separate PRs for changes to each branch?

Scott, you're our resident git expert. Any best practices to apply here?

-Jordan

Re: Merge strategy now that CURATOR-3.0 is master

[Jordan Zimmerman <jo...@jordanzimmerman.com>]

OK - I've updated the Wiki with this new standard:

https://cwiki.apache.org/confluence/display/CURATOR/For+Curator+Committers#ForCuratorCommitters-pr-curator-2.0 <https://cwiki.apache.org/confluence/display/CURATOR/For+Curator+Committers#ForCuratorCommitters-pr-curator-2.0>

I added a note as well to do squash merges.

-JZ

> On May 9, 2017, at 2:32 AM, Scott Blum <dr...@gmail.com> wrote:
> 
> Cherry-pick is basically an "on the rails" version of patch+apply.  Sounds like we should just do all development on master, and cherry pick individual bugfixes to CURATOR-2.0.
> 
> The one caveat to that approach, however, is that it works a lot better if you merge+squash changes when you commit to master rather than creating traditional git merge commits on master.  The company I worked for switched to merge+squash a while back when Github started offering it from the pull request UI, and it's been great.  The history is much more sane to digest, you don't end up with all of the "development" iterations polluting your history forever, and single every change is a single logical commit it's easy to cherry-pick.
> 
> 
> On Mon, May 8, 2017 at 6:40 AM, Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>> wrote:
> As I explained in the original email, ZooKeeper 3.5 is now at "beta" and will soon be the main version. CURATOR-3.0 is our branch that matches ZooKeeper 3.5 so it too needs to be master. That's the reason for the change. 
> 
> How many additional versions of CURATOR-2.0 we do is entirely up to us. CURATOR-409/CURATOR-410 as examples of changes that also apply to CURATOR-2.0. Cherry-pick is one option. A git patch/apply would also work.
> 
> -JZ
> 
>> On May 8, 2017, at 7:50 AM, Scott Blum <dragonsinth@gmail.com <ma...@gmail.com>> wrote:
>> 
>> We should definitely be very clear on the goals before trying to pick a specific technical strategy!
>> 
>> If 2.0 is basically "done" except for bugfixes, then the best strategy is probably to just do everything on master (3.0) and only backport / cherry-pick specific bugfixes.  I'm assuming that was the underlying rational for calling 3.0 master?
>> 
>> 
>> On Mon, May 8, 2017 at 12:23 AM, Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>> wrote:
>> In this case I think the PRs were made against master. But, they both apply to CURATOR-2.0.
>> 
>> Another possibility is that we sunset CURATOR-2.0 and just say - time to move on CURATOR-2.0 is what it is.
>> 
>> -JZ
>> 
>> > On May 8, 2017, at 6:22 AM, Cameron McKenzie <mckenzie.cam@gmail.com <ma...@gmail.com>> wrote:
>> >
>> > The PRs were presumably made against the 3.0 baseline? I guess if it's a
>> > 3.0 specific fix it should just be merged to master. If it's a 2.0 fix then
>> > it should be merged into 2.0 and then merged up to master if appropriate.
>> >
>> > On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>
>> >> wrote:
>> >
>> >> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of
>> >> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.
>> >>
>> >> -JZ
>> >>
>> >>> On May 8, 2017, at 6:12 AM, Cameron McKenzie <mckenzie.cam@gmail.com <ma...@gmail.com>>
>> >> wrote:
>> >>>
>> >>> Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
>> >>> into master?  Cherry picking seems very manual and error prone (at least
>> >>> based on my minimal Git experience).
>> >>> cheers
>> >>>
>> >>> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <
>> >> jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>
>> >>>> wrote:
>> >>>
>> >>>> Folks,
>> >>>>
>> >>>> Now that CURATOR-3.0 is master, how should we deal with keeping
>> >>>> CURATOR-2.0 in sync. It's no longer possible to do simple merges.
>> >> Should we
>> >>>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for
>> >>>> changes to each branch?
>> >>>>
>> >>>> Scott, you're our resident git expert. Any best practices to apply here?
>> >>>>
>> >>>> -Jordan
>> >>
>> >>
>> 
>> 
> 
> 

Re: Merge strategy now that CURATOR-3.0 is master

[Scott Blum <dr...@gmail.com>]

Cherry-pick is basically an "on the rails" version of patch+apply.  Sounds
like we should just do all development on master, and cherry pick
individual bugfixes to CURATOR-2.0.

The one caveat to that approach, however, is that it works a lot better if
you merge+squash changes when you commit to master rather than creating
traditional git merge commits on master.  The company I worked for switched
to merge+squash a while back when Github started offering it from the pull
request UI, and it's been great.  The history is much more sane to digest,
you don't end up with all of the "development" iterations polluting your
history forever, and single every change is a single logical commit it's
easy to cherry-pick.


On Mon, May 8, 2017 at 6:40 AM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:

> As I explained in the original email, ZooKeeper 3.5 is now at "beta" and
> will soon be the main version. CURATOR-3.0 is our branch that matches
> ZooKeeper 3.5 so it too needs to be master. That's the reason for the
> change.
>
> How many additional versions of CURATOR-2.0 we do is entirely up to
> us. CURATOR-409/CURATOR-410 as examples of changes that also apply to
> CURATOR-2.0. Cherry-pick is one option. A git patch/apply would also work.
>
> -JZ
>
> On May 8, 2017, at 7:50 AM, Scott Blum <dr...@gmail.com> wrote:
>
> We should definitely be very clear on the goals before trying to pick a
> specific technical strategy!
>
> If 2.0 is basically "done" except for bugfixes, then the best strategy is
> probably to just do everything on master (3.0) and only backport /
> cherry-pick specific bugfixes.  I'm assuming that was the underlying
> rational for calling 3.0 master?
>
>
> On Mon, May 8, 2017 at 12:23 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> In this case I think the PRs were made against master. But, they both
>> apply to CURATOR-2.0.
>>
>> Another possibility is that we sunset CURATOR-2.0 and just say - time to
>> move on CURATOR-2.0 is what it is.
>>
>> -JZ
>>
>> > On May 8, 2017, at 6:22 AM, Cameron McKenzie <mc...@gmail.com>
>> wrote:
>> >
>> > The PRs were presumably made against the 3.0 baseline? I guess if it's a
>> > 3.0 specific fix it should just be merged to master. If it's a 2.0 fix
>> then
>> > it should be merged into 2.0 and then merged up to master if
>> appropriate.
>> >
>> > On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com
>> >> wrote:
>> >
>> >> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of
>> >> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.
>> >>
>> >> -JZ
>> >>
>> >>> On May 8, 2017, at 6:12 AM, Cameron McKenzie <mc...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Can we still apply patches (where appropriate) to CURATOR-2.0 and
>> merge
>> >>> into master?  Cherry picking seems very manual and error prone (at
>> least
>> >>> based on my minimal Git experience).
>> >>> cheers
>> >>>
>> >>> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <
>> >> jordan@jordanzimmerman.com
>> >>>> wrote:
>> >>>
>> >>>> Folks,
>> >>>>
>> >>>> Now that CURATOR-3.0 is master, how should we deal with keeping
>> >>>> CURATOR-2.0 in sync. It's no longer possible to do simple merges.
>> >> Should we
>> >>>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs
>> for
>> >>>> changes to each branch?
>> >>>>
>> >>>> Scott, you're our resident git expert. Any best practices to apply
>> here?
>> >>>>
>> >>>> -Jordan
>> >>
>> >>
>>
>>
>
>

Re: Merge strategy now that CURATOR-3.0 is master

[Jordan Zimmerman <jo...@jordanzimmerman.com>]

As I explained in the original email, ZooKeeper 3.5 is now at "beta" and will soon be the main version. CURATOR-3.0 is our branch that matches ZooKeeper 3.5 so it too needs to be master. That's the reason for the change. 

How many additional versions of CURATOR-2.0 we do is entirely up to us. CURATOR-409/CURATOR-410 as examples of changes that also apply to CURATOR-2.0. Cherry-pick is one option. A git patch/apply would also work.

-JZ

> On May 8, 2017, at 7:50 AM, Scott Blum <dr...@gmail.com> wrote:
> 
> We should definitely be very clear on the goals before trying to pick a specific technical strategy!
> 
> If 2.0 is basically "done" except for bugfixes, then the best strategy is probably to just do everything on master (3.0) and only backport / cherry-pick specific bugfixes.  I'm assuming that was the underlying rational for calling 3.0 master?
> 
> 
> On Mon, May 8, 2017 at 12:23 AM, Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>> wrote:
> In this case I think the PRs were made against master. But, they both apply to CURATOR-2.0.
> 
> Another possibility is that we sunset CURATOR-2.0 and just say - time to move on CURATOR-2.0 is what it is.
> 
> -JZ
> 
> > On May 8, 2017, at 6:22 AM, Cameron McKenzie <mckenzie.cam@gmail.com <ma...@gmail.com>> wrote:
> >
> > The PRs were presumably made against the 3.0 baseline? I guess if it's a
> > 3.0 specific fix it should just be merged to master. If it's a 2.0 fix then
> > it should be merged into 2.0 and then merged up to master if appropriate.
> >
> > On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>
> >> wrote:
> >
> >> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of
> >> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.
> >>
> >> -JZ
> >>
> >>> On May 8, 2017, at 6:12 AM, Cameron McKenzie <mckenzie.cam@gmail.com <ma...@gmail.com>>
> >> wrote:
> >>>
> >>> Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
> >>> into master?  Cherry picking seems very manual and error prone (at least
> >>> based on my minimal Git experience).
> >>> cheers
> >>>
> >>> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>
> >>>> wrote:
> >>>
> >>>> Folks,
> >>>>
> >>>> Now that CURATOR-3.0 is master, how should we deal with keeping
> >>>> CURATOR-2.0 in sync. It's no longer possible to do simple merges.
> >> Should we
> >>>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for
> >>>> changes to each branch?
> >>>>
> >>>> Scott, you're our resident git expert. Any best practices to apply here?
> >>>>
> >>>> -Jordan
> >>
> >>
> 
> 

Re: Merge strategy now that CURATOR-3.0 is master

[Scott Blum <dr...@gmail.com>]

We should definitely be very clear on the goals before trying to pick a
specific technical strategy!

If 2.0 is basically "done" except for bugfixes, then the best strategy is
probably to just do everything on master (3.0) and only backport /
cherry-pick specific bugfixes.  I'm assuming that was the underlying
rational for calling 3.0 master?


On Mon, May 8, 2017 at 12:23 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> In this case I think the PRs were made against master. But, they both
> apply to CURATOR-2.0.
>
> Another possibility is that we sunset CURATOR-2.0 and just say - time to
> move on CURATOR-2.0 is what it is.
>
> -JZ
>
> > On May 8, 2017, at 6:22 AM, Cameron McKenzie <mc...@gmail.com>
> wrote:
> >
> > The PRs were presumably made against the 3.0 baseline? I guess if it's a
> > 3.0 specific fix it should just be merged to master. If it's a 2.0 fix
> then
> > it should be merged into 2.0 and then merged up to master if appropriate.
> >
> > On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com
> >> wrote:
> >
> >> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of
> >> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.
> >>
> >> -JZ
> >>
> >>> On May 8, 2017, at 6:12 AM, Cameron McKenzie <mc...@gmail.com>
> >> wrote:
> >>>
> >>> Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
> >>> into master?  Cherry picking seems very manual and error prone (at
> least
> >>> based on my minimal Git experience).
> >>> cheers
> >>>
> >>> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com
> >>>> wrote:
> >>>
> >>>> Folks,
> >>>>
> >>>> Now that CURATOR-3.0 is master, how should we deal with keeping
> >>>> CURATOR-2.0 in sync. It's no longer possible to do simple merges.
> >> Should we
> >>>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs
> for
> >>>> changes to each branch?
> >>>>
> >>>> Scott, you're our resident git expert. Any best practices to apply
> here?
> >>>>
> >>>> -Jordan
> >>
> >>
>
>

Re: Merge strategy now that CURATOR-3.0 is master

[Jordan Zimmerman <jo...@jordanzimmerman.com>]

In this case I think the PRs were made against master. But, they both apply to CURATOR-2.0. 

Another possibility is that we sunset CURATOR-2.0 and just say - time to move on CURATOR-2.0 is what it is.

-JZ

> On May 8, 2017, at 6:22 AM, Cameron McKenzie <mc...@gmail.com> wrote:
> 
> The PRs were presumably made against the 3.0 baseline? I guess if it's a
> 3.0 specific fix it should just be merged to master. If it's a 2.0 fix then
> it should be merged into 2.0 and then merged up to master if appropriate.
> 
> On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
>> wrote:
> 
>> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of
>> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.
>> 
>> -JZ
>> 
>>> On May 8, 2017, at 6:12 AM, Cameron McKenzie <mc...@gmail.com>
>> wrote:
>>> 
>>> Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
>>> into master?  Cherry picking seems very manual and error prone (at least
>>> based on my minimal Git experience).
>>> cheers
>>> 
>>> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com
>>>> wrote:
>>> 
>>>> Folks,
>>>> 
>>>> Now that CURATOR-3.0 is master, how should we deal with keeping
>>>> CURATOR-2.0 in sync. It's no longer possible to do simple merges.
>> Should we
>>>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for
>>>> changes to each branch?
>>>> 
>>>> Scott, you're our resident git expert. Any best practices to apply here?
>>>> 
>>>> -Jordan
>> 
>> 

Re: Merge strategy now that CURATOR-3.0 is master

[Cameron McKenzie <mc...@gmail.com>]

The PRs were presumably made against the 3.0 baseline? I guess if it's a
3.0 specific fix it should just be merged to master. If it's a 2.0 fix then
it should be merged into 2.0 and then merged up to master if appropriate.

On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:

> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of
> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.
>
> -JZ
>
> > On May 8, 2017, at 6:12 AM, Cameron McKenzie <mc...@gmail.com>
> wrote:
> >
> > Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
> > into master?  Cherry picking seems very manual and error prone (at least
> > based on my minimal Git experience).
> > cheers
> >
> > On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com
> >> wrote:
> >
> >> Folks,
> >>
> >> Now that CURATOR-3.0 is master, how should we deal with keeping
> >> CURATOR-2.0 in sync. It's no longer possible to do simple merges.
> Should we
> >> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for
> >> changes to each branch?
> >>
> >> Scott, you're our resident git expert. Any best practices to apply here?
> >>
> >> -Jordan
>
>

Re: Merge strategy now that CURATOR-3.0 is master

[Jordan Zimmerman <jo...@jordanzimmerman.com>]

For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes.

-JZ

> On May 8, 2017, at 6:12 AM, Cameron McKenzie <mc...@gmail.com> wrote:
> 
> Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
> into master?  Cherry picking seems very manual and error prone (at least
> based on my minimal Git experience).
> cheers
> 
> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
>> wrote:
> 
>> Folks,
>> 
>> Now that CURATOR-3.0 is master, how should we deal with keeping
>> CURATOR-2.0 in sync. It's no longer possible to do simple merges. Should we
>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for
>> changes to each branch?
>> 
>> Scott, you're our resident git expert. Any best practices to apply here?
>> 
>> -Jordan

Re: Merge strategy now that CURATOR-3.0 is master

[Cameron McKenzie <mc...@gmail.com>]

Can we still apply patches (where appropriate) to CURATOR-2.0 and merge
into master?  Cherry picking seems very manual and error prone (at least
based on my minimal Git experience).
cheers

On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:

> Folks,
>
> Now that CURATOR-3.0 is master, how should we deal with keeping
> CURATOR-2.0 in sync. It's no longer possible to do simple merges. Should we
> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for
> changes to each branch?
>
> Scott, you're our resident git expert. Any best practices to apply here?
>
> -Jordan