On Fri, 12 Oct 2012, Akemi Yagi wrote:
Having understood the subdirectory method, I now say I'd prefer the
kernel-ml / kernel-lt option for 2 reasons.
One is that, as Phil said, having to update the elrepo-release package
because of kernel addition does not sound right. We want to keep it as
static as we can.
Second is from the users point of view. With the split method one
would install elrepo kernel by running:
yum --enablerepo=elrepo-kernel kernel-ml
or
yum --enablerepo=elrepo-kernel kernel-lt
The choice remains between the two as the kernel version advances,
which I think makes it easy for the users.
So, with the risk of beating a dead horse, I discussed the issues that
I think are valid with Akemi on IRC. In the end it is up to Alan and the
community to decide what direction to go, but I want to make sure we make
a decision to change for the right reasons.
----
(06:04:33 PM) dag: toracat: in the whole discussion there does not seem to be a
requirement that users can pick what stable release they want to track ?
(06:04:59 PM) toracat: dag-: hrm?
(06:05:02 PM) dag: which in my opinion is what makes the kernel-ml stable trees
compelling
(06:05:29 PM) dag: so for RHEL5 you'll be at kernel-lt-3.0, but not
kernel-lt-2.6.3x
(06:05:55 PM) toracat: I think that most people would not care to go for older
version. Only conscience users do
(06:06:00 PM) dag: if you think 'stable' you do not expect to got from 2.6.36
to 3.0 or 3.6
(06:06:38 PM) dag: well, for RHEL5 there is a very good reason to use 2.6.38 vs
3.0
(06:06:53 PM) dag: or was it 2.6.36, cannot remember anymore
(06:07:11 PM) toracat: dag-: elrepo kernels are for testing purposes , remember
? ;-)
(06:07:31 PM) dag: sure, that's another reason for me to not name them 'long
term support'
(06:07:52 PM) toracat: I do not insist on the name lt or lts
(06:07:53 PM) dag: it seems as if we condone using them
(06:08:04 PM) toracat: we can change that
(06:08:14 PM) toracat: I do not like the word support either
(06:08:39 PM) toracat: or 'long term'
(06:09:21 PM) toracat: how about 'st' for stable that originates from
kernel.org ?
(06:09:22 PM) dag: so for me there is only one use-case: sticking to a specific
version and getting the most stable release of that version
(06:09:47 PM) dag: and there is no need to differentiate in package-name for
that
(06:10:39 PM) dag: to me that is a mess, because all these kernels add up in
/boot and we've seen systems filling /boot because even if you reduce the
number of installed kernels to e.g. 3, you get 3x3 (in case you have both ml
and lt)
(06:11:45 PM) toracat: again, this is (supposedly) done by people that know
what they are doing, so they should accept the fact
(06:11:49 PM) dag: but the most compelling reason still is that someone who
wants stability, does not want the latest stable kernel necessarily, if it was
tested with 2.6.3x, and there are updates to 2.6.3x you want to stick to the
'stable' updates and not go to the latest stable release
(06:12:26 PM) dag: if people know what they are doing, they don't need any
change at all IMO
(06:12:53 PM) toracat: dag-: you sound as if you encourage use of elrepo's
kernel for production ;)
(06:12:54 PM) dag: if they don't, it's better to stick to specific version
(06:13:23 PM) dag: no, to be honest I don't think we should change as it is a
kernel for testing drivers
(06:13:51 PM) dag: but I only joined in when the decision to make a change was
almost taken, so I started from the fact that there was a need
(06:13:56 PM) dag: and we accepted that need
(06:14:58 PM) dag: but I still do not agree with the use-case that is proposed,
because it's a very specific one 'we want the _latest_ stable release', whereas
I don't see the point in that, if you want stability, you are not vouching for
the latest one (as you have no idea what it will do to your system)
(06:15:21 PM) dag: if we release a new version for a stable tree and it eats
their data, who is to blame ?
(06:15:35 PM) dag: "yes, but they ought to know what they are doing"
(06:15:47 PM) dag: they are not, because it ought to be "stable"
(06:16:07 PM) dag: nevermind that they went from 3.0.45 to 3.6.1
(06:16:13 PM) dag: you go from very stable to very unstable
(06:16:19 PM) dag: under the banner 'stable'
(06:16:50 PM) dag: (and this is not hypothetical, although it might be 3.4.34
-> 3.6.2)
(06:17:18 PM) dag: whatever Alan (or whoever helps him in the future) decides
to do
(06:17:18 PM) toracat: personally I do not want to make any changes at all. but some
users want the change to make it easy to keep "earlier" versions. They can
still do it without us doing anything.
(06:17:55 PM) dag: they cannot do it automatically, and stay current with the
"earlier" version
(06:17:59 PM) dag: and that's where my beef is
(06:18:10 PM) dag: _what_ earlier version do they want to stay current with
(06:18:46 PM) dag: it's clear that for the few they spoke up, they want the latest
(maybe without realising that very stable -> very unstable leap)
(06:19:01 PM) dag: you can only compare stability within a single version (e.g.
3.0)
(06:19:51 PM) dag: maybe I should copy&paste this discussion onto the
mailinglist, because I am afraid it's not clear to everyone
(06:20:03 PM) dag: NedSlider: there ?
(06:20:37 PM) toracat: dag-: go ahead and take the discussion to the M/L.
(06:20:50 PM) toracat: I like transparent talks :)
(06:20:56 PM) dag: ok ;-)
----
Kind regards,
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
