-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/25/2013 11:57 AM, Josh Boyer wrote:
On Mon, Nov 25, 2013 at 11:46 AM, Stephen Gallagher sgallagh@redhat.com wrote:
What do you think you would need for a resource here, if we make the following assumptions (not final, just ideas):
- The Fedora Server stable release is the only Product
running the LTS kernel
- We limit updates to the kernel package in the stable
release to a regular schedule (excepting only security fixes). See my lifecycle proposal plan for how I suggest we might want to do Fedora Server 1.1, 1.2, etc. releases. If we limited kernel patch roll-ups to a six-month cycle, would that reduce your resource needs?
I'm not quite following you on this part.
If Server is doing an LTS, it follows the latest upstream longterm kernel. We agree there. Which means that whenever upstream longterm does a release (which is actually pretty regular), we do a kernel update containing that. E.g. 3.13.1, 3.13.2, 3.13.3, etc. Those are typically on the order of 1-3 weeks between releases. Not months. They also contain more than security fixes, but they are limited to _fixes_ not features. I would think that's acceptable.
Ok, I was actually trying to make your life easier by reducing the number of updates you had to package up, but if it's easier to follow the 1-3 week schedule than a 3-6 month schedule, I'm not going to argue.
My point was more that you might be underestimating the number of fixes (some of which are CVE fixes) that flow into even the longterm kernels. Yes, most of them are fairly minor, but some of them aren't. So we'd bump and build, but not necessarily file updates unless there's something important.
I was kind of thinking that we actually might want to offer two choices of kernels in general: the classic 'kernel', which is kept at the latest upstream release and 'kernel-stable', which follows the stable release. The Server would tie itself to 'kernel-stable', but
Nope. That would require two kernel SRPMs or some horrible abomination of packaging two different trees in the same SRPM. That leads to even more work for us, unless...
theoretically a user could opt to install the 'kernel' package instead, if they had an urgent need for a new feature. (This operation would not be recommended or supported in any way by the Fedora Server product, just providing live rounds for shooting oneself in the foot).
Then they can just install the kernel from the Base repo, which would be this classic kernel you referred to above. I'm not at all fond of doing that same work twice in Server LTS just because people want Server-LTS-except-for-the-kernel. This is yet another use case that is served by Enterprise distros already, so doing anything beyond "use Base" is (imo) out-of-scope here. If the Base kernel somehow becomes incompatible with Server LTS userspace (which would be very rare), then they get to keep all the broken pieces.
Sorry, "use Base" was what I was essentially trying to say here. I think we're pretty much in agreement. I did *not* mean we should build an extra unstable kernel for the Server.