Repository navigation
Ownership of cudd-sys (Rust bindings) #48
Description
Activity
I agree that it would be nice to unify CUDD maintenance efforts under this organization. I can invite @pclewis and any interested Rust maintainers to join the organization. Being under the @cuddorg organization may improve visibility and make coordination much easier.
And please let me know if there is anything helpful to build CUDD using Rust tooling. I am not really familiar with the Rust ecosystem. I want to involve more but other responsibilities prevent me concentrate on that so far.
Having contributed recent updates to the
cudd-syscrate, I would be very interested in helping to maintain the rust bindings for the cudd project.In terms of tooling, from the rust side, mostly everything is provided by the Rust package manager cargo.
To accommodate for the new build chain for the new 4.0 release (that involves cmake), adjustments to the build process and CI setup have to be made. However, they should be fairly straight forward.The packaging and publishing is then handled via the Rust package manager. Nothing is really required here, ideally one would migrate the publishing process into the CI/CD by using the new Trusted Publishing workflow.
Thanks @doganulus :)
Awesome! I am not sure how active @pclewis is on Github these days (we only interacted a few years ago when I helped to keep the package maintained). However, we can definitely try to ask him to transfer the ownership (unfortunately, I don't have the rights to do that). In the worst case, he might not get the message and we'll have to fork the project.
There is one thing that needs to be discussed still though: Using cargo, the
cudd-syspackage is published at crates.io. I have admin rights to this package, so I can create a publishing API key and make it available to the organization, meaning we can publish new versions ofcudd-sysdirectly from github actions without my intervention. However, if I get run over by a bus, the organization may eventually lose this access.So either (a) we need to consider adding more people from the organization as admins of the package on crates.io (fortunately, it seems that I can do that, we just need to decide who's it going to be and whether that actually solves the single-point-of-failure concern) (b) create some "shared" organization account that will get the admin rights and then save it securely somewhere such that only the members of the organization have access to it.
Do you have any preferences in this regard?
Edit: I also "officially" asked if we could transfer the repo (cuddorg/cudd-sys#8). We'll have to wait and see if @pclewis is still active and open to it.
Unfortunately, I think that somehow both solutions are not suboptimal.
a) would require us to constantly maintain the users with admin privileges. While we reduce the chance of singe points of failures, we would probably not give every user in the org access, so there is still a chance of loosing access, if there is no longer ongoing maintenance effort.
b) AFAIK there is no way to create an account managed by an organization. We would have to somehow store credentials in some internal repo or similar, and the question then becomes what email to use, which will be needed to verify access (because many actions require additional authentication, like login from a new device). It just creates an additional potential single point of failure.
I actually don't have a preferred solution here.
I am happy to transfer the repo. I think I need to be in the org to do so.
Reacted by Samuel Pastva and Paul EichlerReacted by Philip LewisWelcome to the organization, @pclewis!
Thank you for transferring the repository, and thanks to @daemontus and @pleich for the suggestions. I’ve also added @pleich as another maintainer of the repo.We may need to make some updates on the Rust side or elsewhere to account for the new repository location.
Overall a very good move!
Reacted by Paul EichlerMaybe rename the repository to
cudd-rust?I'm not entirely against it, but
*-sysis a naming convention for Rust crates ("libraries") that link to some underlying C code. It's not a formal rule, but it is very common to use this suffix. So, I would consider renaming the repository, but not the crate itself.Overall, the most "standard" way of doing this would be to name the whole repository
cudd-rs, and then have two crates in it:cudd-sys(which is just the C bindings), andcudd-rs, or justcudd, which is a nicer, memory safe interoperability layer built on top ofcudd-sys(which we currently don't have). However, that would be a bit more work, so that's definitely something for a bigger project.(For comparison, see how it is done for the Z3 solver: https://github.com/prove-rs/z3.rs)
I agree with @daemontus here. As long as there is no higher level interface, I would be in favor of keeping the current name
FYI, I now configured the
cudd-sysrepository such that any tag whose name matchesv*.*.*,v*.*.*-alpha.*, orv*.*.*-beta.*gets automatically validated against the minimum supported version of Rust and published to crates.io.While this does not give us a clear "succession plan", it does mean that anyone in the CUDD organization who can push to this repository can now also release directly to crates.io, so it is not strictly necessary to have me involved. I would very much like to maintain that everything we merge and publish gets some (however brief) human review, but we don't really have any branch protection rules right now, so that's essentially a "gentlemen's agreement" at this point.
We can add branch protection to
main. Perhaps this is better when managing the repository with multiple contributors.
Hello everyone!
Since the cudd organization is now more active, I wanted to ask about the future of the CUDD bindings for Rust (https://github.com/pclewis/cudd-sys). I "took over" (meaning "I did a few maintenance updates") a long time ago after @pclewis started the project, but maybe now is the time to transfer it into the CUDD organization? It would also make sense to eventually sync new CUDD releases with updates to the Rust bindings.
Of course, I'm still happy to help, e.g. with reviewing future pull requests and there seems to be community interest in helping out as well (cuddorg/cudd-sys#6). But I might not have as much time for it as needed, so it would be good if it were managed by the whole organization.