Product lifecycles and kernel impacts

[Josh Boyer]

On Mon, Nov 25, 2013 at 11:46 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>>> What do you think you would need for a resource here, if we make
>>> the following assumptions (not final, just ideas):
>>>
>>> 1) The Fedora Server stable release is the only Product running
>>> the LTS kernel
>>>
>>> 2) 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.

josh