[V1.46][Spirit] request for late minute changes to release branch
Hey release managers, With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably. Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid. We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit. What would you suggest? Regards Hartmut --------------- http://boost-spirit.com
On 1/23/2011 10:14 AM, Hartmut Kaiser wrote:
Hey release managers,
With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably.
Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid.
We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles
Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit.
What would you suggest?
It's a new feature that nobody is using yet? How about ... c) Leave it undocumented. Fix it in the next release. I prefer c). Please remove any references to utree from the docs and the release notes. Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 23 January 2011 06:28, Eric Niebler <eric@boostpro.com> wrote:
On 1/23/2011 10:14 AM, Hartmut Kaiser wrote:
Hey release managers,
With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably.
Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid.
We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles
Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit.
What would you suggest?
It's a new feature that nobody is using yet? How about ...
c) Leave it undocumented. Fix it in the next release.
I would very much prefer removing it. If I write code which uses utree and send it to someone else, I wouldn't want it to compile if their copy of boost has an undocumented and non-functional copy of utree in it. Perhaps as least remove the "major" base headers, so it is not usable. Chris
On 1/23/2011 5:21 PM, Chris Jefferson wrote:
On 23 January 2011 06:28, Eric Niebler<eric@boostpro.com> wrote:
On 1/23/2011 10:14 AM, Hartmut Kaiser wrote:
Hey release managers,
With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably.
Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid.
We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles
Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit.
What would you suggest?
It's a new feature that nobody is using yet? How about ...
c) Leave it undocumented. Fix it in the next release.
I would very much prefer removing it. If I write code which uses utree and send it to someone else, I wouldn't want it to compile if their copy of boost has an undocumented and non-functional copy of utree in it. Perhaps as least remove the "major" base headers, so it is not usable.
That's a very good point, but I think Eric's intent is to be ultra cautious and not touch any code at all this late in the release cycle. I can understand that. I'm ok with b or c. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 23 Jan 2011, at 10:54, Joel de Guzman wrote:
On 1/23/2011 5:21 PM, Chris Jefferson wrote:
On 23 January 2011 06:28, Eric Niebler<eric@boostpro.com> wrote:
On 1/23/2011 10:14 AM, Hartmut Kaiser wrote:
Hey release managers,
With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably.
Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid.
We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles
Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit.
What would you suggest?
It's a new feature that nobody is using yet? How about ...
c) Leave it undocumented. Fix it in the next release.
I would very much prefer removing it. If I write code which uses utree and send it to someone else, I wouldn't want it to compile if their copy of boost has an undocumented and non-functional copy of utree in it. Perhaps as least remove the "major" base headers, so it is not usable.
That's a very good point, but I think Eric's intent is to be ultra cautious and not touch any code at all this late in the release cycle. I can understand that. I'm ok with b or c.
What would happen, do you suspect, if I took code which worked with the up-coming version, and tried to compile it with 1.46? Would the problems be it didn't compile (that's fine with me), or it compiled but horribly misbehaved in unpredictable ways? Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 23 Jan 2011 11:52:48 +0000 Christopher Jefferson <chris@bubblescope.net> wrote:
What would happen, do you suspect, if I took code which worked with the up-coming version, and tried to compile it with 1.46? Would the problems be it didn't compile (that's fine with me), or it compiled but horribly misbehaved in unpredictable ways?
Chris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Misbehaved in unpredictable ways. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk08G+AACgkQ9cB/V3/s9Ey3ZACghnwviHXRKk0SN7he8Y+XTN3Z aNsAn2yGhjJX8GIvLDm6fhM1xAHWu9DA =wVZK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, rather, compiled and misbehaved. Not particularly in an unpredictable fashion. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk08HSwACgkQ9cB/V3/s9EzZcgCcC6ichwbT0mtENjFNZ7CYg0tM oxsAoJ6+DWhYSXf7ztdb0W8JlN4HcMyB =RSpw -----END PGP SIGNATURE-----
On 23 Jan 2011, at 12:21, Bryce Lelbach wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Well, rather, compiled and misbehaved. Not particularly in an unpredictable fashion.
Still, if this version of boost ended up in an ubuntu release, or some such, then a lot of people might end up with miscompiled code. I was looking forward to using utree, and now I am going to have to add an explicit version test, to make sure I don't pick up this broken version. Unfortunately, people tend to just try compiling code they get with whatever is on their system first, and don't check headers. If the particular headers are just never supposed to be included, they could just be 'poisoned' with a #error, or as you say deleted. I realise this might hold release up, but would avoid known-broken code being released. Chris
On 1/23/2011 7:27 PM, Christopher Jefferson wrote:
On 23 Jan 2011, at 12:21, Bryce Lelbach wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Well, rather, compiled and misbehaved. Not particularly in an unpredictable fashion.
Still, if this version of boost ended up in an ubuntu release, or some such, then a lot of people might end up with miscompiled code. I was looking forward to using utree, and now I am going to have to add an explicit version test, to make sure I don't pick up this broken version.
Unfortunately, people tend to just try compiling code they get with whatever is on their system first, and don't check headers.
If the particular headers are just never supposed to be included, they could just be 'poisoned' with a #error, or as you say deleted. I realise this might hold release up, but would avoid known-broken code being released.
I would be ok with poisoning the broken header with #error. That's in addition to removing any mention of the broken feature from the docs and release notes. But please do it soon. I think the beta is to be rolled tomorrow. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric,
Well, rather, compiled and misbehaved. Not particularly in an unpredictable fashion.
Still, if this version of boost ended up in an ubuntu release, or some such, then a lot of people might end up with miscompiled code. I was looking forward to using utree, and now I am going to have to add an explicit version test, to make sure I don't pick up this broken version.
Unfortunately, people tend to just try compiling code they get with whatever is on their system first, and don't check headers.
If the particular headers are just never supposed to be included, they could just be 'poisoned' with a #error, or as you say deleted. I realise this might hold release up, but would avoid known-broken code being released.
I would be ok with poisoning the broken header with #error. That's in addition to removing any mention of the broken feature from the docs and release notes. But please do it soon. I think the beta is to be rolled tomorrow.
poisoning the utree headers touches exactly the same set of files as pulling them. The overall design makes utree completely nonintrusive to other parts of Spirit, the headers are not included anywhere. The same is true for the tests: the Jamfiles have to be touched in any case. May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable... Regards Hartmut --------------- http://boost-spirit.com
On 1/23/2011 11:44 PM, Hartmut Kaiser wrote:
Eric,
Well, rather, compiled and misbehaved. Not particularly in an unpredictable fashion.
Still, if this version of boost ended up in an ubuntu release, or some such, then a lot of people might end up with miscompiled code. I was looking forward to using utree, and now I am going to have to add an explicit version test, to make sure I don't pick up this broken version.
Unfortunately, people tend to just try compiling code they get with whatever is on their system first, and don't check headers.
If the particular headers are just never supposed to be included, they could just be 'poisoned' with a #error, or as you say deleted. I realise this might hold release up, but would avoid known-broken code being released.
I would be ok with poisoning the broken header with #error. That's in addition to removing any mention of the broken feature from the docs and release notes. But please do it soon. I think the beta is to be rolled tomorrow.
poisoning the utree headers touches exactly the same set of files as pulling them. The overall design makes utree completely nonintrusive to other parts of Spirit, the headers are not included anywhere.
The same is true for the tests: the Jamfiles have to be touched in any case.
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
I second Hartmut's plea. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 1/23/2011 10:44 PM, Hartmut Kaiser wrote:
Eric Niebler wrote:
I would be ok with poisoning the broken header with #error. That's in addition to removing any mention of the broken feature from the docs and release notes. But please do it soon. I think the beta is to be rolled tomorrow.
poisoning the utree headers touches exactly the same set of files as pulling them.
Not true. You wouldn't have to touch any build files to poison the headers.
The overall design makes utree completely nonintrusive to other parts of Spirit, the headers are not included anywhere.
The same is true for the tests: the Jamfiles have to be touched in any case.
They don't. Let the tests for utree run and fail. utree is broken, after all.
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
Sorry, no. We have a way to avoid changing build files just before release. Let's take it. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 1/23/2011 10:44 PM, Hartmut Kaiser wrote:
Eric Niebler wrote:
I would be ok with poisoning the broken header with #error. That's in addition to removing any mention of the broken feature from the docs and release notes. But please do it soon. I think the beta is to be rolled tomorrow.
poisoning the utree headers touches exactly the same set of files as pulling them.
Not true. You wouldn't have to touch any build files to poison the headers.
The overall design makes utree completely nonintrusive to other parts of Spirit, the headers are not included anywhere.
The same is true for the tests: the Jamfiles have to be touched in any case.
They don't. Let the tests for utree run and fail. utree is broken, after all.
Well, that's something I wouldn't have done even if push came to shove - under no circumstances.
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
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. Regards Hartmut --------------- http://boost-spirit.com
On 1/25/2011 12:09 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. 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. Please don't do that again, or your changes will be reverted. 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. -- Eric Niebler BoostPro Computing http://www.boostpro.com
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
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
On Tuesday, January 25, 2011 04:05:22 Eric Niebler wrote:
On 1/25/2011 12:09 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. 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. Please don't do that again, or your changes will be reverted.
Release managers: our process should include a way to physically lock down the release branch at the cut-off date.
That's actually straight-forward to do: (1) give me ssh access to svn server (2) there's no (2) Another alternative is having Rene be subsribed to Google Calendar notifications and disable commits himself ;-) - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On Tuesday, January 25, 2011 04:05:22 Eric Niebler wrote:
... 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. 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. Please don't do that again, or your changes will be reverted.
Eric, technical and process issues aside, it seems to me that your reply has gone in the direction of personal attack. It seems to me that Hartmut was acting in good faith, and therefore we should be talking about how to improve process (e.g. publishing your mobile number on boost.org, and I'm not kidding), rather then threatening to start a revert war or apply technical measures to prevent commits.
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,
Most of which, I presume, were just now CCed on this thread? - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 1/25/2011 2:28 PM, Vladimir Prus wrote:
On Tuesday, January 25, 2011 04:05:22 Eric Niebler wrote:
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,
Most of which, I presume, were just now CCed on this thread?
I responded to Hartmut because none of the other release managers did. I shouldn't have to cc any release managers. This is standard stuff. Volodya, you're free to follow the list and jump in whenever you feel like it. In fact, please do. We have extra release managers because *we're all busy* and we can't all follow the list. We answer what questions we find unanswered.
... 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. 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. Please don't do that again, or your changes will be reverted.
Eric,
technical and process issues aside, it seems to me that your reply has gone in the direction of personal attack.
That wasn't my intention. Hartmut, I personally offended you and I'm sorry. I know you believed you were doing the right thing.
It seems to me that Hartmut was acting in good faith, and therefore we should be talking about how to improve process (e.g. publishing your mobile number on boost.org, and I'm not kidding), rather then threatening to start a revert war or apply technical measures to prevent commits.
If it's OK to ignore the release procedures and the judgment of the release managers, why have release managers at all? It's not a rhetorical question. Last release cycle, IIRC, merges were accidentally made by maintainers who weren't aware of the release status. I suggested then that we should physically lock down the release branch. Had that suggestion been taken, we wouldn't be having this discussion now. Hartmut would have filed a showstopper bug, submitted his patch, and had it acepted or rejected, and that would have been the end of it. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tuesday, January 25, 2011 11:37:18 Eric Niebler wrote:
It seems to me that Hartmut was acting in good faith, and therefore we should be talking about how to improve process (e.g. publishing your mobile number on boost.org, and I'm not kidding), rather then threatening to start a revert war or apply technical measures to prevent commits.
If it's OK to ignore the release procedures and the judgment of the release managers, why have release managers at all? It's not a rhetorical question.
Well, most of the time release manager is doing roughly what an adminstrative assistant does in an office -- helping everybody do things and making sure every i is dotted. Of course, there are times when there's a judgement call to be made, and it's surely required that at the end, release manager can enforce a decision. But, enforcing a decision should be an exception, and every time the process somehow breaks, it's better to think how to improve it, so that the next time, there's no need to enforce anything. In this case, the problem was a combination of (i) perceived chances of having beta released really soon now with code that seemed undesirable, and (ii) failure to have closure on the discussion with release managers before that supposed deadline. (i) Can be improved by: - Communicating when the actual deadlines are. In particular, this is only a beta, and this change could be done before actual release. It's also unlikely that Beman would roll the beta before even having breakfast ;-) - Actually implementing protocol for filing "I think this really should be fixed" bugs. Note that apparently, we failed to check the list of show-stopper bugs again this time. (ii) Can be improved by providing out-of-band contacts of release managers to Boost developers. WDYT? -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
Eric Niebler wrote:
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
Sorry, no. We have a way to avoid changing build files just before release. Let's take it.
That does not seem reasonable to me. IIUC, the changes to build files involve remove N tests, which is a low-risk change that can be fully validated locally. Leaving broken code in seems much worse. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 1/25/2011 2:10 PM, Vladimir Prus wrote:
Eric Niebler wrote:
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
Sorry, no. We have a way to avoid changing build files just before release. Let's take it.
That does not seem reasonable to me. IIUC, the changes to build files involve remove N tests, which is a low-risk change that can be fully validated locally. Leaving broken code in seems much worse.
The question to answer is: was the original issue a showstopper or not? I had decided it was not because it breaks no code in the field. That seems reasonable to me. And if you disagreed, the time to speak up was days ago. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
On 1/25/2011 2:10 PM, Vladimir Prus wrote:
Eric Niebler wrote:
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
Sorry, no. We have a way to avoid changing build files just before release. Let's take it.
That does not seem reasonable to me. IIUC, the changes to build files involve remove N tests, which is a low-risk change that can be fully validated locally. Leaving broken code in seems much worse.
The question to answer is: was the original issue a showstopper or not? I had decided it was not because it breaks no code in the field. That seems reasonable to me.
You seem to take a block-diagram-driven approach. "Is this a showstopper -- yes, no?". The real decision here is either shipping a broken code, or doing a relatively safe code change to remove all traces thereof.
And if you disagreed, the time to speak up was days ago.
There's some truth to that; except -- aren't the most recent messages in this thread dated Jan 23 and Jan 24 -- which is yesterday and the other day? In fact, what is the status here? I though that utree code was removed, and Jamfiles were modified to not run relevant tests. Is that untrue? - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 1/25/2011 5:35 PM, Vladimir Prus wrote:
Eric Niebler wrote:
On 1/25/2011 2:10 PM, Vladimir Prus wrote:
Eric Niebler wrote:
May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable...
Sorry, no. We have a way to avoid changing build files just before release. Let's take it.
That does not seem reasonable to me. IIUC, the changes to build files involve remove N tests, which is a low-risk change that can be fully validated locally. Leaving broken code in seems much worse.
The question to answer is: was the original issue a showstopper or not? I had decided it was not because it breaks no code in the field. That seems reasonable to me.
You seem to take a block-diagram-driven approach. "Is this a showstopper -- yes, no?". The real decision here is either shipping a broken code, or doing a relatively safe code change to remove all traces thereof.
My understanding is that the release progresses in stages. We had passed the "doing relatively safe things" stage and passed into "critical bug fixes only" stage. You could say that I take too hard a line. Maybe. I think that the process runs more smoothly when the rules are well-defined, we all understand them and stick to them. Hartmut's change was relatively safe -- granted. But I don't want to start making exceptions. I'm busy. The last thing I want is a lengthy discussion about whether the fixes are "safe enough". So yeah, at this point in the release, "is it a showstopper, yes or no?" That makes my job easier.
And if you disagreed, the time to speak up was days ago.
There's some truth to that; except -- aren't the most recent messages in this thread dated Jan 23 and Jan 24 -- which is yesterday and the other day?
Yes, 2 days ago. As the subject line says, this is a "last minute" change request. We're down to the wire. Two days can be a long time.
In fact, what is the status here? I though that utree code was removed, and Jamfiles were modified to not run relevant tests. Is that untrue?
That's the current state, yes. And it looks good. That's great. It was a roll of the dice and we won. I'm not going to give the money back, but I'd rather not be playing dice in the first place, even if it's a safe bet. I hope I've made my position clear. And I hope Hartmut forgives my harsh tone. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 1/23/2011 2:28 PM, Eric Niebler wrote:
On 1/23/2011 10:14 AM, Hartmut Kaiser wrote:
Hey release managers,
With the upcoming Boost release, we were planning to release a new feature in Spirit (a dynamic data structure called utree) and everything seemed to be fine. Unfortunately, we now discovered a flaw in the design of the new code, which shows up under certain circumstances. The fix for that problem changes the semantics of the utree/Spirit integration considerably.
Releasing utree now without being fixed means breaking its semantics with the next release. That is something we would like to avoid.
We have two options: a) fix it now, possibly delaying the release for a couple of days (until the tests have cycled), or b) pull utree from the release branch, which mainly means removing files and adapting the test Jamfiles
Neither a) nor b) would have any consequences for other Boost code and both are purely local to Spirit.
What would you suggest?
It's a new feature that nobody is using yet? How about ...
c) Leave it undocumented. Fix it in the next release.
I prefer c). Please remove any references to utree from the docs and the release notes. Thanks.
Same here. I agree with Eric. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
participants (7)
-
Bryce Lelbach -
Chris Jefferson -
Christopher Jefferson
-
Eric Niebler -
Hartmut Kaiser -
Joel de Guzman -
Vladimir Prus