Linux Support Policy

[Mark Waite]

I've submitted a draft pull request that proposes a Linux support policy.  It is modeled after the Windows support policy with 4 tiers.

When we adopted the Windows Support Policy, we discussed it here in the developer mailing list and then created the pull request that included the comments and concerns from the mailing list.  I can retract the pull request if that is the preferred technique or we can discuss the proposal through the pull request.

The pull request won't be merged until discussion has concluded and a Jenkins governance board meeting has approved that it can be published.

The proposed levels are:

Level 1 - Full support - amd64 Linux versions supported by Debian, Red Hat, SUSE, and Ubuntu and Linux versions used in official Docker images

Level 2 - Supported - 64 bit Linux versions that use deb and rpm formats (amd64, arm64, s390x, ppc64le)

Level 3 - Patches considered - 32 bit Linux, other architectures, preview releases

Level 4 - Unsupported - Operating systems no longer supported by their provider

Comments, concerns, or worries are welcomed.

This is intentionally specific to Linux, without considering other Unix systems like macOS, FreeBSD, OpenBSD, or NetBSD.

Mark Waite

[Gavin Mogan]

I'm not super comfortable with the word support, as it sets a level of
expectations with users and corporations about what we provide as to
help. We make no guarantees anyone will help you with a linux or linux
+ jenkins issue, but we will say we've fully run our automated test
suite on those environments?

I'm just not entirely sure what the point of this policy is, what
problem is it solving?

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bedea2f5-141a-43ac-87e0-16faa90d3b2en%40googlegroups.com.

[Mark Waite]

On Friday, January 14, 2022 at 11:58:24 AM UTC-7 Gavin wrote:

I'm not super comfortable with the word support, as it sets a level of
expectations with users and corporations about what we provide as to
help. We make no guarantees anyone will help you with a linux or linux
+ jenkins issue, but we will say we've fully run our automated test
suite on those environments?

I'm just not entirely sure what the point of this policy is, what
problem is it solving?

I'm trying to describe current practices in a way that readers can understand current levels of involvement from the contributors to the project.  We build and test on Ubuntu machines and have built and tested on Debian machines previously.  We deliver Linux installers for deb, Red Hat rpm, and SUSE rpm.  We run automated tests of the deb and Red Hat rpm installers.

We do not actively test Jenkins with other Linux distributions like Amazon Linux 2 (uses the Red Hat rpm), Devuan (uses Debian but with System V init rather than systemd), Oracle Linux (uses the Red Hat rpm), and many others.  If issues are detected with a distribution that is not in the "fully supported" list, I want the reader to understand that it will probably receive less attention than an operating system on the "fully supported" list.

I've not seen issues from the Windows support policy page that has used similar phrasing for 18+ months.  I'm open to other phrasing, but I'm not clear what that alternate phrasing might be.

Mark Waite

[Oleg Nenashev]

I am in favor of having a support policy in general, as long as it is explicit there is no SLA. The original Windows support page and the new Linux one says "we intend to fix the reported issues timely." even for Tier 1. IMHO it is okay.

We could make an explicit disclaimer if not enough @Gavin

Also, should it actually be Unix or Linux?