Re: [elrepo] kernel/kernel-lts separation
I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett a...@elrepo.org wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. Simply have both in the elrepo-kernel repository? Akemi ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 11.10.2012 21:48, Akemi Yagi wrote: On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett a...@elrepo.org wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. Simply have both in the elrepo-kernel repository? Yep, should work fine. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 11.10.2012 21:34, Alan Bartlett wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. Thank you! -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10/11/2012 11:48 PM, Akemi Yagi wrote: On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartletta...@elrepo.org wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. Simply have both in the elrepo-kernel repository? +1 for this ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On Thu, 11 Oct 2012, Phil Perry wrote: On 10/10/12 23:30, Trevor Hemsley wrote: I'd suggest kernel30 rather than kernel-lt since the long term in this case is not that long and soon we'll be trying to work out how to change kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel happens to be. Unless the desired action is to update to the latest LTS kernel at that point? At which time a user can add an exclude for kernel-lt if they want to stay at an unsupported 3.0.y. But I take your point. What do others think? I am not in favor of renaming the packages to kernel-lts (or anything but kernel-ml). For all practical purposes, sticking to one name, but offering (sub)repositories for the different versions offers everything. So I would propose this: kernel-ml/ kernel-ml/repodata/ kernel-ml/3.0/ kernel-ml/3.0/repodata/ kernel-ml/3.8/ kernel-ml/3.8/repodata/ You can select the specific version you want to hook into, either the parent directory if you prefer to stick with the latest, or one of the major version repositories. If you have different names for different releases (or even just the ml/lts split) it becomes harder for the user to understand how this affects the system. Besides, we do not influence when a release becomes stable, and when it not longer is updated. So keeping all under the generic 'mainline' brand is much clearer. Is there a need for the proposed complexity ? -- -- 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
Re: [elrepo] kernel/kernel-lts separation
On 11 October 2012 22:23, Dag Wieers d...@wieers.com wrote: On Thu, 11 Oct 2012, Phil Perry wrote: On 10/10/12 23:30, Trevor Hemsley wrote: I'd suggest kernel30 rather than kernel-lt since the long term in this case is not that long and soon we'll be trying to work out how to change kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel happens to be. Unless the desired action is to update to the latest LTS kernel at that point? At which time a user can add an exclude for kernel-lt if they want to stay at an unsupported 3.0.y. But I take your point. What do others think? I am not in favor of renaming the packages to kernel-lts (or anything but kernel-ml). For all practical purposes, sticking to one name, but offering (sub)repositories for the different versions offers everything. So I would propose this: kernel-ml/ kernel-ml/repodata/ kernel-ml/3.0/ kernel-ml/3.0/repodata/ kernel-ml/3.8/ kernel-ml/3.8/repodata/ You can select the specific version you want to hook into, either the parent directory if you prefer to stick with the latest, or one of the major version repositories. If you have different names for different releases (or even just the ml/lts split) it becomes harder for the user to understand how this affects the system. Besides, we do not influence when a release becomes stable, and when it not longer is updated. So keeping all under the generic 'mainline' brand is much clearer. Is there a need for the proposed complexity ? Hmm . . . so what has been proposed is complex but what you propose, above, is not added complexity? Perhaps the simplest thing is for me is to type: No. No change. No nothing. No further releases from me. I've shown you all how to do it, now get on with it yourselves. :-) But I won't. I will hand the decision process over to my number two, Akemi and ask that toracat tells burakkucat what is the final outcome (of what is likely to be an extended discussion process) once it has been reached. Over to toracat. Alan. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On Thu, 11 Oct 2012, Alan Bartlett wrote: On 11 October 2012 22:23, Dag Wieers d...@wieers.com wrote: On Thu, 11 Oct 2012, Phil Perry wrote: On 10/10/12 23:30, Trevor Hemsley wrote: I'd suggest kernel30 rather than kernel-lt since the long term in this case is not that long and soon we'll be trying to work out how to change kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel happens to be. Unless the desired action is to update to the latest LTS kernel at that point? At which time a user can add an exclude for kernel-lt if they want to stay at an unsupported 3.0.y. But I take your point. What do others think? I am not in favor of renaming the packages to kernel-lts (or anything but kernel-ml). For all practical purposes, sticking to one name, but offering (sub)repositories for the different versions offers everything. So I would propose this: kernel-ml/ kernel-ml/repodata/ kernel-ml/3.0/ kernel-ml/3.0/repodata/ kernel-ml/3.8/ kernel-ml/3.8/repodata/ You can select the specific version you want to hook into, either the parent directory if you prefer to stick with the latest, or one of the major version repositories. If you have different names for different releases (or even just the ml/lts split) it becomes harder for the user to understand how this affects the system. Besides, we do not influence when a release becomes stable, and when it not longer is updated. So keeping all under the generic 'mainline' brand is much clearer. Is there a need for the proposed complexity ? Hmm . . . so what has been proposed is complex but what you propose, above, is not added complexity? I didn't know complexity was a boolean. ;-) The proposal was to add repositories and change the package name. I don't see a good reason for the second change, in fact I see many reason to not make the second change. -- -- 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
