Feature proposal: Extended Life Cycle Support

[Jesse Keating]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090706/54436c1e/attachment.bin