-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 23 May 2014 16:21:43 +0200
Tomas Mraz <tmraz(a)redhat.com> wrote:
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
Really we have only needed this once in 10 years. Doesn't mean we
should not try to fix the issues.
> I'd much prefer to have a mechanism in place that allows
> 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.
I am not trying to be rude here but your statement clearly shows you
have no idea how the push process works. There is no use of repoclosure
in the push process. how it works is as follows:
* we tell bodhi we want to push, it gives us a list of builds and says
do you want to . to which we say no.
* We sign all updates in the push process.
* we tell bodhi we want to push, but say yes do it.
* Resign the updates to make sure we catch newer updates.
* bodhi updates each update adding comments that update is being pushed
* bodhi tags the packages in koji as needed.
* bodhi mashes the tags for updates and updates-testing for each release
- mashing takes the longest period of time. creating deltarpms is one
of the most resource intensive tasks.
* bodhi updates the updateinfo.xml files
* bodhi updates some symlinks so that the script that syncs the updates
to the master mirror can sync
* once bodhi detects that the updates have hit the master mirror it
then updates bugzilla for each update
Matt's idea was to have a repo enabled by default that we can tag builds
into a special tag, mash and sync out so that we could get an update
like the openssl one out in a matter of minutes to the mirrors rather
than hours. we had a netapp upgrade that has sped up the updates
process but its still time consuming and quite fragile. Things
frequently go wrong on the bag end of bodhi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----