Introduce patch_acceptance_criteria

[gagath]

No description provided.

[smb49]

Though we say before that non-upstream sources will rather be frowned upon. IMO not a blocker. Just mentioning it. Thinking about it maybe one other special case might be added which has happened recently. Picking or backporting from another series (which might even be SAUCE there).

[gagath]

Added a section with example for this usecase.

[smb49]

Adding this just as a generic comment. Trying to give a little background here. The BugLink location is not strictly enforced. Just over time it got established at the first line in the description. This allows finding it more easily. In the past some had it as the first line of the additional s-o-b.

On the SRU template... the required location is the bug report. And the audience is a different one from the email submission. I am really not sure how much of this is still done but in the past any package update (and the kernel in that sense is just another package) was reviewed by a SRU review team which was not the kernel team but somewhere around foundations. What gets written there should rather be high level from a user point of view. The most mis-understood part being regression potential. There were attempts to use a more clear term. But basically what was intended there was a description which explains what it would look like if this change caused a regression. So someone doing regression testing might understand where that is coming from.
The email cover letter is rather for us/the reviewers of the patches. And having the SRU justification copied in there is an easy way to introduce things without further work. But what I would envision there in addition is explaining the fixes picked in a way that help the reviewer to understand the choices made. That include the one why a SAUCE approach was taken.

[smb49]

To me this looks good regardless of the notes I added. This is an improvement to the current situation at least.

[gagath]

Adding this just as a generic comment. Trying to give a little background here. The BugLink location is not strictly enforced. Just over time it got established at the first line in the description. This allows finding it more easily. In the past some had it as the first line of the additional s-o-b.

Reformulated "must" to "should" for the BugLink to reflect that.

On the SRU template... the required location is the bug report. And the audience is a different one from the email submission. I am really not sure how much of this is still done but in the past any package update (and the kernel in that sense is just another package) was reviewed by a SRU review team which was not the kernel team but somewhere around foundations. What gets written there should rather be high level from a user point of view. The most mis-understood part being regression potential. There were attempts to use a more clear term. But basically what was intended there was a description which explains what it would look like if this change caused a regression. So someone doing regression testing might understand where that is coming from.

Reformulated "must" to "should" for the SRU template in cover letter to reflect that.

The email cover letter is rather for us/the reviewers of the patches. And having the SRU justification copied in there is an easy way to introduce things without further work. But what I would envision there in addition is explaining the fixes picked in a way that help the reviewer to understand the choices made. That include the one why a SAUCE approach was taken.

Added some extra explanation for the cover letter section.