[PATCH 1/4] docs: securityprocess: Don't claim that we have maint branches
Michal Prívozník
mprivozn at redhat.com
Wed Mar 9 10:10:01 UTC 2022
On 3/9/22 11:06, Peter Krempa wrote:
> On Wed, Mar 09, 2022 at 10:47:45 +0100, Michal Prívozník wrote:
>> On 3/9/22 10:09, Peter Krempa wrote:
>>> The 'Branch fixing policy' paragraph claims that we have at least one
>>> actively maintained stable branch which isn't currently the case.
>>>
>>> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
>>> ---
>>> docs/securityprocess.rst | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst
>>> index adddbf76b0..fe64e94f80 100644
>>> --- a/docs/securityprocess.rst
>>> +++ b/docs/securityprocess.rst
>>> @@ -84,8 +84,6 @@ engineers on the security team.
>>> Branch fixing policy
>>> --------------------
>>>
>>> -The libvirt community maintains one or more stable release branches at any given
>>> -point in time. The security team will aim to publish fixes for GIT master (which
>>> -will become the next major release) and each currently maintained stable release
>>> -branch. The distro maintainers will be responsible for backporting the
>>> +The security team will publish fixes for GIT master (which will become the next
>>> +major release). The distro maintainers will be responsible for backporting the
>>> officially published fixes to other release branches where applicable.
>>
>> Yeah, we don't really do that, but removing is looks too harsh. Maybe
>> mention that we might create a maint branch? OTOH, a crasher we had
>> wasn't serious enough for us to create a maint branch:
>>
>> https://listman.redhat.com/archives/libvir-list/2022-March/228906.html
>>
>> So in the end, off it goes.
>
> In my previous posting of this patch (sorry forgot to mark it as v2) I
> attempted to use vague language to hint that there _might_ be a maint
> branch, but Jano pointed out that we didn't really do it for a very long
> time:
>
> https://listman.redhat.com/archives/libvir-list/2022-March/229067.html
>
> I can go with that version, but I agreed that it's unlikely to be
> maintaining those.
>
Oh, I did not realize this was v2 and in v1 you were told to remove
this. As I said, in the end I am okay with your change.
Michal
More information about the libvir-list
mailing list