[graph] disjoint_sets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[graph] disjoint_sets

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [graph] disjoint_sets

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [graph] disjoint_sets

Boost - Dev mailing list
On Mon, Jul 16, 2018 at 5:17 PM Marc Glisse <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [graph] disjoint_sets

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost