On 6/21/2018 5:00 PM, Kevin Traynor wrote:
> Set the starting point that all commits on master branch
> with Fixes tag are backported to relevant stable/LTS branches.
>
> Of course there will be exceptions that will crop up from time
> to time that need discussion, so also add a sentence for that.
>
> This is to ensure that there is consistency between what is
> backported to stable/LTS branches, remove some subjectivity
> as to what constitutes "a fix" and avoid possible conflicts
> for future backports.
>
> Signed-off-by: Kevin Traynor <ktray...@redhat.com>
> ---
> doc/guides/contributing/stable.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/contributing/stable.rst
> b/doc/guides/contributing/stable.rst
> index 0f2f1f3..bbafc37 100644
> --- a/doc/guides/contributing/stable.rst
> +++ b/doc/guides/contributing/stable.rst
> @@ -58,5 +58,7 @@ What changes should be backported
> ---------------------------------
>
> -Backporting should be limited to bug fixes.
> +Backporting should be limited to bug fixes. All patches accepted on the
> master
> +branch with Fixes tags will be backported to the relevant stable/LTS
> branches.
> +If there are exceptions, they will be discussed on the mailing lists.
Just to highlight, there are some cased fix is not applicable for stable trees,
for that case "Cc: sta...@dpdk.org" tag explicitly omitted.
a) Fix with backport request:
Fixes: ############ ("...")
Cc: sta...@dpdk.org
b) Fix but backport not applicable/requested:
Fixes: ############ ("...")
So I agree there may be a confusion in b) if the backport is not requested or it
has been forgotten.
Is there anything we can do/change to help stable tree maintainers on this
issue?
>
> Features should not be backported to stable releases. It may be acceptable,
> in
>
