FAD Goals and deliverables

Dennis Gilmore dennis at ausil.us
Thu May 14 21:44:29 UTC 2015


On Thursday, May 14, 2015 01:10:59 PM Luke Macken wrote:
> On Thu, May 14, 2015 at 08:31:55PM +0200, Kalev Lember wrote:
> > On 05/14/2015 07:45 PM, Luke Macken wrote:
> > > With regard to updates, I am in favor of getting bits out asynchronously
> > > as fast as possible. This means repos would hit first, then the various
> > > installers/trees/images trickle out shortly after as soon as they
> > > complete.
> > 
> > Would it be possible to have drpms go out asynchronously as well, so
> > that regular rpms hit the repos first and then drpms get synced out
> > later when they are ready?
> > 
> > Could be a nice speed improvement for the composes.
> 
> This would be great. I think it requires either decoupling the delta
> generation from mash, or being able to run a second pass with it that
> did deltas only. It might be possible with the current code, I'm not
> quite sure.
> 
> RPM deltas, OSTree deltas... we may want to think about making "delta
> generation" be it's own part of the process entirely.
with the current code and way it works it is really not possible to decouple. 
and its the opposite of what I want to do. The pieces need to be tightly 
integrated and cohesive. in order to get things out promptly we need to be 
able to distribute the load to produce all the pieces that are part of an 
updates push. make all the repos at once.  but do 6 repos on 6 boxes. not 6 
repos on one box in serial. fire off all the things needing those repos after 
they are done in one shot. release them all at once.  If we decouple the 
delivery I fear it will cause confusion for users. especially in the instance 
of something like heartbleed or shellshock when we say update now, but only 
some updates are out there.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150514/ef7b22a1/attachment.sig>


More information about the rel-eng mailing list