When to branching off the release?

[Evans Ye <ev...@apache.org>]

I saw Jun He branched off branch-1.3.  This may due to I suggested him to
proceed on the release steps[1].

Take this chance I'd like to discuss when's the right time to branch off
release.

I prefer not to actually branch off too early cause we still need to work
on several patches for 1.3 release. If we branch off this early then we
need to cherry-pick patches between branches. Although that's also doable,
we need to spend extra effort to maintain up coming patches for the master
and 1.3 branch.

My experience previously doing release is to branch off when I need to
release a RC. RC may go from RC1 to RC3 or else. So for patches coming
after RC, I'll pick them into release branch only if it fixes the issue for
release. Of course, this way works just because we've relatively smaller
scale of patches to deal with. For those large projects such as Hadoop and
HBase, strict branch control prevents various feature interferes each other.

Evans

[1] https://cwiki.apache.org/confluence/display/BIGTOP/How+to+release

Re: When to branching off the release?

[Evans Ye <ev...@apache.org>]

Agree the points you make. There's no correct answer for this. The best way
is the way that community can move faster.
So please proceed based on your professional judgement.

Jun HE <ju...@apache.org> 於 2018年8月16日 週四 下午3:47寫道：

> Thanks for sharing the thoughts, Evans.
>
> I was thinking of those reasons when branched it out:
> 1. there are no more inputs for 1.3.0 release BOM. So I assume the
> community has agreed on the scope of 1.3.0.
> 2. allow users to contribute patches beyond 1.3.0's scope without putting
> their work in queue while release is inprogress.
> 3. there should be only a small set of patches need to be merged back to
> master. In BIGTOP-3063, there are 10 blocking JIRA tickets, which should
> reflect 10 patches, required for 1.3.0. There might be more when doing the
> real job, but should be doable efforts to merge back.
>
> I fully agree the points Evans mentioned, while one thing is we need to
> branch out on a proper ground. In my view RC might a little bit late
> because of #2. Given this specific case (10 blockings JIRAs for 1.3.0) I
> ran a bit faster. :)
>
> Eager to hear you folks inputs. :)
>
>
>
> 2018-08-16 14:03 GMT+08:00 Evans Ye <ev...@apache.org>:
>
> > I saw Jun He branched off branch-1.3.  This may due to I suggested him to
> > proceed on the release steps[1].
> >
> > Take this chance I'd like to discuss when's the right time to branch off
> > release.
> >
> > I prefer not to actually branch off too early cause we still need to work
> > on several patches for 1.3 release. If we branch off this early then we
> > need to cherry-pick patches between branches. Although that's also
> doable,
> > we need to spend extra effort to maintain up coming patches for the
> master
> > and 1.3 branch.
> >
> > My experience previously doing release is to branch off when I need to
> > release a RC. RC may go from RC1 to RC3 or else. So for patches coming
> > after RC, I'll pick them into release branch only if it fixes the issue
> for
> > release. Of course, this way works just because we've relatively smaller
> > scale of patches to deal with. For those large projects such as Hadoop
> and
> > HBase, strict branch control prevents various feature interferes each
> > other.
> >
> > Evans
> >
> > [1] https://cwiki.apache.org/confluence/display/BIGTOP/How+to+release
> >
>

Re: When to branching off the release?

[Jun HE <ju...@apache.org>]

Thanks for sharing the thoughts, Evans.

I was thinking of those reasons when branched it out:
1. there are no more inputs for 1.3.0 release BOM. So I assume the
community has agreed on the scope of 1.3.0.
2. allow users to contribute patches beyond 1.3.0's scope without putting
their work in queue while release is inprogress.
3. there should be only a small set of patches need to be merged back to
master. In BIGTOP-3063, there are 10 blocking JIRA tickets, which should
reflect 10 patches, required for 1.3.0. There might be more when doing the
real job, but should be doable efforts to merge back.

I fully agree the points Evans mentioned, while one thing is we need to
branch out on a proper ground. In my view RC might a little bit late
because of #2. Given this specific case (10 blockings JIRAs for 1.3.0) I
ran a bit faster. :)

Eager to hear you folks inputs. :)



2018-08-16 14:03 GMT+08:00 Evans Ye <ev...@apache.org>:

> I saw Jun He branched off branch-1.3.  This may due to I suggested him to
> proceed on the release steps[1].
>
> Take this chance I'd like to discuss when's the right time to branch off
> release.
>
> I prefer not to actually branch off too early cause we still need to work
> on several patches for 1.3 release. If we branch off this early then we
> need to cherry-pick patches between branches. Although that's also doable,
> we need to spend extra effort to maintain up coming patches for the master
> and 1.3 branch.
>
> My experience previously doing release is to branch off when I need to
> release a RC. RC may go from RC1 to RC3 or else. So for patches coming
> after RC, I'll pick them into release branch only if it fixes the issue for
> release. Of course, this way works just because we've relatively smaller
> scale of patches to deal with. For those large projects such as Hadoop and
> HBase, strict branch control prevents various feature interferes each
> other.
>
> Evans
>
> [1] https://cwiki.apache.org/confluence/display/BIGTOP/How+to+release
>