Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAC27z=NKg-6--0JCi=FO0am1pk0Sn0b61Waiwn_9Kgqh_rE4Gw@mail.gmail.com>
References: 
 <CAK+0a_pfaEvq4E50BWE6SegDTQ7E5381tHNG5TWvxJbBmPGpEw@mail.gmail.com>
	<CANMXwW27f=Y9CJeDn4KV5Q_YxG=18tw6R4fVyirBBbMJgZxe6g@mail.gmail.com>
	<CAK+0a_p3nWhrxMY7nNwUbom7Efh00WxX9fTXmwU6_y2Mj4PacA@mail.gmail.com>
	<CAC27z=NKg-6--0JCi=FO0am1pk0Sn0b61Waiwn_9Kgqh_rE4Gw@mail.gmail.com>
Date: Wed, 27 Apr 2016 15:18:14 +0200
Message-ID: 
 <CAK+0a_osacnu9n4mvrGhFhqHtm4zJwBRUS0ppF2ZVuGMeLrTxA@mail.gmail.com>
Subject: Re: Backporting a patch to a release branch
From: Stefano Baghino <stefano.baghino@radicalbit.io>
To: dev@flink.apache.org
Content-Type: multipart/alternative; boundary=001a113cc51c01f6440531773eb5

--001a113cc51c01f6440531773eb5
Content-Type: text/plain; charset=UTF-8

Ok, thanks for the feedback.

On Wed, Apr 27, 2016 at 3:16 PM, Till Rohrmann <trohrmann@apache.org> 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 <
> stefano.baghino@radicalbit.io> 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 <aljoscha@apache.org>
> > 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 <
> > > stefano.baghino@radicalbit.io>
> > > 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

--001a113cc51c01f6440531773eb5--