[graph] disjoint_sets
Hello folks in the Boost.Graph team, The CMT currently maintains Boost.DisjointSets which contains a class that is only used by Boost.Graph and Boost.GraphParallel. The headers are published in "boost/pending" right now. Given the CMT has a considerable workload already I would like to discuss moving disjoint_sets into Boost.Graph, as long as it satisfies the requirements for the two repositories currently consuming it. This would be for 1.69.0. Any thoughts, objections, considerations on this (open to anyone)? Thanks, Jim
On Mon, 16 Jul 2018, James E. King III via Boost wrote:
Hello folks in the Boost.Graph team,
The CMT currently maintains Boost.DisjointSets which contains a class that is only used by Boost.Graph and Boost.GraphParallel. The headers are published in "boost/pending" right now. Given the CMT has a considerable workload already I would like to discuss moving disjoint_sets into Boost.Graph, as long as it satisfies the requirements for the two repositories currently consuming it. This would be for 1.69.0.
Any thoughts, objections, considerations on this (open to anyone)?
You could also become a maintainer for Boost.DisjointSets without merging it with another package. I don't mind the merge, I am just saying the two need not be linked. The headers might be in boost/pending, but there are many external users. Please try not to break them gratuitously. If you move the header to a different subdirectory, please put in the old position a dummy header that includes the new one, etc. -- Marc Glisse
On Mon, Jul 16, 2018 at 5:17 PM Marc Glisse <marc.glisse@inria.fr> wrote:
On Mon, 16 Jul 2018, James E. King III via Boost wrote:
Hello folks in the Boost.Graph team,
The CMT currently maintains Boost.DisjointSets which contains a class that is only used by Boost.Graph and Boost.GraphParallel. The headers are published in "boost/pending" right now. Given the CMT has a considerable workload already I would like to discuss moving disjoint_sets into Boost.Graph, as long as it satisfies the requirements for the two repositories currently consuming it. This would be for 1.69.0.
Any thoughts, objections, considerations on this (open to anyone)?
You could also become a maintainer for Boost.DisjointSets without merging it with another package. I don't mind the merge, I am just saying the two need not be linked.
The headers might be in boost/pending, but there are many external users. Please try not to break them gratuitously. If you move the header to a different subdirectory, please put in the old position a dummy header that includes the new one, etc.
-- Marc Glisse
Providing a forward is easy enough, and certainly possible to avoid things disappearing. Nobody should be relying on a header that contains "boost/pending" in the path however. This repository was created with "pending" headers then abandoned. Maintaining a separate repository for one class is incredibly expensive. If you factor in the CI requirements for unix, windows, code coverage, static code analysis it becomes very expensive. We have the same issue with Boost.Logic (boost::logic::tribool is the only class) for example, but there is a much higher likelihood that A) there are external users or B) more boost::logic will appear in the future. These things said, will you accept a PR into Boost.Graph adding disjoint_sets? I can set it up so that it retains any header forwarding needed. If you decline, I will set up the complete CI environment for it and the CMT will be forced to continue to maintain it. Thanks, Jim
On Mon, 16 Jul 2018, James E. King III via Boost wrote:
Providing a forward is easy enough, and certainly possible to avoid things disappearing.
Thanks. I was actually more worried you might want to refactor the code and update the interface, in which case compatibility could be harder to maintain.
Nobody should be relying on a header that contains "boost/pending" in the path however.
We have to be pragmatic. This header works and provides a fundamental facility. Since it has been there for a very long time, people have grown confident enough to use it. A search on google / github shows more users than for a number of official facilities.
Maintaining a separate repository for one class is incredibly expensive. If you factor in the CI requirements for unix, windows, code coverage, static code analysis it becomes very expensive.
Maybe the problem is that cost, not the number of repositories. Setting up pretty much exactly the same tools for multiple repositories should be very easy. And the more things are split, the cheaper CI should be (fewer tests to run for each patch).
These things said, will you accept a PR into Boost.Graph adding disjoint_sets?
Just to be clear, I am only a boost user, I am not the one you need to convince. I was against the split of boost into submodules, and union-find is very related to graphs, so if the Boost.Graph maintainers are in favor of a merge, I am all for it. -- Marc Glisse
participants (2)
-
James E. King III -
Marc Glisse