-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/21/2013 09:18 AM, Josh Boyer wrote:
Hi All,
I've seen a lot of discussion around release cycles and lifetimes.
I've not heard any specific requests for what impacts any of the
current ideas would have to the kernel, but that doesn't mean they
won't be coming. We should probably start thinking about various
things we can support today, what we could possibly support in the
future, and what we'd need to do it. I've CC'd the Product
liaisons so they can see this. Please keep them on CC.
The first scenario I can think of is probably some kind of
"long-term" release. Exactly what long-term means here is
undefined, but we already support a Fedora release for 13 months or
so. We do that today with rolling kernel releases. We could
possibly continue, but I expect the Products to desire something
more "stable".
What that implies is that we'd likely need to base on an upstream
longterm kernel. That means:
1) No new kernel features. 2) No new hardware enablement outside of
things acceptable for an upstream longterm commit (basically just
adding a new USB/PCI id to an existing driver). 3) Bugfixes will
primarily come from the upstream longterm tree 4) There will be no
alternative kernels supported on the Fedora longterm release. 5)
There are no guarantees on bugfixes, response time, etc.
If any of the above are desired, people are better off picking an
Enterprise distro where you have contracted support.
So if that's the case, the feasibility of this is going to hinge a
lot on timing. I would think from a kernel perspective we'd know
up-front when a Fedora longterm was going to happen, and we'd try
and align that release with the newest official longterm stable
kernel. Those are maintained for 2 years, which seems to be a good
fit for a Fedora longterm release. Any longer than that and you're
back in the Enterprise space again.
The second scenario I can think of is products with mismatched
release cycles. E.g. Server doing a 2 year longterm and developing
the Server.next release on top of Base, which releases every 6
months. Or Workstation doing a release once a year while Base
moves every 6 months. Etc. It's hard to come up with a concrete
scenario since none of the products have gotten this far. It's
worth noting that FESCo is basically disallowing this for the first
releases, so this is a secondary concern.
I would propose that for Base, we continue our current method of
rebasing with each kernel release. That has been working very
well for the past few Fedora releases, and gets us the most "bang
for the buck" in terms of features, hardware support, and fixes. A
year long release for e.g. Workstation would likely also desire the
newer support and features, so they could probably just update
their kernel in the same way. This keeps our maintenance costs
down to today's and gives products flexibility.
In the Server LTS + Server.next development scenario, I would
expect the LTS to use the longterm kernel as suggested above which
means whenever they cut over to LTS mode it would need to coincide
with an upstream longterm kernel. That would be something we have
to watch and plan for. Server.next would continue to use Base
until it was ready to cut over and repeat. I hope that makes
sense.
Would you believe I was typing up an email to you earlier today (that
I didn't finish) to suggest this exact thing?
My thought was that we would naturally tie the Fedora Server release
cycle to the Kernel LTS cycle, as you suggest. This should keep the
maintenance costs on the kernel down.
I suspect that Server is the only one of the three products for which
the LTS kernel makes sense, though. Both the Workstation and Cloud
projects are likely going to want to take advantage of newer
capabilities far more often.
In terms of people, the only major change I see would be the
longterm addition. That might be something we can tuck, but having
additional QA and maintainer resources would allow us to cover
development and support better. If there was any major deviation
in which kernel was used in the various products, we'd likely need
either the Product teams themselves to pick up maintenance or
additional people on the kernel team to handle that. The desire
here is to keep the kernel common among as many Products and
releases as we can.
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?
This is mostly just some thoughts I've had on the topics so far.
Let me know what you all are thinking and please ask questions or
propose alternatives as you see fit.
josh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlKOPRQACgkQeiVVYja6o6NEYgCfReM2infj7YK30IA6BLx3G7OC
lgcAniXhJs28TzXTZ+oHagDPbHMiMPo2
=+EUR
-----END PGP SIGNATURE-----