Changing default cxx_stdlib to libc++

[db]

On 13 Mar 2018, at 15:22, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Mar 13, 2018, at 08:47, db wrote:
>> On 12 Mar 2018, at 21:35, Ryan Schmidt wrote:
>>> On Mar 12, 2018, at 13:56, db wrote:
>>>> If not, shouldn't it, prior to accepting an updated port definition?
>>> The buildbot is only engaged after a commit is in the repository master branch.
>>> We have a separate system, using Travis CI, for doing test builds of updates that have been submitted as pull requests but have not yet been merged into the repository master branch. But most maintainers that are committers don't submit pull requests for their own software, they just commit directly to master, so their changes would not go through Travis.
>> Then why contribute an update to a port circumventing the test build system? What's the sense in that?
> You're the first person, that I'm aware of, to suggest that we should restrict commits to master and require all contributors, including those who have already been vetted and given commit access, to make their contributions through pull requests. I'm sure there are other projects that have made such policies, but we haven't so far. Instead, we allow direct commits to master, and we encourage others to review those commits on the macports-dev mailing list or on GitHub.
> 
> We've only been on GitHub since late 2016. For the 10 years prior to that, we used a Subversion repository, and prior to that it was CVS. The only way to update those repositories was for a someone with commit access to commit to them. Many of us who were MacPorts committers during that time are used to this way of working and might find the additional roadblocks to our contributions that pull requests represent to be intrusive. In my case, I feel like I might finally be becoming proficient at submitting pull requests at least, but it has been a long and frustrating learning process for me, and one which is far from over; I'm still making git mistakes daily.
> 
> We've only had our Travis CI integration set up since mid-2017. I am not certain what its reliability is now. Often, when I've looked at a Travis failure log, it has turned out to be a problem specific to Travis, and not a reason to reject a PR. So I am not paying a great amount of attention to what Travis is doing at this time. It's nice that we have it, it's nice that our other developers like to use it to check their work before publishing it. But developers are already expected to check their work and verify the port installs on their own machines before committing or submitting a PR or patch; if they do that, they shouldn't see much on Travis that they didn't already know about.

Thanks for the background. I don't know how much inconvenience would that mean for developers, I do know as a user though. I suppose that problems would be properly caught in the pipeline and almost never make it to the user. Skipping it because of being inconvenienced, that doesn't make any sense whatsoever to me.