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. You posited an 'official' opinion, 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, 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. Now please tell me, what is the preferable outcome? 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.
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, 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!
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. 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'). Finally yet importantly, alienating active developers is definitely not part of a release manager's job description. Regards Hartmut --------------- http://boost-spirit.com