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

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
>> Though I am interested in getting other people's
>> feedback. I would *really* like to see feature freeze week be the time
>> to ask people to focus on getting bugs squashed, code merged,
>> documentation written, and not developing new features. You can chose
>> what to do on your time, but my shaping what gets accepted for that
>> week, it can help encourage people to do some polishing.
> 
> It might be helpful to define "polishing" as people have different opinions about what needs to shine :)  For example, I'd tend to think test suite fixes would qualify (shiny tests are good!), but they've been rejected during the frozen period.  I didn't bother looking for things to "polish" during the 1.6 frozen period as I was under the impresison that anything other than major showstoppers would be held over.  Up until now I've been assuming 1.7 would be the same...
> 
> Cheers,
> 
> Mark
> 
> 

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.


I can understand your confusion. And I will agree that typical things allowed
during "feature freeze" week are:

1) Test updates, especially for fixing "broken" (by platform) tests. Reducing
   test coverage is obviously a no-no. But as you won't break the *runtime*
   bzr by breaking something in bzrlib/tests/* we are usually more lenient
   about what gets merged.
2) Documentation updates
3) Regression fixes (always allowed, even during rc's)
4) Bug fixes
5) "trivial" updates, this is a bit hazy but things like:
  a) Obviously correct tweaks to existing code. There is some question where
     this lands versus bug fixes.
  b) Adding new apis. Modifying existing apis is almost never allowed, but the
     idea is you can't cause a *regression* with new code, because old code
     won't be calling it.
     Robert's new hook would fall under this heading. I'll admit to being
     picky about asking not to merge it. I suppose I could have been more
     passive-aggressive and just not reviewed it. It is unlikely that someone
     else would have approved it before 1.7rc1 was out.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIwZIOJdeBCYSNAAMRAp0pAJ9eQsfOd6AxeHrADrt3rNBrk/LLiQCfZ7bK
yA558T8uSwwitGRxyAdvFd4=
=jNhH
-----END PGP SIGNATURE-----