How freeze breakage works in general ("time to teach the newbie")

[Elijah Newren <newren gmail com>]

On Mon, 7 Feb 2005 19:25:32 -0500, Luis Villa <luis villa gmail com> wrote:
> On Tue, 08 Feb 2005 01:20:18 +0100, Murray Cumming <murrayc murrayc com> wrote:
> > On Mon, 2005-02-07 at 19:15 -0500, Luis Villa wrote:
> > > Murray, is there anyone else appropriate on the team right now to
> > > approve this?
> >
> > Some one else who has designed an API in a high-level language, I
> > suppose.
> 
> Right, but does anyone that you know of match that criteria? i can't
> think of anyone, which is why i ask you :)

Cool, a chance to jump in with some questions and learn.  Or at least
a chance to make a complete fool of myself as the newbie.  :-)  This
thread comes across as very odd to me.  Now, there aren't any
guidelines anywhere on how patch approval for freeze breaks work other
than "you need two approvals from the release team".  So, I tried to
watch for a while and figure out how things worked.  Then I eventually
jumped in and made a couple comments/choices on ones that looked
fairly safe, figuring that if I really blew things I could learn and
hopefully not a lot of harm would be done.  Okay, so with this
background...

This thread makes it appear that the release team approvals are
technical reviews.  I was assuming that would not be the
case--obviously those most able to do technical reviews are the module
authors.  But leaving them to do all decisions about freeze breakages
means that there isn't a freeze.  So, I figured that the release team
was here to make a best-bet call about how bad is it versus how bad is
missing it in a system-wide how-much-will-this-affect-everyone-else
kind of way, with some added weight against making exceptions so that
freezes retain meaning.

Obviously, without some technical background some things are difficult
to judge the how-bad-it-is vs. how-bad-is-missing-it aspect.  But it's
difficult to do that sometimes without being a module author anyway. 
That's why we so frequently ask for details ("Why can't this wait?",
"What's the impact of this?", "Is it a regression from the previous
Gnome release?", "What would be missed by not including it?") after
people request a freeze breakage.

In particular, my thoughts on the perl API freeze breakage were: (1)
See what Murray says (to see if I'm thinking right), (2) API additions
are not as severe as API changes or such so we can tend to be easier,
(3) it appears they have some API they want to add that isn't really
necessary, (4) they have some that appears fairly important, (5) they
have the cool bonus of having written tests for everything already.

Given the above and Murray's comments, aren't most if not all members
of the release-team qualified to give a second approval (or partial
approval considering the additions that look less important)?  I'm
looking for the general rule of thumb here as opposed to the specific
case, though the specific case definitely provides a good concrete
example...

Thanks,
Elijah