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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
