|
Boost : |
Subject: Re: [boost] [V1.46][Spirit] request for late minute changes to release branch
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2011-01-24 21:22:34
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk