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

[Mark McLoughlin <markmc redhat com>]

Hi Elijah,

On Mon, 2005-02-07 at 17:58 -0700, Elijah Newren wrote:
> 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...

	Yeah, we don't have guidelines on how to make these decisions, and
that's mainly because its an inexact science. But the way I think about
it is:

  - We're trying to slow down the rate of major change in the lead
    up to a release. We start by slowing down the rate of large scale 
    changes and changes that affect others and coming closer to the
    release we lock down all changes.

  - We're trying to teach maintainers to make this decision on their
    own. Ideally, the maintainer only asks after weighing up the pros
    and cons and we're just a rubber stamp. So, we look for sane,
    considered requests from sane, considered maintainers.

  - We frown upon changes that might cause regressions, changes that 
    have impact on other parts of the release, people rushing to get
    things in at the last minute without giving themselves a chance
    to get it right etc. etc.

  - We also look over the patch itself to make sure we fully understand 
    what's being proposed and its impact and we try and catch anything
    obvious in the patch the maintainer has missed. E.g. if you spotted
    a leak, it would be "tut, tut, you're trying to rush this in"

> 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.

	IMHO, Its also worth taking into consideration that its a language
binding. Keeping up with new APIs is the name of the game, so we need to
cut them a bit of slack ... but not blanket "you can add APIs whenever
you want" slack.

> 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...

	There's no reason at all for you to not make this call :-)

Cheers,
Mark.