Re: [boost] [V1.46][Spirit] request for late minute changes to release branch

Subject: Re: [boost] [V1.46][Spirit] request for late minute changes to release branch
From: Eric Niebler (eric_at_[hidden])
Date: 2011-01-24 21:51:47

On 1/25/2011 9:22 AM, Hartmut Kaiser wrote:
>>> Eric Niebler wrote:
>>>> Sorry, no. We have a way to avoid changing build files just before
>>>> release. Let's take it.
>>>
>>> Well, it's too late for that. You said to react quickly as the beta is
>>> to go out today (Monday) and none of the release managers has gotten
>>> back to us before yesterday (late) evening. As we needed to decide in
>>> a timely fashion, we pulled utree completely from the release branch
>> only.
>>>
>>> All tests (those, which caught up) are green, which makes me believe
>>> we did the right thing.
>>
>> (cc'ing the other release managers)
>>
>> Hartmut, you had your answer from the release managers, and you had it in
>> a timely fashion: pull the docs and poison the broken headers. But you
>> didn't like the answer, so you asked, "Really?" And when you still didn't
>> hear the answer you wanted, you went ahead and made your changes anyway.
> 
> That's not entirely true. I asked 'really?' with additional explanations as
> we had the impression that my first mail had not given the full picture,
> leading to misunderstandings on your end.

Thank you, I understood the problem quite well. It was a new feature,
and it was broken.

> You posited an 'official' opinion, 

Yes, as a release manager, my opinion is official. Sans quotes.

> which seemed to us being based on
> incomplete information. At the same time, you expressed the need for quick
> reaction. We have not received any response from none of the release
> managers to our repeated mail (I know that you Eric are in a time zone
> completely opposite to mine right now). We believed our arguments were good,
> sensible, and convincing enough to change your mind. For that reason, we
> decided to go against your initial decision.
> 
> My mails are the result of thorough discussions amongst the Spirit
> developers, and the decision to pull the files is not mine alone. As
> explained, we, the Spirit developers

Let me remind you that the Spirit developers are not Boost's release
managers.

> , came to the conclusion that pulling
> the files incurred the same risk as what you suggested, namely touching
> exactly the same set of files. The difference is, that we are now entirely
> green in terms of tests, while your suggestion would have left Spirit with a
> whole set of broken tests. 

Yes, reflecting the fact that utree is, in fact, broken. There is
nothing wrong with test results that reflect reality.

> Now please tell me, what is the preferable outcome? 

The *best* outcome is a bug-free and timely release of Boost. By my
suggestion, I was trying to ensure both. I saw your change as no less
correct but needlessly risking a delay.

> Nevertheless, I would like to apologize if my commit is generally seen as an
> irresponsible action. We discussed the required changes thoroughly and tried
> to come up with a solution, which is minimally damaging for Boost and
> Spirit. We tested the changes as thoroughly as we could on four different
> platforms before committing. 

That's appreciated, but beside the point.

>> This is a serious breach of protocol. We can't have people making the
>> changes that make them feel good willy-nilly just before a release. C'mon,
>> you know better than this. 
> 
> Eric, even if this is a 'serious breach of protocol' I see no reason for you
> to use this tone on me. 
> You're neither my age nor are you my father,

What does age have to do with this?

>  please restrain yourself. We
> have worked together for quite some time and you know I am a responsible
> person not making any rash decisions, not to speak about 'willy-nilly'
> changes.
> 
>> Please don't do that again, or your changes will be reverted.
> 
> Go ahead, be my guest. However, I believe it wouldn't do any good to Boost!

No, more changes at this point would risk delaying the release. We've
taken enough risks already.

>> Release managers: our process should include a way to physically lock down
>> the release branch at the cut-off date. This is not the first time changes
>> have (intentionally or accidentally) been merged without permission during
>> code freeze. Policing this policy on the mailing list is not working.
> 
> Being release manager is not only about being as strict as possible.

No, but but it does involve weighing risks. We have to draw a line
somewhere. We were only taking showstopper fixes. Where was the
showstopper bug? This one does not qualify.

When I worked on Windows 2000 and Visual C++, I saw how seriously
code-freeze was taken during the lead-up to a release. Not taking
code-freeze seriously slows down the whole process.

> Likewise, it's not only about enforcing deadlines. The main task of the
> release managers is to ensure a high quality release, allowing some
> flexibility for unexpected situations (very much as you allowed for some
> flexibility when it came to tackling that Spirit/Proto/Fusion bug we fixed
> in the last minute, after the 'cut-off date'). 

Yes, it was a showstopper:
https://svn.boost.org/trac/boost/ticket/5084

The irony is that, even though this is a bug that only affects Spirit
users, the Spirit developers would have let this slip had I not held
their feet to the fire.

> Finally yet importantly,
> alienating active developers is definitely not part of a release manager's
> job description.

Enforcing Boost release procedure is my job. Holding developers who
violate policy responsible is my job too (but it fucking sucks). If you
want to take offense for being held accountable, that's entirely your
business.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com