-----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@xxxxxxxxxx> 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. > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKTgi0ACgkQeiVVYja6o6MQ7QCgqdp+eWsl1Lhwgfb6XNwHJHDD iHsAniuut4EcnBHN+0jSsAbcoToa+Syb =lXYY -----END PGP SIGNATURE----- _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
