* [LTP] Oldest still supported kernel
@ 2019-05-16 7:38 Petr Vorel
2019-05-16 8:35 ` Jan Stancek
0 siblings, 1 reply; 6+ messages in thread
From: Petr Vorel @ 2019-05-16 7:38 UTC (permalink / raw)
To: ltp
Hi,
do we declare oldest still supported kernel version?
According to distrowatch [1] still supported RHEL-6.9 is using v2.6.32.
Is it the oldest version we want to support or even something older?
Latest still supported stable kernel is 3.16, which is obviously too new for
enterprise distros.
It'd be nice to specify latest supported kernel (and glibc) version in docs
and remove old autotools checks (we have some checks for v2.6.25).
Kind regards,
Petr
[1] https://distrowatch.com/table.php?distribution=redhat
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] Oldest still supported kernel
2019-05-16 7:38 [LTP] Oldest still supported kernel Petr Vorel
@ 2019-05-16 8:35 ` Jan Stancek
2019-05-16 9:07 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2019-05-16 8:35 UTC (permalink / raw)
To: ltp
----- Original Message -----
> Hi,
>
> do we declare oldest still supported kernel version?
> According to distrowatch [1] still supported RHEL-6.9 is using v2.6.32.
6.9 is already EOL, but there still are other supported RHEL6 streams (up to 2024).
> Is it the oldest version we want to support or even something older?
I'd like minimum to be at least 3.10.0 / glibc-2.17 (RHEL7).
Older distros use LTP mostly for regression tests, so it might be acceptable
for users to switch to older release tag, rather than always latest master.
There's also an option, we create a "legacy" branch for old distros,
and accept only critical fixes (no new tests, rewrites, etc.). It would
be unsupported, but provide place where legacy users can cooperate.
> Latest still supported stable kernel is 3.16, which is obviously too new for
> enterprise distros.
>
> It'd be nice to specify latest supported kernel (and glibc) version in docs
> and remove old autotools checks (we have some checks for v2.6.25).
>
> Kind regards,
> Petr
>
> [1] https://distrowatch.com/table.php?distribution=redhat
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] Oldest still supported kernel
2019-05-16 8:35 ` Jan Stancek
@ 2019-05-16 9:07 ` Cyril Hrubis
2019-05-16 9:49 ` Li Wang
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2019-05-16 9:07 UTC (permalink / raw)
To: ltp
Hi!
> > Is it the oldest version we want to support or even something older?
>
> I'd like minimum to be at least 3.10.0 / glibc-2.17 (RHEL7).
>
> Older distros use LTP mostly for regression tests, so it might be acceptable
> for users to switch to older release tag, rather than always latest master.
>
> There's also an option, we create a "legacy" branch for old distros,
> and accept only critical fixes (no new tests, rewrites, etc.). It would
> be unsupported, but provide place where legacy users can cooperate.
I was trying to avoid having several active branches for LTP for several
reasons. Mainly to avoid people running old LTP on reasonably modern
kernels because they were under an impression that older release is more
stable. Hence I would like to avoid having this if possible.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] Oldest still supported kernel
2019-05-16 9:07 ` Cyril Hrubis
@ 2019-05-16 9:49 ` Li Wang
2019-05-16 11:09 ` xuyang
0 siblings, 1 reply; 6+ messages in thread
From: Li Wang @ 2019-05-16 9:49 UTC (permalink / raw)
To: ltp
On Thu, May 16, 2019 at 5:07 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> > > Is it the oldest version we want to support or even something older?
> >
> > I'd like minimum to be at least 3.10.0 / glibc-2.17 (RHEL7).
>
This minimum looks good to me.
> >
> > Older distros use LTP mostly for regression tests, so it might be
> acceptable
> > for users to switch to older release tag, rather than always latest
> master.
>
I think so. To switch to older release is a better option in that situation.
> >
> > There's also an option, we create a "legacy" branch for old distros,
> > and accept only critical fixes (no new tests, rewrites, etc.). It would
> > be unsupported, but provide place where legacy users can cooperate.
>
> I was trying to avoid having several active branches for LTP for several
> reasons. Mainly to avoid people running old LTP on reasonably modern
> kernels because they were under an impression that older release is more
> stable. Hence I would like to avoid having this if possible.
>
Yes, to maintain an old LTP branch will also cost more energy, I agree to
avoid do that too.
But one more question, if a person posts a patch to fix an older issue
which conflicts with the new kernel stuff, what should we do for that?
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190516/3c50bc3d/attachment.html>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] Oldest still supported kernel
2019-05-16 9:49 ` Li Wang
@ 2019-05-16 11:09 ` xuyang
2019-05-16 12:28 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: xuyang @ 2019-05-16 11:09 UTC (permalink / raw)
To: ltp
Hi
>
> On Thu, May 16, 2019 at 5:07 PM Cyril Hrubis <chrubis@suse.cz
> <mailto:chrubis@suse.cz>> wrote:
>
> Hi!
> > > Is it the oldest version we want to support or even something
> older?
> >
> > I'd like minimum to be at least 3.10.0 / glibc-2.17 (RHEL7).
>
>
> This minimum looks good to me.
>
> >
> > Older distros use LTP mostly for regression tests, so it might
> be acceptable
> > for users to switch to older release tag, rather than always
> latest master.
>
>
> I think so. To switch to older release is a better option in that
> situation.
>
> >
> > There's also an option, we create a "legacy" branch for old distros,
> > and accept only critical fixes (no new tests, rewrites, etc.).
> It would
> > be unsupported, but provide place where legacy users can cooperate.
>
> I was trying to avoid having several active branches for LTP for
> several
> reasons. Mainly to avoid people running old LTP on reasonably modern
> kernels because they were under an impression that older release
> is more
> stable. Hence I would like to avoid having this if possible.
>
>
> Yes, to maintain an old LTP branch will also cost more energy, I agree
> to avoid do that too.
>
> But one more question, if a person posts a patch to fix an older issue
> which conflicts with the new kernel stuff, what should we do for that?
In this situation, I think new kernel stuff has a higher priority if
older issue is not very serious.
For Oldest supported , I don't think we must specify a kernel or glibc
oldest version.
Kind Regards
Yang Xu
>
> --
> Regards,
> Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190516/8fda3284/attachment.html>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] Oldest still supported kernel
2019-05-16 11:09 ` xuyang
@ 2019-05-16 12:28 ` Cyril Hrubis
0 siblings, 0 replies; 6+ messages in thread
From: Cyril Hrubis @ 2019-05-16 12:28 UTC (permalink / raw)
To: ltp
Hi!
> For Oldest supported , I don't think we must specify a kernel or glibc
> oldest version.
Keeping special cases and workarounds for things that have been release
more than 15 years ago has a maintenance costs as well. It makes sense
to decide on oldest supported kernel/libc versions from time to time so
that we can get rid of these.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-05-16 12:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-16 7:38 [LTP] Oldest still supported kernel Petr Vorel
2019-05-16 8:35 ` Jan Stancek
2019-05-16 9:07 ` Cyril Hrubis
2019-05-16 9:49 ` Li Wang
2019-05-16 11:09 ` xuyang
2019-05-16 12:28 ` Cyril Hrubis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.