Feature proposal: Extended Life Cycle Support

Jeroen van Meeuwen kanarip at kanarip.com
Tue Jul 7 23:38:50 UTC 2009


On 07/07/2009 06:39 PM, Jesse Keating wrote:
> On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote:
>> 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.
>
> Yeah, if you pick the line at say "critical" then every update would
> have a CVE, or would be bundled in bodhi with the package that had the
> CVE.  So say webkit needs updating due to a CVE, you would bundle all
> the dependent packages in the same update, and the whole update itself
> would have the CVE listing, and would have just once announcement.
>

+1, my thoughts exactly.

>> 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?
>
> Could go by time it takes to get a CVE discovered/fixed, how many are
> slipping through, karma on the updates, or just mirrormanager hits on
> the repos.
>

Agreed, these certainly are measurables. Might be a little harder to get 
some figures on, but we'd have to figure it out at some point anyway.

>>> * 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.
>
> I would think 6 months might be a little too short.  Why not give it a
> year?
>

6 months would be what we can commit to now, right now, to extend the 
life cycle of one Fedora release with. Depending on those results, and 
it's success, we might be able to 1) extend the life cycle a little 
more, and/or 2) take on a second release's extended life cycle.

>>> * 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.
>
> You're driving the feature, but don't want to be responsible for the
> feature?  odd?
>

Yes, I'm driving the feature. That doesn't mean I'm in a position to say 
anything definitive ;-)

I'm not elected, chosen, endorsed, unique in this initiative, or 
anything else, I'm just driving it. Even if I were to be assigned a 
leading position within whatever governance body should govern this 
feature/initiative, I'd not be in control -like I said before though; 
different subject ;-)

If, supposedly, FESCo (or the Board) says "hell yeah" (or just 'yes', 
which would do) to the initiative, then I suppose we put our jewels on 
the table and determine the final shape and form of the project.

>>> 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.
>
> Ok, so long as your aware that somebody or somebodies will need to
> monitor the entire package set for CVEs (something we're probably
> missing to some extent already).
>
>

And so this has to be resolved from a Fedora Project wide perspective 
rather then just be assigned to the people that co-incidentally said 
"security fixes only".

This can not and will not ever be a measurable against the ELC feature 
if the Fedora Project itself does not have the same or similar 
procedures approved and implemented. If we miss out on a few, or many, 
then we're bad. If the Fedora Project misses out on just as much, then 
we're good, within the bad, bad Fedora Project. Even though a Fedora 
release is much less likely to have security issues linger around for a 
while due to frequent updates being available for virtually any given 
application, the Fedora Project sets the standard in this case, not 
vice-versa ;-)

-- Jeroen




More information about the devel mailing list