Development to Official

[Kevin Kofler]

Christopher Aillon <caillon <at> redhat.com> writes:
> What's a few days extra?  A few days of extra testing for F9 on the 
> features that didn't quite make it into F8, such as intlclock.  Or a few 
> days of testing some bugfixes, such as NetworkManager fixes, in F9 
> packages before they make it in to F8-updates.  With all the "few days 
> here" because of test freezes, we've maybe lost a month or so of testing 
> in the F8 cycle -- out of 6 months.

I have one possible suggestion (at least for F9+, it's probably too late for 
F8) for this problem (maybe worthy of its own thread? Anyway, here it is):
* make updates-testing available early, e.g. as soon as builds for the new 
release go to dist-f*-updates-candidate,
* if a direct push to stable was requested, but the stable updates haven't been 
opened yet, make the updates go through testing anyway, and automatically push 
them as 0-day stable updates unless they have been unpushed or the move request 
revoked. (Alternatively, the stable updates could be opened early too, but it 
just doesn't make sense to me to declare updates "stable" before the release.)
* Of course, start doing regular test update pushes for the new release as soon 
as updates-testing is opened.

The advantages and drawbacks of this approach as I see them:
+ 0-day updates would be able to get some testing.
+ Rawhide users would be able to reliably get security updates even during the 
freeze. (Right now, they only show up in Rawhide if tagged f8-final.)
- Less testing for the packages which show up in the frozen release (because 
testers will be split between f*-final and f*-final + updates-testing).

Any comments/feedback? (Feedback from all of: release engineering, packagers 
and Rawhide users is welcome!)

        Kevin Kofler