You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2018/08/29 23:47:28 UTC
[PROPOSAL] Dealing with two LTS releases and backports
Hi all,
since we now have two of the “new” style LTS release branches, 7.1.x and 8.0.x, it gets more problematic to deal with backport requests. The issue comes down to the fact that a PR can only have one Milestone. My suggestion is as follow:
1. The latest LTS branch has priority on doing “simple” cherry-picks, and therefore, can update the Milestone accordingly.
2. All other LTS branches will always require a second PR against that particular branch.
For #2, the RM (e.g. me for 7.1.x) is at liberty to do such a PR him/herself, however, the person proposing a Backport should be willing and expected to make the PR if asked. Therefore, if you are not willing, or interested, in making such backport PRs, please don’t propose a PR to be back ported to an older LTS branch.
I hope this makes sense?
— Leif
Re: [PROPOSAL] Dealing with two LTS releases and backports
Posted by Masakazu Kitajo <ma...@apache.org>.
> the person proposing a Backport should be willing and expected to make
the PR if asked
I proposed a backport but didn't make a PR for 7.1.x because I wasn't asked
to make it. Should I make the PR even if I wasn't asked to do so, or should
I wait for the request from RM?
Masakazu
On Sat, Sep 1, 2018 at 12:48 AM Bryan Call <bc...@apache.org> wrote:
> +1
>
> -Bryan
>
> > On Aug 29, 2018, at 4:47 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >
> > Hi all,
> >
> > since we now have two of the “new” style LTS release branches, 7.1.x and
> 8.0.x, it gets more problematic to deal with backport requests. The issue
> comes down to the fact that a PR can only have one Milestone. My suggestion
> is as follow:
> >
> > 1. The latest LTS branch has priority on doing “simple”
> cherry-picks, and therefore, can update the Milestone accordingly.
> > 2. All other LTS branches will always require a second PR against
> that particular branch.
> >
> >
> > For #2, the RM (e.g. me for 7.1.x) is at liberty to do such a PR
> him/herself, however, the person proposing a Backport should be willing and
> expected to make the PR if asked. Therefore, if you are not willing, or
> interested, in making such backport PRs, please don’t propose a PR to be
> back ported to an older LTS branch.
> >
> > I hope this makes sense?
> >
> > — Leif
> >
>
>
Re: [PROPOSAL] Dealing with two LTS releases and backports
Posted by Bryan Call <bc...@apache.org>.
+1
-Bryan
> On Aug 29, 2018, at 4:47 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Hi all,
>
> since we now have two of the “new” style LTS release branches, 7.1.x and 8.0.x, it gets more problematic to deal with backport requests. The issue comes down to the fact that a PR can only have one Milestone. My suggestion is as follow:
>
> 1. The latest LTS branch has priority on doing “simple” cherry-picks, and therefore, can update the Milestone accordingly.
> 2. All other LTS branches will always require a second PR against that particular branch.
>
>
> For #2, the RM (e.g. me for 7.1.x) is at liberty to do such a PR him/herself, however, the person proposing a Backport should be willing and expected to make the PR if asked. Therefore, if you are not willing, or interested, in making such backport PRs, please don’t propose a PR to be back ported to an older LTS branch.
>
> I hope this makes sense?
>
> — Leif
>