F12 0-day release updates

[Toshio Kuratomi]

On 08/19/2009 11:43 AM, Ricky Zhou wrote:
> On 2009-08-19 02:35:32 PM, Josh Boyer wrote:
>> While I do think the mirror issue is important, I'll be honest and say the
>> 'common sense' angle that Rex mentioned earlier is what I was after anyway.
>> I don't understand why we need to have 380 0-day updates of $new_crap.
> Ah, I did not pick this up from your original email.  I don't quite get
> the common sense part either though - If we have the updates, what is
> the gain of delaying them?  Would the benefit be to get the important
> updates out faster and with a less error-prone push?
> 
I'm with ricky here.  The original email says that we'd be saving
mirrors from having to serve both the release (packages and isos) on the
same day as it's serving the 0 day updates.  But if the mirrors don't
see this as a problem, then perhaps there's no reason to do it.

IIRC the pushes for 0 day updates all happen before the release day, so
it shouldn't influence the error-proneness of a particular push by that
much... It would create a larger sized post-release push when all the
new packages and enhancements are sent through.

In terms of implementation, Bodhi doesn't yet check dependencies and we
really should do that if we pull apart the bugfix vs enhancement/new
package requests.  Especially with new packages (to aid in fixing a bug)
there's the potential for a lot of dep breakage if we don't check that
the packagers specified the same update type for the new package and the
rebuilt package that now depends on it.  (I don't think packagers have
the ability to add their packages into a set with other packages built
by someone else to ensure they're all updated at once either... only
into sets that they built.)

0-day updates for new crap may not make conceptual sense if we think
that 0-day updates have a different value than any other day's updates.
 But the only difference advanced so far is that mirrors are already hit
hard on release day and 0-day updates make it worse.  Unless we know
that that's true, I don't know that we want to invest time in this.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20090819/16091ebe/attachment.bin