Additional backport labels and process improvements

Additional backport labels and process improvements

[Vasu Kulkarni]

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"

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.

Thanks

Re: Additional backport labels and process improvements

[Ken Dreyer]

On Thu, Nov 2, 2017 at 10:16 AM, Vasu Kulkarni <vakulkar@redhat.com> wrote:
> 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.

I like the additional tickets because it makes it clearer to me what
is complete and what is not. But I agree it's pretty heavyweight to do
it by hand.

I think ceph-workbench (?) automates some of this, but I think we
could automate it further.

- Ken

Re: Additional backport labels and process improvements

[Nathan Cutler]

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.

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

Re: Additional backport labels and process improvements

[Sage Weil]

On Thu, 2 Nov 2017, Nathan Cutler 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).

Sounds good to me--I added this to easily track backports that didn't have 
issues.  Once a release is out and stable it's probably not a good idea.

sage

 
> > 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.
> 
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Additional backport labels and process improvements

[Vasu Kulkarni]

On Thu, Nov 2, 2017 at 2:44 PM, Nathan Cutler <ncutler@suse.cz> 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