Boost logo

Boost :

Subject: Re: [boost] Removing support for old compilers
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2013-10-14 02:23:16


Stephen Kelly <steveire <at> gmail.com> writes:

>
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk