Feature proposal: Extended Life Cycle Support

[Jeroen van Meeuwen]

On 07/07/2009 12:07 AM, Jesse Keating wrote:
> 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.
>

Like with anything else, though FY2010 is the right moment to start 
with, it has to grow organically and it will, or it won't, regardless of 
whether the timing is excellent -we would only need to take into account 
the release of EL6 from the perspective of expectations from our side.

> 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.
>

+1, no change on the consumer side may be required in order to have the 
ELC feature succeed.

> * 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.
>

I'll look into these details and try and elaborate on what I find -on 
the Feature page, so that this is (more) clear. Like I said before, I'm 
not in control and this is (going to be) a group effort so things may 
turn out a little different but we need to think about it anyway, so 
let's give it a shot beforehand. Thanks!

> * 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.
>

All, +1

> * 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.
>

If you take into account that the proposal concerns security fixes only, 
then every update has to be labeled a security update (and preferably 
have some kind of CVE/bug# attached??). We would need to think about a 
policy for that, agreed.

Without a guarantee for stable ABI/API or stable major/minor version 
numbers though some updates may have to be pushed as part of the 
dependency stack for a given security bug fix -or not. I guess we'll 
need to describe how this should be tackled exactly.

> * 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
>

The measure of success is particularly hard to state in figures. Just 
thinking about some measures of success though, it would include;

- increased participation from the Fedora side of things
- continuous flow of security updates (and bugs against EOS releases solved)
- increased consumption

and maybe there's more. Number of subscriptions to an announcement / 
errata type of mailing list maybe? Number of subscriptions to a ELC SIG 
mailing list?

> * A timeline to go with the above to review for success/failure
>

Here's where the initial proposed extension of 6 months kicks in. I 
would say our first review is what is now called "Alpha freeze" -the 
milestone where Features are checked for their readiness -whether this 
proposal ends up being an actual feature or not.

> * A responsible body behind the effort to make regular reports to
> FESCo/Board
>

This is not up to me ;-) I guess we'll hear from FESCo, on whether they 
think this is a feature, on whether they think this is in their mandate, 
on whether they think this has to go to the Board.

> Who is going to track and discover the security issues?
>

To be determined. Could be delegated to a (dedicated?) small(er) group 
of people within the SIG (to be set up) -maybe the not-so-technical??, 
or could be a responsible of each individual participating.

Kind regards,

Jeroen van Meeuwen
-kanarip