Managing backport work for issues fixed in trunk

[Chetan Mehrotra <ch...@gmail.com>]

Hi Team,

Often we consider some issue need to be merged to one of the branch
but it is not immediately required. For e.g. a practice we have
recently started is to have some new feature implemented in trunk and
then have it enabled by default there. Once we find it to be stable we
enable it by default in branches. For such work I typically create 2
issues, A (e.g. OAK-3069) for actual work and B (e.g. OAK-3073) for
tracking making it enabled by default.

Now #B has to be marked resolved in trunk but I have to keep a mental
note that this needs to be done in branch also sometime later. This
approach is error prone.

Instead if we make use of labels to mark issues which are suitable
_candidates_ for merge to branches then we can track such issues via
JIRA query and revisit them when we cut new releases on branch.

I propose we use following labels

candidate_oak_1_0
candidate_oak_1_2

For issues to be merged to 1.0 and 1.2 branches.

Then later we can query for such issues.

Thoughts?

Chetan Mehrotra

Re: Managing backport work for issues fixed in trunk

[Michael Marth <mm...@adobe.com>]

+1




On 03/07/15 15:27, "Davide Giannella" <da...@apache.org> wrote:

>On 03/07/2015 12:21, Chetan Mehrotra wrote:
>> ...I propose we use following labels
>>
>> candidate_oak_1_0
>> candidate_oak_1_2
>>
>sounds good to me.
>
>Davide
>
>

Re: Managing backport work for issues fixed in trunk

[Davide Giannella <da...@apache.org>]

On 03/07/2015 12:21, Chetan Mehrotra wrote:
> ...I propose we use following labels
>
> candidate_oak_1_0
> candidate_oak_1_2
>
sounds good to me.

Davide