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