Re: [boost] [optional] New RC_1_34_0 regression

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-04-09 11:38:43

Fernando Cacciola wrote:

>>> Fernando Cacciola wrote:
>>>> I can test it with gcc (4.4.1) in a Debian Linux Box, but not today
>>>> (8pm already here). And probably not until next Monday.
>>>>
>>> OK. I just did it, and it also works with gcc 4.4.1
>> 
>> I'm certainly missing something. Clearly, the change you committed
>> right before freeze changed a finite amount of files. What's wrong
>> with reverting those files into the state they had immediately
>> before your commit?
>> 
>> While "I really hated the idea of going back to 2 headers" might
>> be a good technical argument at a different time, do we really
>> want to spend time trying yet another alternative solution
>> at this point?
>> 
> If it were just a matter of reverting N files to a previous version I
> would just do it. But it isn't.
> 
> I need to revert 2 files, BUT ALSO
> 
> 1.Manually edit-back "optional.hpp", which included "none_t.hpp" but now
> includes "none.hpp"

If it included none_t.hpp and now includes none.hpp, it means there was
a commit which changed that file. How about reverting that commit?

> 2.Manually edit-back those test files which included "none.hpp"
> explicitly and now they doesn't.

Why? Weren't those file changed as part of some commit?

> 3.Manually re-edit the documentation to state that "none.hpp" must be
> included separately.

Again, I'm lost. I presume there was commit which made documentation no
longer say that none.hpp must be included separately.

> Granted, I can avoid 1,2 and 3 there by going back to the 2 headers but
> keeping "optional.hpp" *updated*, that is, including "none.hpp".
> But that renders the point of having two separate headers totally useless.
> 
> I totally understand that doing a last minute fix which delays the
> release even longer is annoying, but IMHO is even more annoying to
> release something knowing it has a problem just because we don't want to
> spend a few additional days clearing up anything that may leak after the
> fix. I'm afraid that's just the way our industry works, but I don't but
> like it.
> 
> Also, unlike the problematic in-a-rush fix that caused the problem
> before, I've given this fix a lot of attention, and it comes with a
> test, so I could tested it locally on 3 different platforms and I will
> test it on a fourth today.
> 
> And finally, Thomas is off until Wednesday anyway, so what's the point
> in rushing just now when we can do whatever it takes to make sure this
> fix will really work?

Well, technically Thomas said it's OK to either revert, or apply 
Richard's patch. You seem to propose checking it some different patch.
Assuming you post it now, and Thomas OKs it on Wednesday, and there
are no issues, we've lost 2 days compared to reverting today. And
delays tend to add up.

I don't have no authority to tell you what to do; if you feel that
whatever patch you have now is OK, you should post it and wait
for Thomas to comment.

- Volodya