Security maintenance policy

[Hauke Mehrtens]

On 12/18/20 11:06 PM, Baptiste Jonglez wrote:
> On 17-12-20, Hauke Mehrtens wrote:
>> I would propose the following policy:
>> 1. Latest release (currently 19.07) gets full support (security bugs and
>> other bugs are getting fixed)
>> 2. The release before that (currently 18.06) gets only security updates if
>> needed.
>> 3. All older release (currently 17.01, 15.05) are completely unsupported and
>> we do not provide any fixes, even for severe security problems.
>>
>> As soon as a new major release is finally tagged (not the first RC), all the
>> existing branches are moving one step lower.
> 
> +1, this sounds good to me, it's simple to understand.
> 
> A downside is that people cannot know in advance at which date a release will
> become completely unsupported.  To ensure that, we could change 2. to:
> 
>    2. A release branch receives security updates for 2 years after its initial release
> 
> Of course, if we *do* release every 6 months (I also don't think it's
> realistic), that would mean lots of parallel releases to support.

This change sounds better. We will probably have to support it for less 
time compared to my proposal based on the past experience and I saw much 
less interest in supporting an old version when we already have a new 
stable branch.

>> As we currently do a release every 1 to 1.5 years this means we have to
>> support every release for about 3 years.
>> We also have to provide the build infrastructure to be able to do an release
>> for 3 years after the XX.XX.0 version and have 3 releases in parallel to
>> master at maximum.
> 
> 18.06.0 was out in July 2018, so it's a bit less than 3 years in
> practice.  Also, 18.06.X has received much less attention since ~March 2020
> (19.07.0 came out in January 2020).  All that to say that 3 years is a
> long time and it's difficult to ensure through "free" work.

I agree with you.

>> I think it is unrealistic to assume we will do a new major release every 6
>> months, we tried this multiple times, but this never worked.
>>
>> We could also reduce the 2.) policy and do the security only support for 6
>> months after the next major release was done.
>>
>> If someone needs longer support, some paid model like the Debian LTS model
>> would be nice, so developers would get paid for an extended LTS support but
>> still can release the code publicly.
> 
> +1, it would probably be sustainable because some companies would be ready to pay.
> 
> This needs some thinking about:
> 
> - only openwrt team members, or anybody?
> - only for core openwrt, or also include LuCi, package feeds?
> - it should include time spent on reviewing patches for old releases, and
>    maybe even time spent on infrastructure?
> - who gets to decide what the priorities are?

We should discuss this in more detail if a company is interested in 
this. I just wanted to mention this if someone starts complain that they 
need support for their product based on OpenWrt. The results of the 
Debian LTS project are public to everyone. It is financed by multiple 
companies and the developers are paid per hour of actual work. This is 
managed by a company.

Hauke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-adm/attachments/20201219/e26142e7/attachment.sig>