Hi All,
In my world, 5 years is short. It use to take me 3 years to get a stable
enough uBuntu kernel to patch in my changes. The 14.0x LTS 4.4.x kernel
never became stable enough.
I will be looking to the industrial Linux at 10 to 25 years for kernels
for the future.
For most of the software I would be looking at no less than 5 years long
term support where longer term support (10+ years) is not available.
In my experience, most industry considers 5 years far too short. That is
why Windows XP was such a success. Its longevity.
Where I work they still run AT bus PCs with 2.4 series kernel because
the upgrade cost is considered prohibitive. It is not just the PC and
bespoke software. It is all the bespoke hardware that goes with it. When
the hardware becomes totally unsupportable there will be a long loss of
service as totally new software and hardware will be needed. There are
no budgeted funds for obsolescence.
Please reconsider the 3 years you proposing. 5 years should be the norm
and extra years for those prepared to pay for the privilege.
Release years. Every two years works OK. Beware of 2037. In 2037
everyone will be updating things and by 2038 it will be a mess (unix
time). Like last time (Y2K) management will, if possible, leave it to
the lasts microsecond. I suspect that most 32bit systems will be fine as
they will just ignore the sign bit. It will be all these new 64bit
systems that will fail miserably (sign extending their filing system
time stamps).
Regards
Mark.
On 29/07/2021 00:53, Micah Snyder (micasnyd) via clamav-users wrote:
Hi All,
For the past couple of months I’ve been promoting the idea of having
Long Term Support (LTS) feature releases for ClamAV within internal
Talos communications.
For the purposes of this discussion:
* A “feature release” is a version starting with MAJOR.MINOR.0 to
include all PATCH versions. I.e. ClamAV 0.103.0, 0.103.1, 0.103.2,
and 0.103.3 are all within the same “feature release”.
* A “patch version” is a specific MAJOR.MINOR.PATCH version. E.g.
0.103.4 would be the next “patch version” in the 0.103 “feature
release”.
My interest in starting an LTS program came about because we have been
getting (understandable) pressure from management to have shorter
development times for feature versions with more targeted feature sets.
What this means is that you would see more frequent feature releases,
possibly as many as ~5 per year. Some of the features in a given
feature release would be things the community cares about, while others
may be by request of a different team within Talos or Cisco.
But I couldn’t in good conscience start pumping out new feature releases
every 2-4 months and expect everyone to keep up. And at that rate it
would not be possible for us to make critical patch versions for every
feature release within the two years, or even one year. So in order to
get features out faster it became clear to me that we will need to
define /specific feature release/ for which we promise to backport
security fixes for /some amount of time/.
This raised a few obvious questions:
* Which feature release do we start with?
* Do we have to continue serving signature database content to every
patch version in an LTS release?
* How often should we select a new feature release for LTS?
* How long is “long term support” anyways?
We’ve been talking about this off and on for the past couple of month.
This is what I came up with….
*/Which feature version do we start with?/*
We /had/ initially settled on 0.104 as the first LTS version, for
basically two reasons:
-Joel really wants to make sure people have the latest freshclam
features, particularly those found in 0.103.2 and 0.103.3, to reduce
bandwidth cost.
-I don’t want to keep fixing glitchy autotools package detection issues
for years to come.
But after seeing the (very much unexpected) reaction to the switch
CMake… it’s clear to me now that *we need to start the LTS program with
**0.103*.
*/Do we have to continue serving database content to every patch version
in an LTS release?/*
No.
LTS means that we will promise to continue providing patch versions for
a given feature release.
I.e. you will get critical fixes in 0.103.4, 0.103.5, 0.103.6, etc. as
needed until End of Life (EOL) for the 0.103 feature release.
*I need to stress* *that* it doesn’t mean people should /or will be
allowed/ to continue using vulnerable or otherwise problematic versions
such as 0.103.0 and 0.103.1 just because they belong to an LTS feature
release. /We will reserve the right to at some point begin to block
older patch versions like 0.103.0 from downloading databases to force
people to use newer patch versions./**
//
*/How often should we select a new feature release for LTS?/*
Some products, like Ubuntu, do a new LTS ever 2 years with support for 5
years. 2 years feels like a long time but, as much as I want to get
people using the latest features, our team is pretty small. The more
frequently we a release for long term support, the more work each
security release will be. We would be required to create and test a new
patch version for the current stable feature release plus a collection
of LTS releases. If we did an LTS every year, that would be too much.
I think 2 years is probably a good number.
//
*/How long is “long term support” anyways?/*
As noted above and elsewhere, Ubuntu and RHEL/CentOS support LTS
versions for 5 years. That’s a long time, and more than our team could
agree to.
After a bunch of discussion, we think 3 years is a good number.
/To summarize/, I’m proposing a Long Term Support (LTS) program for
ClamAV starting with the 0.103 feature release. This means:
1. We will promise to provide critical patch versions (0.103.4, .5.,
.6, etc.) as needed until the LTS end-of-life.
This does not mean that the original 0.103.0 or other problematic
patch versions within the series will continue to “work”.
Users MUST be willing to upgrade to newer patch versions within a
given LTS release.
2. Each LTS release would be supported for three (3) years from the
first (.0) version.
/0.103.0 was published in August 2020/. This means we would
continue to provide critical patch versions for 0.103 until August
2023.
3. We will aim to select a new LTS feature release every two (2) years.
With 0.103 starting the LTS program, that means that whichever
feature release is to be published near abouts August 2022 is the
likely candidate for the next LTS release.
4. When a security fix is required, we’ll publish a patch version for
the latest feature release as well as all affected active LTS
feature releases.
5. We will document the LTS policy and add an end-of-life version table
to https://docs.clamav.net/faq/faq-eol.html.
I would like your feedback.
Respectfully,
Micah
Micah Snyder
ClamAV
Talos
Cisco Systems, Inc.
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
