Review queue/FESCo after the merge

[Jesse Keating]

On Wed, 14 Nov 2007 22:58:27 +0100
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> You received feedback from some people, including from Hans, Me and
> some others. On "# Date: Fri, 26 Oct 2007 13:52:34 -0400" you in
> https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02295.html

The crux of Hans' complaint as I understand it is that there is an
actual freeze, at all.  That there would ever be a time where a build
done doesn't automatically go into a release.  And I'm sorry, but I
just can't possibly imagine doing any kind of release with any sort of
quality if there wasn't some sort of freeze.  I fought with QA for the
shortest freezes possible for a reasonable release cycle, and that's
what we have in the proposed changes/schedules.  Your QA team would
like even longer freezes.  I'd like you to find any other distribution
that doesn't do some sort of a freeze for a release.

And I took a lot of your input and incorporated it into the proposal,
like weekly snapshots, and discussion of at some point being able to
compose two trees, the pre-release tree and the next rawhide each
night.  Likely can't do that for F9, but looking into the future.  Then
it digressed into arguing about freeze times, and while I appreciate
your opinions, I also have to rely upon my experience of actually doing
the releases and knowing how much time we need with limited tree
changes.  I think there is one clarification that needs to be made, you
at one point asked:

F9 hypothetical schedule: Final Development freeze is 20080408 -- thus
all updates after that point that are *not* release-critical gets tagged
as "updates candidate" afaics (at least that's how I understand it from
the description; please tell me if I got something wrong). Thus
non-critical stuff doesn't make it into the tree for 23 days (release is
scheduled for 20080501).

I should note that during that time we're taking more things in that
just 'release-critical' updates.  We're taking (with review) reasonable
bugfixes.  It's the opportunity for all the groups to look at what
we're proposing as the final package set and look for bugs that should
be fixed.  Once we create the first Release Candidate, that's the point
when we're only taking in release critical fixes.

I should note that even /with/ our review, a few builds slipped in that
broke things pretty badly for the release.  A late rhgb build caused a
lot of boot hangs.  A late selinux-policy build broke selinux.  The
rhpxl build we did late to fix graphical boot broke ps3.  There were a
few more too.  These are all examples why not having review and not
being very critical about every change going into a release can have
very nasty results.

I'd be more than happy to continue discussing why the proposal is the
way it is.  We didn't just pull numbers out of our butts because we
felt like it, there are very real reasons and experiences that have led
us to want a slow down to changes being introduced to the tree, along
with a reasonable enough amount of time to actually create release
candidate trees and validate them before throwing them at the mirrors,
and giving the mirrors enough time to sync up for the release.  Your QA
team wants enough time to sufficiently test the proposed bits for
release without adding new builds to the mix and invalidating tests.

My entire motivation has been to find ways to accomplish the slow down
for the release tree while providing outlets for builds to continue
(and even be tested!).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/ddf0038a/attachment.sig>