Re: Managing backport work for issues fixed in trunk
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
jackrabbit-oak build #5923: Errored
Build Update for apache/jackrabbit-oak - Build: #5923 Status: Errored Duration: 3003 seconds Commit: ca6f72ef90b0eb4056fb26bc92e6e165239ee192 (trunk) Author: Alexandru Parvulescu Message: OAK-3069 Provide option to eagerly copy the new index files in CopyOnRead - minor logging tweaks git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1689008 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/e8c7cde8af41...ca6f72ef90b0 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/69435230 -- sent by Jukka's Travis notification gateway
Re: Managing backport work for issues fixed in trunk
+1 On 03/07/15 15:27, Davide Giannella dav...@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
Managing backport work for issues fixed in trunk
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
