Future of Bliss - Githubissues

mkoeppe / bliss

bliss - compute graph automorphisms - by Tommi Junttila, Petteri Kaski - with patches from Debian and for SageMath. Archived because upstream has become active again in 2021.

GNU Lesser General Public License v3.0

4 stars 1 forks source link

Future of Bliss #3

Open AntoinePrv opened 3 years ago

AntoinePrv commented 3 years ago

Hello @mkoeppe

When filing to ship the SCIP solver on Conda (https://github.com/conda-forge/staged-recipes/pull/13520), we discovered the existence of this fork of Bliss. Beforehand, we had started our own fork ds4dm/Bliss, as it seems the original authors were not interested in maintaining this project.

We believe we should join efforts to make this project easier to use for all of us. Here is a list of what we have been working on, and would like to improve:

[x] The first patch used by the SCIP developers was to be able to limits number of search nodes and generators during the backtrack search (https://github.com/ds4dm/Bliss/commit/faeb2d27854ab04efa8a512f9fc92ef546d1a12e). This is something that we need to keep on our end, so hopefully we can find a way to merge it without changing API.
[x] Move to CMake for the build tool.
[ ] Add Github Action to test that the library installs properly in different OS.

What are your thoughts on this? I hope that you share this vision.

cc: @matbesancon @fschloesser

mkoeppe commented 3 years ago

The purpose of this fork was to provide a source release for use in the SageMath distribution - a proper build system (taken from Debian's autotoolization) so that shared library builds work reliably, plus a few bug fixes.

I do not have immediate plans for more development.

I would suggest to include other distribution maintainers, such as the maintainer of the Debian package, in the conversation.

A quick note - to restructure a source tree as a first action when forking a package is IMHO ill-advised because you are making it harder to exchange patches with other forks and distributors' patches.

SageMath could certainly switch to using a different, well-maintained fork if that (1) includes our bug fixes and (2) is able to support the same breadth of platforms as our fork.

AntoinePrv commented 3 years ago

I would suggest to include other distribution maintainers, such as the maintainer of the Debian package, in the conversation.

That would be welcome, do you know who they are?

SageMath could certainly switch to using a different, well-maintained fork if that (1) includes our bug fixes and (2) is able to support the same breadth of platforms as our fork.

Are you suggesting moving to our repository if we merge your changes? I am not sure our changes are binary compatible. We'll try hard to make it happen, but a safe plan would probably be to start from you changes and bump the version number.

A quick note - to restructure a source tree as a first action when forking a package is IMHO ill-advised because you are making it harder to exchange patches with other forks and distributors' patches.

That's a good point, although I am not there is so much going on in Bliss that git could not keep track of it. We're happy to let it go if that can help.

mkoeppe commented 3 years ago

I would suggest to include other distribution maintainers, such as the maintainer of the Debian package, in the conversation.

That would be welcome, do you know who they are?

https://repology.org/ is a good starting point to find out.

SageMath could certainly switch to using a different, well-maintained fork if that (1) includes our bug fixes and (2) is able to support the same breadth of platforms as our fork.

Are you suggesting moving to our repository if we merge your changes?

This might happen in the future if we (SageMath) find that your fork is suitable. On the SageMath side there is currently no need for any work on bliss – development is triggered by build failures that need fixing.

mkoeppe commented 3 years ago

Just added a GH Actions workflow for portability testing in #4.

AntoinePrv commented 3 years ago

This is great! On our end, we heard back from Junttila Tommi

Incidentally, I've released new versions during the last weeks that address most of your comments, please see https://users.aalto.fi/~tjunttil/bliss/download.html Observe the new URL; the old URL is still active for some time but will eventually disappear (I cannot currently add a forward pointer in the old page due to some legacy file system issues).

The new versions still use the same algorithms as the previous version 0.73 but C++11 and Windows compatibility have been improved, CMake support introduced, and it is also possible to terminate the search early (with the risk of incompleteness). Shared libraries are also built. C++11 is now required. In Windows, I set the MSVC option /permissive- so that MSVC supports standard C++11 operators "and" and "or". The timer class has been rewritten to use std::chrono.

The new version seems to satisfy our concerns, but there is still a bit of (ongoing) work to move from current SCIP patch to the new node limit API of Bliss. Hopefully we'll no longer need our patch.

There may potentially be an official Github repo for Bliss in the future as well.

mkoeppe commented 3 years ago

Thanks for sharing this news.

antonio-rojas commented 3 years ago

What are the plans for this repo? I'd like to port sage to use bliss 0.77 so I can update it in Arch. It comes with a cmake build system now, although incomplete (no install target). Do you think we can switch back to using plain upstream releases, or will this fork still be needed?

mkoeppe commented 3 years ago

What are the plans for this repo?

My hope is that I can archive it as soon as the Sage distribution has switched to a usable upstream.