Rene Rivera
I should have prefaced all my replies with.. I don't feel strongly opposed to this change. Just more like "meh" So please take my comments in that context.
On Tue, Jan 5, 2016 at 4:52 PM, Louis Dionne
wrote: [...]
If there are other uses, could you please elaborate? This is not rhetorical; such uses would point out other places that need to be changed to accommodate my proposal.
I don't know all of them ATM. Daniel maintains some extra tools that deal with that file. So he will need to tell us.
Ok no problem. Let's hope Daniel sees this thread.
[...]
If not confusing, it can definitely be surprising. The convention for storing meta data and configuration data is to use dotfiles, not meta/ directories.
It's a convention on Unix style systems. Not so much on Windows. For example, Appveyor doesn't use a dotfile (although maybe they support alternate names?)
That's true. However, I think that it would be better to adhere to a convention, even if not universal, than to adhere to no convention at all. Also, you are correct in thinking that Appveyor allows customizing the name of the appveyor.yml file.
Also, my point is not only about confusion, but mostly about clutter. The meta/ directory at the root of Hana appears in my editor, my file browser and everywhere else as a directory. It is given the same priviledged place as other directories such as include/, when it should be a mere detail.
Personally I consider hiding of information (aka files) by IDEs to be a UI bug. Which is especially painful to me as I spend most of my personal programming time on OSX It also means I had to dig around IDE documentation to disable that bug.
I guess this is personal preference, then. Outside of an IDE, I find it very useful to have commands like `ls` exclude dotfiles and dotdirs by default. But again, you could argue for the contrary, so let's assume this is not a strong argument for or against.
[...]
Also, as a side note, I would probably oppose storing release notes in such a directory. Some libraries are also released on their own, and it would be messy to store Boost-specific release notes in there. Plus, some people might want to use GitHub to provide release notes (this is my case). And even if we were to always include release notes in a library, we could argue that using a CHANGELOG file or similar is more in line with existing practice.
You are going to need to mention what goes into here < http://www.boost.org/users/history/version_1_60_0.html> somewhere. And I'd prefer to move away from having authors continually submit PRs to the website for this.
Ah, I see.
[...]
2. Suggest using a .boost _directory_ instead of a single file
Renaming the directory seems like a better choice to me.
In retrospect, it probably is a better choice indeed. The changes required to existing tools would also be even more trivial, and we could easily do a batch renaming for all modules. Like I said elsewhere, my problem is not file vs directory, but the way such a file or directory is named.
[...]
What if Travis had decided to use a ci/ directory instead of a .travis.yml file? Clearly, using Appveyor and Travis at the same time would have been confusing, since both of them are CIs. Using .travis is just more focused, and it carries the intent better.
It's a case of facets. For CIs they are facets of a repository. Which is not really the case for Boost. It's single a Boost library. Now I grant you that it's becoming possible to have a library be independent and a Boost library. So perhaps that's the issue you are trying to resolve? I.e. How to manage a library that has both an independent, outside of Boost, existence and is part of Boost?
Yes, exactly. When reasonable, I want to minimize the cohesion between Hana and Boost. In its current state, Hana is a completely standalone library, which also happens to work inside the Boost tree. I'd like it to stay that way, since I find it gives me more freedom to use Hana the way I want.
I have submitted a pull request to BPM [1] adding the ability to fetch the meta data in a .boost file. The meta-data can still be provided in meta/libraries.json, so this should not affect existing libraries.
It would as it's more maintenance and confusion as to where to have that data. And as was pointed out that's not the only consumer of that data.
As Glen suggested, we could also move all the modules to the dotfile approach. Otherwise, I think you can see from my pull requests that the amount of added maintenance is quite small.
If we change.. I prefer to just move everything to the new way. Having multiple supported ways hasn't worked out so well for us in the past And it's easier to deal with one way for tools (see my other post).
Sure, then I'd be OK with doing a batch rename.
[...]
Right. You will definitely need help. At least to go in and merge all the PRs involved in this. Since only admins (aka the release team) has enough privileges to do this unilaterally. And it needs to be unilaterally, since the last time we did such a change (creating that meta dir) it was impossible to get authors to help.
If I provided a script to do it, could someone from the release team update all the repositories? Such a script should be fairly simple to write, but in comparison creating 100+ PRs and merging them would be quite cumbersome. One problem I see is for those libraries maintained as forks; in this case the original repository would need to be updated, which would require authors to cooperate. But I think all libraries maintained as forks have authors that are around, so it should be doable. Regards, Louis