On Sat, 2009-07-04 at 23:58 +0200, Jeroen van Meeuwen wrote: > I wanted to draw your attention to a feature I've proposed for Fedora > 12, mysteriously called Extended Life Cycle. > > You can find more details at > https://fedoraproject.org/wiki/Features/Extended_Life_Cycle When we talked at Berlin some of the details were a bit different, and I'll get to some of what I talked about there later in this email. First off, I think this is different from Fedora Legacy, or has potential to. Legacy had a few very key fail points. 1) it was opt in. Users had to know about it and actively enable it. 2) it was completely done outside of the Fedora infrastructure. 3) Fedora's popularity was very hit and miss, the type of people that would best use a Legacy like service were too burned to give any Red Hat related offering a shot. 4) RHEL4 (and its clones) were new enough for most of the people that would use this service, and thus they went that way. A longer Fedora sounds really great now, particularly because EL 5 and its clones are rather long in the tooth. How good it will sound once EL6 is out is a different matter. I think the popularity will wax and wane as the EL release cycles go. I think for this to succeed as an effort, which there is some folks whom state a need, I think there needs to be a few key things. * Automatic use. Users shouldn't have to opt-in to something different, they should have to do nothing and continue to get the updates. * A clarification of "security" updates. Will local denial of service (aka crash bug) be fixed? Local root escalation? Remote denial of service? Remote escalations? The amount of updates you will have to do will change dramatically based upon what level of security updates you want to target. http://www.redhat.com/security/updates/classification/ may help and may be familiar to the type of users you are targeting. * All or nothing. Either updates for whatever class you clarify from above will be provided for all packages, or none. There can't be any vagueness here. * A way to prevent updates that do not match the above from being pushed. Ambiguity in what can be expected can cause confusion and fear. I realize that we have ambiguity during the normal release cycle and that is maintainer driven, but an extended support effort like this should clarify what will be offered. * A measure of success. Some way that you can decide whether or not the "Feature" has been a success and should be continued, or whether it is a failure and shot not be continued, or should be attempted in some other way * A timeline to go with the above to review for success/failure * A responsible body behind the effort to make regular reports to FESCo/Board Some other interesting problems: Bugzilla spam. If we keep the release open for random bug filing, we have no good way of telling bugzilla that only specific users should get bugs for specific releases of Fedora. Ownership is at a product level, not at the product version level. So maintainers will get all the spam, and have to forward it along to whomever is handling security updates. Who is going to track and discover the security issues? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
