Re: [boost] Review request: Require a SFINAE capable compiler

Subject: Re: [boost] Review request: Require a SFINAE capable compiler
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-13 16:03:30

On 10/13/2013 09:31 PM, Andrey Semashev wrote:
> On Sunday 13 October 2013 20:26:56 Stephen Kelly wrote:
>> On 10/13/2013 02:17 PM, John Maddock wrote:
>>> It's OK by me, though as others have already said, best to wait for
>>> the 1.55 release to go out first... just in case we need to test
>>> patches/bug reports in Trunk.
>> This is what I don't understand.
>>
>> I don't see how my work makes this any harder. At *worst*, a bug fix
>> will have a part in the positive side of an ifdef for some feature (like
>> BOOST_NO_SFINAE), and a part in the negative side of it. I don't think
>> that's even a likely scenario. Also, that's assuming the one who writes
>> the patch patches both sides of the ifdef.
>>
>> That is still trivial to cherry-plck into the trunk branch. Or do you
>> think it is not trivial? In that case, what makes it non-trivial?
>>
>> I want to understand the problem that exists and is stalling me.
> While the release is in process of preparation, like now, it is possible that 
> a bug is reported and fixed in trunk. The developer then waits to see if the 
> tests are ok in order to merge the fix to release. Since the time is pressing 
> and tests turnaround is typically around a week or so, even a brief breakage 
> in trunk is critical. Such breakage can prevent a valid bug fix from making it 
> into release.
>
> Further I'll just speak for myself. I prefer trunk and release branch to be 
> always as close as possible. I don't do cherry picking when merging to 
> release, I always synchronize release with trunk (after tests pass) by merging 
> the whole library. This way I make sure I don't have any forgotten unmerged 
> commits in trunk. 

I won't comment on how good an idea this is, in my view... :)

> This also makes sure that I mostly have a single version of 
> the library everywhere, so I don't have to guess when someone reports a 
> problem with the library.

If the reporter doesn't say, then you have to ask them. They might
respond version 1.54, 1.53, 1.52 etc... or they might respond 'release
branch' or 'trunk branch'.

Either you guess or you ask.

> Cherry picking is also more complicated by itself 
> since I have to figure out which commits I want to merge and which I don't 
> (and why).

As the maintainer, which ones you cherry-pick are simply your choice. I
don't see how that is complicated either you think it should be in
branch xyz, or you don't.

> So, I'm in favor of postponing any massive changes to Boost.Log or 
> Boost.Atomic in trunk until after 1.55.

Yes. I'm not going to make more changes, except on request until after
1.55 is out. Daniel said until 'some time after' 1.55 is out. I have no
idea how much time he has in mind...

>  That said, I'm not against the general 
> trend of raising compiler requirements or someone patching the libraries I 
> (co-)maintain.

Great, thanks.

> Perhaps, it would be a good idea to create tickets for the affected libraries 
> with localized patches instead of posting here cumulative patches to the whole 
> Boost. This way the library maintainers will be properly notified of the 
> planned changes, the changes won't be lost and will be applied when it is 
> convenient.

That's not practical. I'm changing many libraries, and I'm making
micro-commits for easy review. I'm not going to file a ticket for each
one. If you want to know how your library will be affected by my
changes, then simply grep for the macros under discussion for removal
(BOOST_NO_SFINAE, at least, currently).

Thanks,

Steve.