25 Oct
2019
25 Oct
'19
5:45 p.m.
Hi all, there seems to be some confusion concerning the backport tracker.
The purpose of the backport tracker is to track backports of fixes that need to
go into multiple stable branches, so they don't "fall through the cracks".
If you need to backport something from master *only* to nautilus *and no
farther*, there is no need to create tracker issues for backporting purposes.
Just open your nautilus PR with the cherry-pick [1].
(If there is already a master tracker issue, you can just mention the URL of the
nautilus backport in a comment on the tracker. You don't need to change the
status to Pending Backport or fill in the Backport field.)
Hope this helps,
Nathan
[1] of course, follow the cherry-picking rules
https://github.com/ceph/ceph/blob/master/SubmittingPatches-backports.rst#ch…
--
Nathan Cutler
Software Engineer Distributed Storage
SUSE LINUX, s.r.o.
Tel.: +420 284 084 037
3 Nov
3 Nov
9:36 a.m.
On Fri, Oct 25, 2019 at 3:45 AM Nathan Cutler <ncutler(a)suse.com> wrote:
Hi all, there seems to be some confusion concerning the backport tracker.
The purpose of the backport tracker is to track backports of fixes that need to
go into multiple stable branches, so they don't "fall through the cracks".
If you need to backport something from master *only* to nautilus *and no
farther*, there is no need to create tracker issues for backporting purposes.
Just open your nautilus PR with the cherry-pick [1].
(If there is already a master tracker issue, you can just mention the URL of the
nautilus backport in a comment on the tracker. You don't need to change the
status to Pending Backport or fill in the Backport field.)
I don't understand why we want to special-case one backport. It's
usually confusing to have two PRs cited in a tracker as that's a
catalyst for wrong backports. For example, what if Mimic is added at a
future time when the backport is realized as necessary; this happens
fairly frequently.
We already have automation (scripts) which make this pretty easy so I
don't see a point. I'd vote we don't do this.
--
Patrick Donnelly, Ph.D.
He / Him / His
Senior Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
5 Nov
5 Nov
8:09 p.m.
Hi Nathan,
On 10/25/19 12:45 PM, Nathan Cutler wrote:
Hi all, there seems to be some confusion concerning
the backport tracker.
The purpose of the backport tracker is to track backports of fixes that need to
go into multiple stable branches, so they don't "fall through the cracks".
If you need to backport something from master *only* to nautilus *and no
farther*, there is no need to create tracker issues for backporting purposes.
Just open your nautilus PR with the cherry-pick [1].
This is news to me. Has this policy been changed recently? What was the
rationale do change it? I remember I reviewed that chapter, but somehow
missed that particular detail.
(If there is already a master tracker issue, you can
just mention the URL of the
nautilus backport in a comment on the tracker. You don't need to change the
status to Pending Backport or fill in the Backport field.)
I have to agree with Patrick that I find this confusing and more error
prone. Why making that exception? If a backport is needed, a
corresponding tracker issue should be created.
Thanks,
Lenu
--
SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nuernberg
GF: Felix Imendörffer, HRB 36809 (AG Nürnberg)
1421
days inactive
1432
days old
2 comments
3 participants
participants (3)
-
Lenz Grimmer -
Nathan Cutler -
Patrick Donnelly