Backporting a patch to a release branch

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Backporting a patch to a release branch

stefanobaghino
I'm currently working on FLINK-3239
<https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos on the
Kafka connector).

I almost have a working prototype, however now I have a doubt regarding how
to properly merge my code (when done): right now I'm working on a branch
out of the 1.0.x release branch (apparently I could not start a cluster to
test on my setup because of FLINK-3824
<https://issues.apache.org/jira/browse/FLINK-3824>).

I'll have to make some minor change to adapt it to the master branch (it's
just a few lines of code but some of the code I had to touch have been
moved in the BootstrapTool.java source file); at this point I'd like to
make it available for both the master and the 1.0.x release branch.

Is there any established process to handle a case like this? Is there a
development branch for releases? Should I perform a PR directly onto the
1.0.x branch? I would assume the latter is unadvisable, just asking if
that's the case.

--
BR,
Stefano Baghino

Software Engineer @ Radicalbit
Reply | Threaded
Open this post in threaded view
|

Re: Backporting a patch to a release branch

Aljoscha Krettek-2
Hi,
I think what we did for now is this: When merging a PR onto the master that
we also consider to be required in a future release of an older release
branch we cherry-pick it there and make the required changes. This only
works for committers, of course, since we can just do that.

I think in your case (and future cases) you can cherry-pick it on the
release branch and then provide a link to your branch in the original PR
such that the committer who merges it can also put it into the older
release branch.

Cheers,
Aljoscha

On Wed, 27 Apr 2016 at 13:38 Stefano Baghino <[hidden email]>
wrote:

> I'm currently working on FLINK-3239
> <https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos on
> the
> Kafka connector).
>
> I almost have a working prototype, however now I have a doubt regarding how
> to properly merge my code (when done): right now I'm working on a branch
> out of the 1.0.x release branch (apparently I could not start a cluster to
> test on my setup because of FLINK-3824
> <https://issues.apache.org/jira/browse/FLINK-3824>).
>
> I'll have to make some minor change to adapt it to the master branch (it's
> just a few lines of code but some of the code I had to touch have been
> moved in the BootstrapTool.java source file); at this point I'd like to
> make it available for both the master and the 1.0.x release branch.
>
> Is there any established process to handle a case like this? Is there a
> development branch for releases? Should I perform a PR directly onto the
> 1.0.x branch? I would assume the latter is unadvisable, just asking if
> that's the case.
>
> --
> BR,
> Stefano Baghino
>
> Software Engineer @ Radicalbit
>
Reply | Threaded
Open this post in threaded view
|

Re: Backporting a patch to a release branch

stefanobaghino
Hi Ufuk,

thanks for getting back to me, I understand.
The problem with this patch in particular is that the code would be
slightly different between the 1.0.x and 1.1.x, so cherry-picking the
commit from the master branch to the release branch wouldn't be a viable
option, unfortunately. In this case the patch can only appear from the 1.1
release onward?

On Wed, Apr 27, 2016 at 2:57 PM, Aljoscha Krettek <[hidden email]>
wrote:

