Stephen Kelly
On 10/13/2013 02:30 PM, Joaquin M Lopez Munoz wrote:
Considering that authors and, particularly, users do not customarily scan Boost commits at svn.boost.org, chances are the majority of affected people won't notice until Boost 1.56.
Ideas for improving that are welcome. Do you have any ideas? What about keeping
http://www.boost.org/users/news/old_compilers.html
up to date with the changes/bumps?
Yes, I think this is a very appropriate place to provide information on the progress of the initiative.
and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected, Only the config/compiler files for MPW and SunPro are affected by this commit. Which are not listed in changeset 85272.
You don't understand. Maybe I was not clear enough. Let me try again:
Only the config/compiler files for MPW and SunPro are affected by revision 86241.
In that context, your comment about revision 85272 makes no sense.
Do you understand now?
No (this is a candid no.) What I'm not getting is the point of your whole activity. After reviewing the discussions and your commits, I understand that there are two (more or less unrelated) tracks here: 1. Once changeset 85272 is commited and official news given about Digital Mars<8.41, GCC<3.3, Intel<6.0 and Visual C++<7.1 being no longer supported (Boost 1.55), eliminate obsolete code checking for these compilers or for defects no additional supported compiler has. 2. Require TPS support, which implies dropping more compilers than announced in the previous track, namely MPW and SunPro<5.4. Is this an accurate description of what you're doing? If so, I'd say going forward with #1 is not controcersial but #2 necessitates that some discussion happens so as to reach an agreement about what to do (probably dropping MPW and SunPro<5.4 is perfectly fine, but they're still officialy supported.) Look, in case I finally got it right after spending like a couple of hours looking into that, consider that many other readers without the time to do similarly might not have a clue yet: this is why I'm asking for more clarity, mail subject tagging, a prominent log page, etc.
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support]) I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice). Prefixing, which is regularly used in Boost mailing lists, allows people interested in a particular initiative to easily filter and track related messages. Now, if I want to consult the prior discussions on your efforts I have to look for your name and filter out not related stuff.
Filtering for my name is enough. You can consider the [compiler support]/[modularization] implied on all messages from me.
That's OK with me, but not with the rest of the community who hasn't necessarily followed our discussion thread down to this point and still don't know about the [compiler support]<->skelly equivalence. Seriously, please make everybody and yourself a favor and strive for the greatest clarity in your communications. Thank you, and thank you for initiating this activity which, despite discussions around execution, is sorely needed. Joaquín M López Muñoz Telefónica Digital