needs-backport label on github/ceph/ceph

needs-backport label on github/ceph/ceph

[kefu chai]

i noticed that we have a new label named "needs-backport" [0]? could
you shed some light on how we are supposed to use it? i thought we
were going to cherry-pick all PRs with this label merged after the
luminous was forked. but seems we are still marking PRs should be
included by luminous with the "luminous" milestone. so i have no clues
now =(


cheers,

---
[0] https://github.com/ceph/ceph/pulls?q=label%3Aneeds-backport

Re: needs-backport label on github/ceph/ceph

[John Spray]

On Tue, Aug 22, 2017 at 4:09 PM, kefu chai <tchaikov@gmail.com> wrote:
> i noticed that we have a new label named "needs-backport" [0]? could
> you shed some light on how we are supposed to use it? i thought we
> were going to cherry-pick all PRs with this label merged after the
> luminous was forked. but seems we are still marking PRs should be
> included by luminous with the "luminous" milestone. so i have no clues
> now =(

I'm curious too -- I believe the authoriative way to mark something
for backport is in a tracker ticket, so a separate label probably
isn't needed?

John

>
> cheers,
>
> ---
> [0] https://github.com/ceph/ceph/pulls?q=label%3Aneeds-backport
> --
> 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: needs-backport label on github/ceph/ceph

[Nathan Cutler]

On 08/22/2017 05:12 PM, John Spray wrote:
> On Tue, Aug 22, 2017 at 4:09 PM, kefu chai <tchaikov@gmail.com> wrote:
>> i noticed that we have a new label named "needs-backport" [0]? could
>> you shed some light on how we are supposed to use it? i thought we
>> were going to cherry-pick all PRs with this label merged after the
>> luminous was forked. but seems we are still marking PRs should be
>> included by luminous with the "luminous" milestone. so i have no clues
>> now =(
> 
> I'm curious too -- I believe the authoriative way to mark something
> for backport is in a tracker ticket, so a separate label probably
> isn't needed?

Maybe it was added to accommodate/facilitate a "fast-track" backporting 
process for the early stages of the luminous release cycle?

ISTR that jewel v10.2.1 went very quickly and some of the backports did 
not "cross all the t's and dot all the i's" wrt the sanctioned 
backporting process. Maybe something like that is a possibility for 
luminous as well? (I would welcome it.)

It could work like this: if a PR is marked "needs-backport", the 
developer who merges the PR would be responsible for ensuring that the 
commits are cherry-picked to luminous and marking the tracker, if any, 
"Resolved" with a note that the backport is already done.

Nathan

Re: needs-backport label on github/ceph/ceph

[kefu chai]

On Wed, Aug 23, 2017 at 12:00 AM, Nathan Cutler <ncutler@suse.cz> wrote:
> On 08/22/2017 05:12 PM, John Spray wrote:
>>
>> On Tue, Aug 22, 2017 at 4:09 PM, kefu chai <tchaikov@gmail.com> wrote:
>>>
>>> i noticed that we have a new label named "needs-backport" [0]? could
>>> you shed some light on how we are supposed to use it? i thought we
>>> were going to cherry-pick all PRs with this label merged after the
>>> luminous was forked. but seems we are still marking PRs should be
>>> included by luminous with the "luminous" milestone. so i have no clues
>>> now =(
>>
>>
>> I'm curious too -- I believe the authoriative way to mark something
>> for backport is in a tracker ticket, so a separate label probably
>> isn't needed?
>
>
> Maybe it was added to accommodate/facilitate a "fast-track" backporting
> process for the early stages of the luminous release cycle?
>
> ISTR that jewel v10.2.1 went very quickly and some of the backports did not
> "cross all the t's and dot all the i's" wrt the sanctioned backporting
> process. Maybe something like that is a possibility for luminous as well? (I
> would welcome it.)
>
> It could work like this: if a PR is marked "needs-backport", the developer
> who merges the PR would be responsible for ensuring that the commits are
> cherry-picked to luminous and marking the tracker, if any, "Resolved" with a
> note that the backport is already done.

thank you, Nathan! that makes sense.

-- 
Regards
Kefu Chai

Re: needs-backport label on github/ceph/ceph

[Sage Weil]

On Tue, 22 Aug 2017, John Spray wrote:
> On Tue, Aug 22, 2017 at 4:09 PM, kefu chai <tchaikov@gmail.com> wrote:
> > i noticed that we have a new label named "needs-backport" [0]? could
> > you shed some light on how we are supposed to use it? i thought we
> > were going to cherry-pick all PRs with this label merged after the
> > luminous was forked. but seems we are still marking PRs should be
> > included by luminous with the "luminous" milestone. so i have no clues
> > now =(
> 
> I'm curious too -- I believe the authoriative way to mark something
> for backport is in a tracker ticket, so a separate label probably
> isn't needed?

I added it for tagging PRs that don't have a tracker ticket open (e.g., 
small usability cleanups that weren't bugs).  It's a bit less overhead 
than opening a ticket and going through the usual process.

It was helpful when every third PR had to be cherry-picked to 
luminous; that will be less common once the release is out the door.

sage

Re: needs-backport label on github/ceph/ceph

[Abhishek Lekshmanan]

kefu chai <tchaikov@gmail.com> writes:

> On Wed, Aug 23, 2017 at 12:00 AM, Nathan Cutler <ncutler@suse.cz> wrote:
>> On 08/22/2017 05:12 PM, John Spray wrote:
>>>
>>> On Tue, Aug 22, 2017 at 4:09 PM, kefu chai <tchaikov@gmail.com> wrote:
>>>>
>>>> i noticed that we have a new label named "needs-backport" [0]? could
>>>> you shed some light on how we are supposed to use it? i thought we
>>>> were going to cherry-pick all PRs with this label merged after the
>>>> luminous was forked. but seems we are still marking PRs should be
>>>> included by luminous with the "luminous" milestone. so i have no clues
>>>> now =(
>>>
>>>
>>> I'm curious too -- I believe the authoriative way to mark something
>>> for backport is in a tracker ticket, so a separate label probably
>>> isn't needed?
>>
>>
>> Maybe it was added to accommodate/facilitate a "fast-track" backporting
>> process for the early stages of the luminous release cycle?
>>
>> ISTR that jewel v10.2.1 went very quickly and some of the backports did not
>> "cross all the t's and dot all the i's" wrt the sanctioned backporting
>> process. Maybe something like that is a possibility for luminous as well? (I
>> would welcome it.)
>>
>> It could work like this: if a PR is marked "needs-backport", the developer
>> who merges the PR would be responsible for ensuring that the commits are
>> cherry-picked to luminous and marking the tracker, if any, "Resolved" with a
>> note that the backport is already done.
>
> thank you, Nathan! that makes sense.

Can we ensure that we always have a tracker issue when there is a
pending backport label, makes it easier to track these.

-- 
Abhishek Lekshmanan
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Re: needs-backport label on github/ceph/ceph

[Nathan Cutler]

> Can we ensure that we always have a tracker issue when there is a
> pending backport label, makes it easier to track these.

I thought the whole idea was to make a "fast-track" backporting process 
which would not require a tracker for each backport. With the 
understanding that it would only be used early in the release cycle. If 
a backport is "fast-tracked" the merging developer would be responsible 
for doing and merging the cherry-picks.

If there is a tracker, of course, then the normal workflow would apply 
regardless of the presence/absence of this "needs-backport" tag.

Right?

Nathan

Re: needs-backport label on github/ceph/ceph

[Abhishek Lekshmanan]

Nathan Cutler <ncutler@suse.cz> writes:

>> Can we ensure that we always have a tracker issue when there is a
>> pending backport label, makes it easier to track these.
>
> I thought the whole idea was to make a "fast-track" backporting process 
> which would not require a tracker for each backport. With the 
> understanding that it would only be used early in the release cycle. If 
> a backport is "fast-tracked" the merging developer would be responsible 
> for doing and merging the cherry-picks.
>
> If there is a tracker, of course, then the normal workflow would apply 
> regardless of the presence/absence of this "needs-backport" tag.

Sure makes sense, sorry, didn't see Sage's mail (until after I sent
mine), yeah it does make sense for until the first backport release or
so for using this tag.

-- 
Abhishek Lekshmanan
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)