From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2007-04-09 16:48:53
Vladimir Prus wrote:
> 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
> a commit which changed that file. How about reverting that commit?
That would revert all the other changes to "optional.hpp" (which is the
bulk of the update and I definitely won't roll-back).
>> 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?
Yes, a commit that involved other changes that I don't want to roll-back.
>> 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.
Sort of. The doc commit introduced all the updates to optional, including
"none" documentation which was entirely non-existing before.
As you can see now, the problem is that the problematic commit did not
involve just "none" but a lot of other changes.
>> 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
>> 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
>> 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.
If you look at it you'll see is only marginally different.
> 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.
To me we gained two days to make sure the patch works.
> 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.
I already posted it 4 days ago, and asked everyone in this thread to test it
if they can.
The bottom line is that I'm pretty confident this patch will work. It's the
same patch Richard proposed (go look at it and you'll see that, even if not
token-by-token, it is the same), I used a specific test-case, and the test
case passed the tests in 3 platforms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk