On 13 January 2016 at 15:49, Louis Dionne
Ok no problem. Let's hope Daniel sees this thread.
We'll probably need to start another thread so he notices.
I sent him a private email to notify him of the thread.
I think this is a bad idea, the advantages of such a change are smaller than the disruption it would cause. Having two different locations would be an issue, because it would be likely that people won't realise that they have to deal with that - especially if one location is hidden. So if someone writes a script using this data, they'd miss some of it. The alternative is to move the files in every module, which would result in a pointless discontinuity. It's also not true that dotfiles are idiomatic here. Since you were addressing package management, that's a fairly good place to look for examples. I had a look at package management systems for several languages (maven for java, nuget for c#, gopm for go, cpan for perl, npm for javascript, composer for php, pip for python, gems for ruby) and only gopm uses dotfiles. That's hardly an established idiom. But I don't really think a third party tool is an appropriate place to look. This is dealing with a boost specific problem, and has no ambition to be a general purpose tool. The 'meta' directory is intended to be part of the standard boost directory layout, and follows the established style. Of course dotfiles also don't have any special meaning on windows, and many of our developers are windows based, so they'd just be weird for them. And on platforms where they are hidden, that's a problem, as they're not discoverable. The whole point of these files is to make it easy for maintainers to update information, even if they don't know about the system in advance. This is also the reason why the file needs to be short. I find the suggestion that the file's path should have had a boost specific element more convincing, and if that had been suggested when I was first setting this up, I would have changed it. But I feel it's too late now, at this point stability is more important, and a path collision with another tool/service seems very unlikely. FWIW none of my scripts actually require a module to have this file, the data can be managed directly in the website. I created them using pull requests with a note saying that they weren't required. But others wanted them to be in every module, so that's why it's required now. And since you were wondering why it's a directory, there was a vague plan to use a similar mechanism for the expected test results, but no one has been keen enough to actually implement it.