[v2] docs: add default that all fixes should be backported
Checks
Commit Message
Set the starting point that all commits on master branch
with Fixes tag should be backported to relevant stable/LTS
branches, and explain that the submitter may indicate it is
not suitable for backport.
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 <ktraynor@redhat.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Aaron Conole <aconole@redhat.com>
---
doc/guides/contributing/stable.rst | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Comments
29/06/2018 23:47, Kevin Traynor:
> -Backporting should be limited to bug fixes.
> +Backporting should be limited to bug fixes. All patches accepted on the master
> +branch with Fixes tags should be backported to the relevant stable/LTS branches,
> +unless the submitter indicates otherwise. If there are exceptions, they will be
> +discussed on the mailing lists.
>
> Features should not be backported to stable releases. It may be acceptable, in
> @@ -77,5 +80,6 @@ list.
> All fix patches to the master branch that are candidates for backporting
> should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_
> -mailing list.
> +mailing list. Absence of this CC is an indication that the patch is not suitable
> +for backporting.
We should mention that it is not a matter of Cc'ing the dpdk-stable ML,
but more importantly, a tag which remains in the git history:
Cc: stable@dpdk.org
On 06/29/2018 11:02 PM, Thomas Monjalon wrote:
> 29/06/2018 23:47, Kevin Traynor:
>> -Backporting should be limited to bug fixes.
>> +Backporting should be limited to bug fixes. All patches accepted on the master
>> +branch with Fixes tags should be backported to the relevant stable/LTS branches,
>> +unless the submitter indicates otherwise. If there are exceptions, they will be
>> +discussed on the mailing lists.
>>
>> Features should not be backported to stable releases. It may be acceptable, in
>> @@ -77,5 +80,6 @@ list.
>> All fix patches to the master branch that are candidates for backporting
>> should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_
>> -mailing list.
>> +mailing list. Absence of this CC is an indication that the patch is not suitable
>> +for backporting.
>
> We should mention that it is not a matter of Cc'ing the dpdk-stable ML,
> but more importantly, a tag which remains in the git history:
> Cc: stable@dpdk.org
>
>
Yes, you are right - fixed that in v3. The format is mentioned in
patches.rst, but it's small so I added here to be complete.
@@ -58,5 +58,8 @@ 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 should be backported to the relevant stable/LTS branches,
+unless the submitter indicates otherwise. If there are exceptions, they will be
+discussed on the mailing lists.
Features should not be backported to stable releases. It may be acceptable, in
@@ -77,5 +80,6 @@ list.
All fix patches to the master branch that are candidates for backporting
should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_
-mailing list.
+mailing list. Absence of this CC is an indication that the patch is not suitable
+for backporting.