> Hi,
> I think what we did for now is this: When merging a PR onto the master that
> we also consider to be required in a future release of an older release
> branch we cherry-pick it there and make the required changes. This only
> works for committers, of course, since we can just do that.
>
> I think in your case (and future cases) you can cherry-pick it on the
> release branch and then provide a link to your branch in the original PR
> such that the committer who merges it can also put it into the older
> release branch.
>
> Cheers,
> Aljoscha
>
> On Wed, 27 Apr 2016 at 13:38 Stefano Baghino <
> [hidden email]>
> wrote:
>
> > I'm currently working on FLINK-3239
> > <https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos on
> > the
> > Kafka connector).
> >
> > I almost have a working prototype, however now I have a doubt regarding
> how
> > to properly merge my code (when done): right now I'm working on a branch
> > out of the 1.0.x release branch (apparently I could not start a cluster
> to
> > test on my setup because of FLINK-3824
> > <https://issues.apache.org/jira/browse/FLINK-3824>).
> >
> > I'll have to make some minor change to adapt it to the master branch
> (it's
> > just a few lines of code but some of the code I had to touch have been
> > moved in the BootstrapTool.java source file); at this point I'd like to
> > make it available for both the master and the 1.0.x release branch.
> >
> > Is there any established process to handle a case like this? Is there a
> > development branch for releases? Should I perform a PR directly onto the
> > 1.0.x branch? I would assume the latter is unadvisable, just asking if
> > that's the case.
> >
> > --
> > BR,
> > Stefano Baghino
> >
> > Software Engineer @ Radicalbit
> >
>



--
BR,
Stefano Baghino

Software Engineer @ Radicalbit
Reply | Threaded
Open this post in threaded view
|

Re: Backporting a patch to a release branch

Till Rohrmann
Hi Stefano,

in this case I think it's best if you opened a PR against the release
branch so that a committer can pull it in.

Cheers,
Till

On Wed, Apr 27, 2016 at 3:03 PM, Stefano Baghino <
[hidden email]> wrote:

> Hi Ufuk,
>
> thanks for getting back to me, I understand.
> The problem with this patch in particular is that the code would be
> slightly different between the 1.0.x and 1.1.x, so cherry-picking the
> commit from the master branch to the release branch wouldn't be a viable
> option, unfortunately. In this case the patch can only appear from the 1.1
> release onward?
>
> On Wed, Apr 27, 2016 at 2:57 PM, Aljoscha Krettek <[hidden email]>
> wrote:
>
> > Hi,
> > I think what we did for now is this: When merging a PR onto the master
> that
> > we also consider to be required in a future release of an older release
> > branch we cherry-pick it there and make the required changes. This only
> > works for committers, of course, since we can just do that.
> >
> > I think in your case (and future cases) you can cherry-pick it on the
> > release branch and then provide a link to your branch in the original PR
> > such that the committer who merges it can also put it into the older
> > release branch.
> >
> > Cheers,
> > Aljoscha
> >
> > On Wed, 27 Apr 2016 at 13:38 Stefano Baghino <
> > [hidden email]>
> > wrote:
> >
> > > I'm currently working on FLINK-3239
> > > <https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos
> on
> > > the
> > > Kafka connector).
> > >
> > > I almost have a working prototype, however now I have a doubt regarding
> > how
> > > to properly merge my code (when done): right now I'm working on a
> branch
> > > out of the 1.0.x release branch (apparently I could not start a cluster
> > to
> > > test on my setup because of FLINK-3824
> > > <https://issues.apache.org/jira/browse/FLINK-3824>).
> > >
> > > I'll have to make some minor change to adapt it to the master branch
> > (it's
> > > just a few lines of code but some of the code I had to touch have been
> > > moved in the BootstrapTool.java source file); at this point I'd like to
> > > make it available for both the master and the 1.0.x release branch.
> > >
> > > Is there any established process to handle a case like this? Is there a
> > > development branch for releases? Should I perform a PR directly onto
> the
> > > 1.0.x branch? I would assume the latter is unadvisable, just asking if
> > > that's the case.
> > >
> > > --
> > > BR,
> > > Stefano Baghino
> > >
> > > Software Engineer @ Radicalbit
> > >
> >
>
>
>
> --
> BR,
> Stefano Baghino
>
> Software Engineer @ Radicalbit
>
Reply | Threaded
Open this post in threaded view
|

Re: Backporting a patch to a release branch

stefanobaghino
Ok, thanks for the feedback.

On Wed, Apr 27, 2016 at 3:16 PM, Till Rohrmann <[hidden email]> wrote:

> Hi Stefano,
>
> in this case I think it's best if you opened a PR against the release
> branch so that a committer can pull it in.
>
> Cheers,
> Till
>
> On Wed, Apr 27, 2016 at 3:03 PM, Stefano Baghino <
> [hidden email]> wrote:
>
> > Hi Ufuk,
> >
> > thanks for getting back to me, I understand.
> > The problem with this patch in particular is that the code would be
> > slightly different between the 1.0.x and 1.1.x, so cherry-picking the
> > commit from the master branch to the release branch wouldn't be a viable
> > option, unfortunately. In this case the patch can only appear from the
> 1.1
> > release onward?
> >
> > On Wed, Apr 27, 2016 at 2:57 PM, Aljoscha Krettek <[hidden email]>
> > wrote:
> >
> > > Hi,
> > > I think what we did for now is this: When merging a PR onto the master
> > that
> > > we also consider to be required in a future release of an older release
> > > branch we cherry-pick it there and make the required changes. This only
> > > works for committers, of course, since we can just do that.
> > >
> > > I think in your case (and future cases) you can cherry-pick it on the
> > > release branch and then provide a link to your branch in the original
> PR
> > > such that the committer who merges it can also put it into the older
> > > release branch.
> > >
> > > Cheers,
> > > Aljoscha
> > >
> > > On Wed, 27 Apr 2016 at 13:38 Stefano Baghino <
> > > [hidden email]>
> > > wrote:
> > >
> > > > I'm currently working on FLINK-3239
> > > > <https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos
> > on
> > > > the
> > > > Kafka connector).
> > > >
> > > > I almost have a working prototype, however now I have a doubt
> regarding
> > > how
> > > > to properly merge my code (when done): right now I'm working on a
> > branch
> > > > out of the 1.0.x release branch (apparently I could not start a
> cluster
> > > to
> > > > test on my setup because of FLINK-3824
> > > > <https://issues.apache.org/jira/browse/FLINK-3824>).
> > > >
> > > > I'll have to make some minor change to adapt it to the master branch
> > > (it's
> > > > just a few lines of code but some of the code I had to touch have
> been
> > > > moved in the BootstrapTool.java source file); at this point I'd like
> to
> > > > make it available for both the master and the 1.0.x release branch.
> > > >
> > > > Is there any established process to handle a case like this? Is
> there a
> > > > development branch for releases? Should I perform a PR directly onto
> > the
> > > > 1.0.x branch? I would assume the latter is unadvisable, just asking
> if
> > > > that's the case.
> > > >
> > > > --
> > > > BR,
> > > > Stefano Baghino
> > > >
> > > > Software Engineer @ Radicalbit
> > > >
> > >
> >
> >
> >
> > --
> > BR,
> > Stefano Baghino
> >
> > Software Engineer @ Radicalbit
> >
>



--
BR,
Stefano Baghino

Software Engineer @ Radicalbit
mxm
Reply | Threaded
Open this post in threaded view
|

Re: Backporting a patch to a release branch

mxm
Hi Stefano,

It is a bit unfortunate for you that you have to spend additional time
to port your code to a different branch. A PR is the way to go if a
commit can't be simply cherry-picked.

If your changes are too major then it is probably good idea just to
include them in the next major release. Minor releases typically don't
include new features. Now it's questionable whether this is a fix or a
new feature :)

