Security maintenance policy

[Baptiste Jonglez]

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.

> 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 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?

Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-adm/attachments/20201218/2dd6e55e/attachment.sig>