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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
