[MERGE] Create a new hook Branch.open. (Robert Collins)

[Martin Pool]

On Sat, Sep 6, 2008 at 6:09 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:

> So... I feel like 1.6 was a special case. I was explicitly trying to do the
> absolute minimum amount of changes to get the damn release out the door
> because it was >3 months overdue.
>
> I realize you have only been around for the 1.6 release (since again, we
> haven't had one in a while).
>
> As for the rules during a feature freeze, I've said explicitly:
>
>> To encourage reviewers, things that are in BB *today* have a very good chance
>> of making it in during feature freeze. And, of course, bug fixes will always
>> have a decent chance.
>
> And earlier:
>
>> Once feature freeze hits, I really do plan on having a week of bugs-only
>> fixes. As mentioned early on, I'll probably try to organize at least one day
>> to be an official "bugs" day, where I'll poke at people on IRC to triage and
>> post fixes for bugs.
>
> I also explicitly stated that I wanted to have test suite improvements for
> 1.7. Admittedly it was probably not clear where those would fall versus the
> "freeze" week.

Getting back on a regular cycle is very important and I really
appreciate your efforts to get 1.6 and 1.7 out.

I think when I read those I interpreted "make it in" as meaning that
you would merge them before making the 1.7 branch, or that they could
be merged to 1.7 as well as trunk.

In the past we had periods where trunk was frozen.  I thought we
decided not to do that, but rather split off a release branch when we
do the first rc, leave trunk open all the time, and merge onto the
release branch only things that are both safe and worthwhile:
documentation, packaging, portability, bug fixes, regression fixes.

I think we should stick with this approach because it doesn't make it
any harder to fix things on the release branch, it avoids confusion or
arguments about when trunk is open or not, and it may reduce people
trying to rush things on to trunk.

If people are not spending enough time on reviews, bug fixes, or
whatever, I'd rather tackle that directly through persuasion or
direction (for Canonical staff) than tweaking the review process to
get it indirectly.

-- 
Martin <http://launchpad.net/~mbp/>