Re: [boost] [1.47.0] Release branch now closed

Subject: Re: [boost] [1.47.0] Release branch now closed
From: Jim Bell (Jim_at_[hidden])
Date: 2011-06-17 14:40:31

On 1:59 PM, Rene Rivera wrote:
> On 6/17/2011 10:36 AM, Anthony Williams wrote:
>> Rene Rivera<grafikrobot_at_[hidden]>  writes:
>>
>>> On 6/17/2011 10:05 AM, Jim Bell wrote:
>>>>
>>>>
>>>> On 6/17/2011 9:37 AM, Rene Rivera wrote:
>>>>> On 6/17/2011 8:58 AM, Jim Bell wrote:
>>>>>>
>>>>>> On 1:59 PM, Rene Rivera wrote:
>>>>>>> The release branch is now close, i.e. the release is frozen, for
>>>>>>> further changes. This means that commits to the release branch will
>>>>>>> fail without explicit authorization.
>>>>>>
>>>>>>
>>>>>> The Boost.Thread patch for Mingw-64 is crucial for that important
>>>>>> platform.<https://svn.boost.org/trac/boost/ticket/4849>
>>>>>>
>>>>>> It has been patched into the trunk for three months without
>>>>>> complaint,
>>>>>> and just needs to be shepherded to the release branch.
>>>>>>
>>>>>> Could you please do this?
>>>>>
>>>>> I'm not sure what you are asking.
>>>>
>>>>
>>>> I'd like a maintainer or release manager to merge the patched trunk
>>>> files into the release branch.
>>>>       boost/detail/interlocked.hpp
>>>>       libs/thread/src/win32/thread.cpp
>>>>       libs/thread/src/win32/tss_pe.cpp
>>>>
>>>>
>>>> See<https://svn.boost.org/trac/boost/changeset/70383>
>>>
>>> Since I don't know enough to judge the code itself at this
>>> instant.. Could others please comment on the above? Is the thread
>>> maintainer around?
>>
>> The only change NOT already merged is the change to
>> boost/detail/interlocked.hpp. I overlooked this when I merged the thread
>> changes from trunk to release a couple of weeks ago, and I wouldn't have
>> remembered if Jim hadn't raised the issue, since this is not one of the
>> main thread headers.
>>
>> However, this is a relatively small change (some functions are no longer
>> marked dllimport), and it only affects this one compiler, since the code
>> expands to the same as before on other compilers.
>
> Could you address my other concerns I posted about?

You mentioned total concerns, but not specifics.

Note that two of the three files are in a win32 subdirectory, intended
only for that platform.

Shouldn't the "immediate compile error/problem" and "7 likely other
compiler problems" manifest themselves in at least one trunk thread test
failure over the past three months (since it was merged into the trunk)?

Does this assuage your concerns?