Update/install experience

[Kevin Fenzi]

On Tue, 15 Dec 2009 11:06:33 -0500
Will Woods <wwoods at redhat.com> wrote:

...snip...

> > So, say we have 30updates/day currently. 
> 
> The average starts at around 25-30/day for the first 4 months and then
> declines to 20 or less over the life of the release. Check the Bodhi
> "Metrics" pages for some data.

Yep. 

> > With this model they would pile up and then be tested in a unit?
> > Then once a week all 210 of them would be pushed out?
> > (The once a day blorp becomes a larger once a week blorp). 
> 
> Me, I'd prefer a once-a-month drop of changes, but yes. Same amount of
> changes, just batched into larger, periodic system updates.

ok. 

> > Who is testing them "as a single unit" ?
> 
> Anyone who's interested in testing updates or getting early access to
> new fixes and features. Collectively referred to as "QA". I'm sure
> you've heard of us?

Sure. :) 

I am just worried that this is a "well, everyone will jump in and test"
type of thing. If they aren't doing so now, how does this setup
increase QA folks? Or you think the current folks in QA will be able to
test all updates in the flow if it was just organized a bit better?

How many problems or bugs are due to integration with other updates?
In the cases of new package A using new package B, wouldn't you
currently have to have both installed to test A anyhow?

> > How much time for testing would there be? If another update shows up
> > the day before the weekly push, it would be deferred to the next
> > one? How about 2 days? 3?  
> 
> Policy remains to be set here. I'd personally advocate monthly update
> pushes with a freeze at least one week before the release. Stuff that
> comes in after the freeze goes into the next push.

So, this would be essentially "12.1", "12.2"? 
Ie, minor point releases of stable release X. 

> > Would security updates hold for the next weekly push? 
> 
> Absolutely not; security updates will always go out as soon as they're
> ready. Note that this would mean that we have *much* more available
> manpower to test the security updates.

Why? Wouldn't the people who test be also testing the next monthly
blob? Or there would be no testing on it until it's frozen?

> > Or push out as they are done? If so, wouldn't that mess up in
> > progress testing? 
> 
> Not really. Security updates are usually small, targeted changes, and
> they're pretty uncommon - I don't have exact numbers but I'd estimate
> something like 10/month across the entire distribution; the number of
> security updates for a typical install will be a subset of that. 

yeah, much smaller to be sure. 

> The destabilizing effect is much, much less than (e.g.) the daily
> changes we get during the freezes for Alpha/Beta. It's a manageable
> amount.

So wait... are we talking rawhide here or stable releases? or Both?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20091215/5b14568c/attachment.bin