[OpenAFS] On desupporting Linux 2.4

[Stephan Wiesand]

> On 26 Feb 2015, at 14:08, Chas Williams (CONTRACTOR) =
<chas@cmf.nrl.navy.mil> wrote:
>=20
> In message =
<alpine.GSO.1.10.1502251140560.3953@multics.mit.edu>,Benjamin Kaduk =
writes:
>> In particular, the threading library used by Linux 2.4, LinuxThreads, =
is
>=20
> Not completely accurate -- there are some 2.6 kernel based =
distributions
> with LinxuxThreads (although they hopefully provide NPTL as well).
>=20
>> When discussion on http://gerrit.openafs.org/#change,6947 began in =
2012,
>> it was claimed that dropping support for Linux 2.4 was premature at =
that
>> time.  It is now nearly three years later, and no progress has been =
made
>> on that change in gerrit, because of the difficulty of dealing with
>> LinuxThreads and Linux 2.4.
>=20
> RHEL4 is the last RHEL distribution to use LinuxThreads by default (at
> least to the best of my knowledge that is the case).

To the best of my knowledge: RHEL3 introduced NPTL, as the default. =
RHEL4 was the last RHEL offering LinuxThreads compatibility.

>  RHEL4 went out of
> production in 2012 and extended support is available until 2017.
>=20
> SLES9 was the last SuSE to have LinuxThreads and went out of general
> support in 2011.  I can't find any information on extended support.
>=20
> So in 2012 it was a bit premature to consider ending support given the
> upgrade cycle for some organizations.  At this point you should have
> moved on though.
>=20
>> As such, I propose that OpenAFS drop support for Linux 2.4 (and thus
>> LinuxThreads) starting with the forthcoming 1.8 release.  Because =
this is
>> a substantial change, I invite comments from the community as to =
whether
>> it is appropriate and acceptable to desupport Linux 2.4, and what the
>> scope of the impact of such a change would be.
>=20
> Since 1.6 will still be an alternative I don't see any issues.  I =
guess
> the big question is how long will 1.6 get security/bug fixes with 1.8
> released?

Good question. It will of course depend on available (human) resources, =
and my perception is that the current gradient isn't good. Ideally, I'd =
personally like to see 1.6 receiving security & critical bug fixes until =
the (non-extended) end of life of the enterprise linux distros current =
at the time of the 1.8.0 release. A reasonable minimum IMO is about one =
year after 1.8 is considered at least as mature and stable as 1.6. But =
in the end, it's the gatekeepers' decision.

And: I wonder how many such old systems are actually updated at all.