Re: [RFC PATCH] docs/about/build-platforms: Refine the distro support policy

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Feb 17, 2023 at 07:47:51PM +0100, Thomas Huth wrote:
> On 17/02/2023 16.59, Daniel P. Berrangé wrote:
> > On Fri, Feb 17, 2023 at 04:55:49PM +0100, Markus Armbruster wrote:
> ....
> > The cost/benefit tradeoff of dropping the platforms entirely
> > is not obviously favourable when we don't have clear demand
> > to bump the min versions of native packages, and the cost to
> > users stuck on these platforms to build their own toolchain
> > or libraries is very high.
> 
> There's another urgent point which I completely forget to mention in my
> patch description (not sure how I managed that, since it's bugging me quite
> badly in the past weeks): We're struggling heavily with CI minutes. If we
> have to support multiple major releases for a long time in parallel, there
> will always be the desire to have all major releases also tested in the CI
> ... and honestly, we're really struggling quite badly there right now - as
> you know, we've already run out of CI minutes in January in the main
> project, and also in my forked repo I'm struggling each month. Additionally,
> it's of course additional effort to keep everything in the "green" state the
> more you have to support.
> 
> We're currently "lucky" in a sense that we're only testing one version of
> CentOS, Debian and Ubuntu right now, but there have been voices in the past
> weeks asking for more already (like we also did in the past already). I'd
> really appreciate if we could have a clearer policy here to support less at
> the same time. It would help with the pressure on the CI and the effort and
> time it takes to maintain all that stuff.

Note, we have never equated CI coverage for a platform with the
technical support for a platform. We have sooooo many combinations
which are not tested and are supported from a technical POV. It
would be nice to have comprehensive testing, but we're unlikely
to ever achieve it. IOW, lack automated CI of testing is not a
reason to delete support for a platform, it just means that we'll
rely on manual testing, and users can't have such high confidence
in the platform.


One thing we've not explored is multiple levels of CI coverage.
We could degrade certain platforms to have periodic post-merge
testing, rather than pre-merge. eg cut down gating platform
combos, but then once a week run a broader CI pipeline. This
would allow regressions to creep in periodically for more obscure
combinations, but still give us an alert so we can fix them before
release.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|