On Wed, Jan 6, 2016 at 1:50 PM, Louis Dionne
Rene Rivera
writes: 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.
We'll probably need to start another thread so he notices.
I sent him a private email to notify him of the thread.
[...]
OK, thinking about it more, now that my brain has time.. I think the best I can think of is to have the dir be ".boostlib". It directly communicates the intended use "Stuff about the Boost library".
I am not strongly attached to the exact name of the directory. I do find that .boost is prettier, but I don't really care. I'll use .boostlib when preparing pull requests.
[...]
Such a script should be fairly simple to write, but in comparison creating 100+ PRs and merging them would be quite cumbersome.
Note, I would prefer if the script did *everything* needed to do the rename. Which means starting from nothing, doing the clones, branch switches, renames, commits, and pushes.
Sure, I think that's the best way to go too. I reckon the changes should be made to the `develop` branches of each library. The changes would then eventually merged to `master` when preparing the next release. Is this correct?
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.
Wouldn't they get merge conflicts and be forced to resolve them?
I guess that would be a viable path too, although it might be better to ask these authors the permission before applying the changes, for politeness. What I propose is the following plan: 1. I'll prepare pull requests for the tools that need to be changed. That will most likely require Daniel James to give me some input. 2. I'll prepare a script that a release manager can run to apply and commit the changes to individual libraries. 3. I'll send an email to this mailing list, explaining what changes are about to be rolled out. We should give some time period for people to oppose to the changes, if they so desire. Something like 1 week seems reasonable? 4. Once the period is done, if it is clear enough that people are okay with this change, a release manager can roll out the changes and merge my pull requests on the tools all at once. Does this plan seem reasonable? Regards, Louis