Backports only to nautilus do not require tracker issues
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#che... -- Nathan Cutler Software Engineer Distributed Storage SUSE LINUX, s.r.o. Tel.: +420 284 084 037
On Fri, Oct 25, 2019 at 3:45 AM Nathan Cutler <ncutler@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
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)
participants (3)
-
Lenz Grimmer
-
Nathan Cutler
-
Patrick Donnelly