[REMINDER] Mark the Project field in PRs

[Leif Hedstrom <zw...@apache.org>]

Hi all,

Please mark the Project field in PRs that needs to be back ported. Now that we have 2 (well, 3) LTS branches, it’s even more important that everyone helps out suggesting back ports to the 3 RMs. Some guidelines are:

You only have to suggest the PRs to the respective LTS Project branches. The RMs will triage from there, moving them to the appropriate tabs within the Project.
Serious bug fixes (misbehavior), crashes, security issues etc. These should be marked for all three LTS Projects, and it’s critical that everyone helps out identifying these PRs.
New features generally do not go into the current LTS, but, we can mark them for a minor-release branch, which will also be LTS (e.g. v8.1.0). But we make no promises of such minor-releases. So, if you feel strongly about a new feature, you can recommend it for a minor-release version.
You don’t have to make a second (or more) PR against the branches, *unless* the RM(s) asks for it. In many cases, we can cherry-pick cleanly.
If a bug is specific to just a single LTS branch, then make sure that you make the PR for that branch. In general, we always land on master first though, but for this case, that’s obviously not an option.
 Never merge something to the LTS branches yourself, that’s up to the RMs


Cheers,

— Leif

Re: [REMINDER] Mark the Project field in PRs

[Leif Hedstrom <zw...@apache.org>]

> On Jun 28, 2018, at 2:08 PM, Leif Hedstrom <zw...@apache.org> wrote:
> 
> Hi all,
> 
> Please mark the Project field in PRs that needs to be back ported. Now that we have 2 (well, 3) LTS branches, it’s even more important that everyone helps out suggesting back ports to the 3 RMs. Some guidelines are:
> 


Omg, something did a number on this email (I assume Apache’s SMTP filters…*sigh*). Here’s what I tried to say:


- You only have to suggest the PRs to the respective LTS Project branches. The RMs will triage from there, moving them to the appropriate tabs within the Project.


- Serious bug fixes (misbehavior), crashes, security issues etc. These should be marked for all three LTS Projects, and it’s critical that everyone helps out identifying these PRs.


- New features generally do not go into the current LTS, but, we can mark them for a minor-release branch, which will also be LTS (e.g. v8.1.0). But we make no promises of such minor-releases. So, if you feel strongly about a new feature, you can recommend it for a minor-release version.


- You don’t have to make a second (or more) PR against the branches, *unless* the RM(s) asks for it. In many cases, we can cherry-pick cleanly.


- If a bug is specific to just a single LTS branch, then make sure that you make the PR for that branch. In general, we always land on master first though, but for this case, that’s obviously not an option.


- Never merge something to the LTS branches yourself, that’s up to the RMs


Cheers,

— leif