Cheers,
Max

On Wed, Apr 27, 2016 at 3:18 PM, Stefano Baghino
<[hidden email]> wrote:

> Ok, thanks for the feedback.
>
> On Wed, Apr 27, 2016 at 3:16 PM, Till Rohrmann <[hidden email]> wrote:
>
>> Hi Stefano,
>>
>> in this case I think it's best if you opened a PR against the release
>> branch so that a committer can pull it in.
>>
>> Cheers,
>> Till
>>
>> On Wed, Apr 27, 2016 at 3:03 PM, Stefano Baghino <
>> [hidden email]> wrote:
>>
>> > Hi Ufuk,
>> >
>> > thanks for getting back to me, I understand.
>> > The problem with this patch in particular is that the code would be
>> > slightly different between the 1.0.x and 1.1.x, so cherry-picking the
>> > commit from the master branch to the release branch wouldn't be a viable
>> > option, unfortunately. In this case the patch can only appear from the
>> 1.1
>> > release onward?
>> >
>> > On Wed, Apr 27, 2016 at 2:57 PM, Aljoscha Krettek <[hidden email]>
>> > wrote:
>> >
>> > > Hi,
>> > > I think what we did for now is this: When merging a PR onto the master
>> > that
>> > > we also consider to be required in a future release of an older release
>> > > branch we cherry-pick it there and make the required changes. This only
>> > > works for committers, of course, since we can just do that.
>> > >
>> > > I think in your case (and future cases) you can cherry-pick it on the
>> > > release branch and then provide a link to your branch in the original
>> PR
>> > > such that the committer who merges it can also put it into the older
>> > > release branch.
>> > >
>> > > Cheers,
>> > > Aljoscha
>> > >
>> > > On Wed, 27 Apr 2016 at 13:38 Stefano Baghino <
>> > > [hidden email]>
>> > > wrote:
>> > >
>> > > > I'm currently working on FLINK-3239
>> > > > <https://issues.apache.org/jira/browse/FLINK-3239> (support Kerberos
>> > on
>> > > > the
>> > > > Kafka connector).
>> > > >
>> > > > I almost have a working prototype, however now I have a doubt
>> regarding
>> > > how
>> > > > to properly merge my code (when done): right now I'm working on a
>> > branch
>> > > > out of the 1.0.x release branch (apparently I could not start a
>> cluster
>> > > to
>> > > > test on my setup because of FLINK-3824
>> > > > <https://issues.apache.org/jira/browse/FLINK-3824>).
>> > > >
>> > > > I'll have to make some minor change to adapt it to the master branch
>> > > (it's
>> > > > just a few lines of code but some of the code I had to touch have
>> been
>> > > > moved in the BootstrapTool.java source file); at this point I'd like
>> to
>> > > > make it available for both the master and the 1.0.x release branch.
>> > > >
>> > > > Is there any established process to handle a case like this? Is
>> there a
>> > > > development branch for releases? Should I perform a PR directly onto
>> > the
>> > > > 1.0.x branch? I would assume the latter is unadvisable, just asking
>> if
>> > > > that's the case.
>> > > >
>> > > > --
>> > > > BR,
>> > > > Stefano Baghino
>> > > >
>> > > > Software Engineer @ Radicalbit
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > BR,
>> > Stefano Baghino
>> >
>> > Software Engineer @ Radicalbit
>> >
>>
>
>
>
> --
> BR,
> Stefano Baghino
>
> Software Engineer @ Radicalbit
Reply | Threaded
Open this post in threaded view
|

Re: Backporting a patch to a release branch

stefanobaghino
Sure, porting it is not an issue. At my current status I actually have to
port it to the master (as I've written it based on the 1.0.x release
branch), but fortunately it's not a lot of code.
Thanks for the feedback as well!

On Wed, Apr 27, 2016 at 3:35 PM, Maximilian Michels <[hidden email]> wrote:

> Hi Stefano,
>
> It is a bit unfortunate for you that you have to spend additional time
> to port your code to a different branch. A PR is the way to go if a
> commit can't be simply cherry-picked.
>
> If your changes are too major then it is probably good idea just to
> include them in the next major release. Minor releases typically don't
> include new features. Now it's questionable whether this is a fix or a
> new feature :)
>
> Cheers,
> Max
>
> On Wed, Apr 27, 2016 at 3:18 PM, Stefano Baghino
> <[hidden email]> wrote:
> > Ok, thanks for the feedback.
> >
> > On Wed, Apr 27, 2016 at 3:16 PM, Till Rohrmann <[hidden email]>
> wrote:
> >
> >> Hi Stefano,
> >>
> >> in this case I think it's best if you opened a PR against the release
> >> branch so that a committer can pull it in.
> >>
> >> Cheers,
> >> Till
> >>
> >> On Wed, Apr 27, 2016 at 3:03 PM, Stefano Baghino <
> >> [hidden email]> wrote:
> >>
> >> > Hi Ufuk,
> >> >
> >> > thanks for getting back to me, I understand.
> >> > The problem with this patch in particular is that the code would be
> >> > slightly different between the 1.0.x and 1.1.x, so cherry-picking the
> >> > commit from the master branch to the release branch wouldn't be a
> viable
> >> > option, unfortunately. In this case the patch can only appear from the
> >> 1.1
> >> > release onward?
> >> >
> >> > On Wed, Apr 27, 2016 at 2:57 PM, Aljoscha Krettek <
> [hidden email]>
> >> > wrote:
> >> >
> >> > > Hi,
> >> > > I think what we did for now is this: When merging a PR onto the
> master
> >> > that
> >> > > we also consider to be required in a future release of an older
> release
> >> > > branch we cherry-pick it there and make the required changes. This
> only
> >> > > works for committers, of course, since we can just do that.
> >> > >
> >> > > I think in your case (and future cases) you can cherry-pick it on
> the
> >> > > release branch and then provide a link to your branch in the
> original
> >> PR
> >> > > such that the committer who merges it can also put it into the older
> >> > > release branch.
> >> > >
> >> > > Cheers,
> >> > > Aljoscha
> >> > >
> >> > > On Wed, 27 Apr 2016 at 13:38 Stefano Baghino <
> >> > > [hidden email]>
> >> > > wrote:
> >> > >
> >> > > > I'm currently working on FLINK-3239
> >> > > > <https://issues.apache.org/jira/browse/FLINK-3239> (support
> Kerberos
> >> > on
> >> > > > the
> >> > > > Kafka connector).
> >> > > >
> >> > > > I almost have a working prototype, however now I have a doubt
> >> regarding
> >> > > how
> >> > > > to properly merge my code (when done): right now I'm working on a
> >> > branch
> >> > > > out of the 1.0.x release branch (apparently I could not start a
> >> cluster
> >> > > to
> >> > > > test on my setup because of FLINK-3824
> >> > > > <https://issues.apache.org/jira/browse/FLINK-3824>).
> >> > > >
> >> > > > I'll have to make some minor change to adapt it to the master
> branch
> >> > > (it's
> >> > > > just a few lines of code but some of the code I had to touch have
> >> been
> >> > > > moved in the BootstrapTool.java source file); at this point I'd
> like
> >> to
> >> > > > make it available for both the master and the 1.0.x release
> branch.
> >> > > >
> >> > > > Is there any established process to handle a case like this? Is
> >> there a
> >> > > > development branch for releases? Should I perform a PR directly
> onto
> >> > the
> >> > > > 1.0.x branch? I would assume the latter is unadvisable, just
> asking
> >> if
> >> > > > that's the case.
> >> > > >
> >> > > > --
> >> > > > BR,
> >> > > > Stefano Baghino
> >> > > >
> >> > > > Software Engineer @ Radicalbit
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > BR,
> >> > Stefano Baghino
> >> >
> >> > Software Engineer @ Radicalbit
> >> >
> >>
> >
> >
> >
> > --
> > BR,
> > Stefano Baghino
> >
> > Software Engineer @ Radicalbit
>



--
BR,
Stefano Baghino

Software Engineer @ Radicalbit