developing the "critical updates repo" plan

[Tomas Mraz]

On Pá, 2014-05-23 at 10:01 -0400, Eric H. Christensen wrote:
> On Thu, May 22, 2014 at 11:26:07AM -0400, Matthew Miller wrote:
> > See <https://fedorahosted.org/rel-eng/ticket/5886>. In short, the time to do
> > an updates compose and push (plus sync times to mirrors) severely limits our
> > ability to put out critical updates quickly. Would anyone be interested in
> > filling out a plan for an alternate repository which would use a special
> > expedited process to make ultra-critical updates available more quickly?
> 
> I dislike the idea of a separate repo for ultra-critical updates.
> Once a fix is available for a vulnerability it should, IMO, be shipped
> as soon as possible.  I know this doesn't fit into the Microsoft model
> or our model of community testing but really as soon as you go public
> with a fix you've also just notified all the "bad guys" out there to
> the vulnerability and exactly how to exploit it.  It's a race
> condition at that point.

Except the severity of various vulnerabilities is very different. And
the number of the updates that fix serious vulnerabilities is much lower
than the number of the remaining updates (including non-security ones).

> I'd much prefer to have a mechanism in place that allows these fixes
> to be pushed to the repos almost immediately (once they've been
> properly tested).  I'm not exactly sure how this can work but perhaps
> having QE tested patches packaged and ready for the embargo time would
> meet Release Engineering's criteria for testing?

You have to understand that the repoclosure process takes some time and
the metadata on the updates repository is much larger. This affects work
of release engineers and it basically prevents the mirrors to sync such
large repository too often.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)