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 |
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 > |
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 |
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 > |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |