On Thu, Nov 2, 2017 at 2:44 PM, Nathan Cutler <ncutler@xxxxxxx> wrote: > Hi Vasu: > > As I understand it, the "needs-backport" label is there to enable > fast-tracking of luminous backports in the early phases of the > release/maintenance cycle, not to replace the existing > (tracker.ceph.com-based) backport tracking. > > Having separate tracker issues for backports is essential to enable > searching for backports in Redmine. For example, if you go to > http://tracker.ceph.com/projects/ceph/issues and look over on the right > you'll see the following links (among others): > > CUSTOM QUERIES > > Backports: jewel > Backports: jewel (pending) > Backports: luminous > Backports: luminous (pending) > Backports: missing release > > These are just some of the more common searches - plenty more are possible. > > Further comments in-line, below. > > On 11/02/2017 05:16 PM, Vasu Kulkarni wrote: >> >> When adding a important code or test fix to the master branch we have >> 'needs-backport' label, can we add more labels that indicate what >> branch it needs to be backported as well eg "needs-jewel-backport" , >> "needs-luminous-backport" > > > If anything, I would like to drop the "needs-backport" label after 12.2.2 > (and perhaps reinstate it when 13.2.0 is released). > >> I have personally missed couple of test backports back to branches and >> added labels would help query results right from the github interface >> and make it easier for anyone to check if there are important >> backports missing. > >> >> >> Also I am +1 on NOT creating a new tracker for every backport, this >> seems redundant work, the original tracker can still be used with few >> additional fields to indicate "fixed in master", "fixed in jewel" etc. > > > That pretty much describes the previous backporting system, which IIRC did > not work properly - many issues did not get backported because there was no > way to separately track backports or query them. > > Rather than creating additional work, the whole system is geared toward > _reducing_ work for developers. Ideally, developer work is reduced to: > > 1. flagging bugfixes for backporting, by filling out the "Backport" field > 2. change the bug status to "Pending Backport" when the master PR is merged. Thanks for the explanation, so all one needs to do is set the backport field and update status to pending backport in the original tracker and the rest is handled automatically. > > That's all. The backporting team takes care of the rest, unless we find the > backport is not easy to cherry-pick and we need to ask for your help. In any > case, developers should definitely not need to create the backport tracker > issues. That is automated (by ceph-workbench) and members of the backporting > team run the script semi-regularly (ping us if you need it done sooner > rather than later). Maybe we should look into running the script via > cronjob. . . > > HTH, > Nathan -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
