-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2013 11:09 AM, Phil Knirsch wrote: > On 11/06/2013 04:46 PM, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 11/06/2013 09:57 AM, Bruno Wolff III wrote: >>> On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch >>> <pknirsch@xxxxxxxxxx> wrote: >>>> >>>> But i do like the idea of well "Overlap" releases? Where most >>>> of the release would stay stable in a sense of API/ABI and we >>>> could still bring out a newer release. >>> >>> Since we have a system where multiple kernel types can be >>> installed, maybe we could use that to have a latest stable >>> kernel package and a latest long term support kernel package. >>> This will take more kernel team resources and may have some >>> issues if the graphics drivers devs want to take advantage of a >>> new feature that isn't going to be back ported to stable. >> >> Alternately, maybe this is one of the cases where we leave it to >> RHEL/CentOS to cover. For really long-term kernel support, those >> groups are much better equipped to resource it than the Fedora >> kernel team. > > Hm, so would the Fedora Server products base their releases then > on CentOS instead? Otherwise, if due to resource constraints the > Base No, please don't take that from what I said. I actually mean pretty much the opposite. In my vision, the Fedora Server should be CLEARLY the feeder channel for RHEL and CentOS server offerings (in that order; Fedora Server is the feeder for RHEL server which is the feeder for CentOS server). I merely meant that if a user absolutely needs a stabilized and *supported* (in the commercial or near-commercial sense) kernel, that they should be looking at products intended for that purpose. The Fedora Server should certainly be useful, but not on the same ten-year cycle. In general, if we settled on eighteen to twenty-four months of updates, I think that would strike a usable balance. > products can't have a longer life cycle then say, 1 year or so, > how would the Server products from Fedora be able to provide > longer lifecycles on top of that? Would they support the Base they > are using themselves? Who would do that? This is still being discussed. Please see the thread "Thoughts on Fedora Server lifecycle"[1] My plan would be for the server to have a stabilized release every eighteen months and after that an updates roll-up every six months thereafter. These updates should be more tightly controlled than the classic Fedora firehose (possibly limited to security and data-loss issues). Kernel will probably get a pass to just rebase though. If you want to discuss this, please do so on the thread I mentioned above. I'd prefer not to split the discussion. > > As at the end of the day, as Bruno already mentioned in his answer, > # of releases per year and lifetime of one product don't scale > well. They actually scale quadratic, which is even worse. So we'll > have to find some common ground and ideas on how we can manage to > support both fast moving products e.g. like Cloud or potentially > Workstation vs. slower moving and longer living ones like i expect > Server. > That's why in my lifecycle discussions I'm aiming to time update releases and preview releases alongside the Base releases. That way they should stay closely aligned. > And don't take this as an attack please, i just want to ensure > everyone is on the same page regarding our finite resources and how > we can most efficiently use them and find a solution that will work > for all involved WGs and products. > No attack > Thanks & regards, Phil > [1] https://lists.fedoraproject.org/pipermail/server/2013-November/000369.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ6escACgkQeiVVYja6o6Mn3wCgn9JiY51rv1eX0RHKMusWbCGS dBAAniKXnndc08CKlPS+5rBPof5VRqSc =7ZSc -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
