Re: GCC selftest improvements

[Mike Stump <mikestump@comcast.net>]

On Oct 28, 2019, at 12:40 PM, Jeff Law <law@redhat.com> wrote:
> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> we have any good mechanism for making this kind of technical decision
> when there isn't consensus.

I'll just point out that we do have good mechanisms in place.  Consensus building is a nice way of doing things, but, when that fails, we can punt to a well established reviewer to just make a decision, because sometimes a made decision is better than failing to make a decision, which, itself, is a decision.  It that should fail for any reason, anyone should feel free to punt to the SC.  Generally we don't use them this way, but, I think it's reasonable to do this if all the maintainers are shy about this or need guidance.

For example, the current policy is to pick the minimum gcc version of all the current LTS release of all the distributions/OSes.  I could propose this be the policy to the SC, then they could, if they wanted to, agree with the policy, then we can document the policy, and then a reviewer can approve a doc patch to say that gcc X or newer is required, whenever the new X is the oldest among the then current set of distributions/OSes.  The policy drives expectations, and drives approvals to bump.  Now, that's just a recommendation.  A reviewer might have a reason to not bump the tools, and that's ok as well.  No reviewer should feel bad, approving a bump when that bump follows the policy however.

If I apply the current policy, [  checking around ] My 18.04 has 7.4 in it.  Centos 8 has 8.2.  It would seem that a bump to 7.4 should be fine, now.  I didn't look at other distributions, but we can go through the list, and on the basis of what version is in the current LTS/OS, contemplate the bump the the minimum of all of them.  That's basically the status quo policy.

Now, people do like to hold onto old OSes and old machines.  And we cater to them by having old releases that can drop onto their system and just run.  For example, I have a 14.04 machine, that's still awaiting 20.04 to upgrade to, but thats because I want to cater even to very old releases (all LTS releases that are not EOL), cause doing this is very cheap.  I manage this by dropping a gcc 9 onto the box so that I have a known, not that old compiler.  Presto, all my software can now use gcc 9 features and not worry about it.

So, I'd propose bumping the minimum to 7.4 if people want to update.  People can comment what release fedora, arch, SUSE and so on have.  Since 7.4 has c++17 in it (non-default), accepting patches that turn on c++17 in that compiler isn't unreasonable, but that's orthogonal to the version bump.  My old Apple has c++17 on it.  Don't have a windows box, but google seems to suggest that their tools support c++17.

I think we should pick not on the basis something unspecific, rather, I'd list the 3 5 or 9 systems we check against, and then pick the minimum of them.  Above I picked 7.4 because it's on 18.04.  I think this  makes for a better policy as it's predicable, stable, and in 100 years, I don't think I see the need to change the policy.