+1 to this idea. On Mon, Oct 27, 2014 at 12:37 PM, Gwen Shapira <[email protected]> wrote:
> That makes a lot of sense. > Kafka community cut the 0.8.2 branch on Sept 30, the first RC > candidate was published last week and the release is happening today. > Important bug fixes from trunk were committed to 0.8.2 branch up until > the vote on RC started. > > So there's definitely some experience showing this can work. > > Gwen > > On Mon, Oct 27, 2014 at 12:27 PM, Jarek Jarcec Cecho <[email protected]> > wrote: > > I can see that our usual release process [1] is instructing us to > announce the intent of the release two weeks in advance before cutting the > release branch. I see a lot of value in the goal as the two weeks are there > to enable community to finish ongoing work and include it in the release. > We came up with this heads up in SVN times when cutting branch and keeping > code in sync has been relatively difficult. > > > > Nowadays I feel that this requirement to cut release branch two weeks > after announcement is more harmful then really helpful. For example Veena > is working on REST interface refactoring (SQOOP-1509) that is split into > several sub task for easier review and better tracking. As the task as > whole might not make it in two weeks for the release, I’m hesitating to > commit it’s parts. Similarly other bigger umbrella JIRAs. At one side I > don’t want to jeopardize the release itself, on the other side I don’t want > to stop all the incoming contributions. > > > > Hence I was thinking how to improve the process and I do have a > proposal. Since the original release procedure has been created, we’ve > switched to git where cutting branches and cherry-picking commits from one > branch to another is easy, I would propose the following: Let’s cut the > release branch immediately or shortly after the announcement and let’s keep > cherry-picking commits that Release Manager want’s to include in the > release while allowing ongoing possibly destabilizing work on the main > development branch. > > > > Just to be sure - I’m not suggesting to remove the two weeks heads up > period, I want to keep it. I’m just suggesting to decouple the “branching” > and “heads up”, so that we can continue the fast pace of introducing > changes without affecting the ongoing release work. > > > > Jarcec > > > > Link: > > 1: > https://cwiki.apache.org/confluence/display/SQOOP/How+to+Release+Sqoop2#HowtoReleaseSqoop2-Giveaheadsup > > > >> On Oct 22, 2014, at 6:29 PM, Veena Basavaraj <[email protected]> > wrote: > >> > >> Yes mam. I am on it, thanks for the heads up. > >> > >> On Wed, Oct 22, 2014 at 6:27 PM, Gwen Shapira <[email protected]> > wrote: > >> > >>> Thanks Veena! > >>> > >>> I'm thinking of cutting a release branch in two weeks. I hope this is > >>> enough time to resolve the blocking issues? > >>> > >>> On Wed, Oct 22, 2014 at 5:58 PM, Veena Basavaraj > >>> <[email protected]> wrote: > >>>> Thank you Gwen. I have marked the ones I have in progress for 1.99.4 > as > >>>> blockers > >>>> > >>>> On Wed, Oct 22, 2014 at 5:51 PM, Gwen Shapira <[email protected]> > >>> wrote: > >>>> > >>>>> Hi Sqoop Devs! > >>>>> > >>>>> We are starting the process to prepare for Sqoop 1.99.4 release. I > >>>>> have opened JIRA SQOOP-1607 to cover the tasks under this release. > >>>>> > >>>>> If you have any JIRA in progress and would like to include it in this > >>>>> release, please mark it as a blocker of the release JIRA and change > >>>>> the fix version to 1.99.4. > >>>>> > >>>>> Feel free to comment on the JIRA if you have any > comments/suggestions. > >>>>> > >>>>> Thanks, > >>>>> Gwen > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> *./Vee* > >>> > >> > >> > >> > >> -- > >> > >> > >> *./Vee* > > >
