-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future maintenance #4
Comments
cc: @tarcieri whose (If I don't hear back this will be the last time i'll cc: you about rust+macaroons) |
I am happy to give over the |
Honestly, I have absolutely no time to dedicate to this (kids + work + other commitments), so I'm happy to hand this over to you. Let me know when/how you want to hand over the project. I am glad someone's taking it on, though. Please let me know if you have any questions/concerns about the code as well. |
Great! I will get my fork in good shape over the next couple weeks and will request redirects/transfer/permissions when ready. I will soon be launching a production service using this library, so will have some sustainable motivation to for maintenance going forward. |
ref(*): Refactors various functions and adds support for binary data
I'd also be willing to contribute to this project, help move it forward and add some polish. 😄 |
@duncandean We did a bunch of work to add some polish in our fork here: https://github.com/deislabs/libmacaroon-rs However, we are still not sure if we are going to continue forward with our planned usage of the library or not. I will update things here once I know more. But feel free to take a look at that code. I'd be completely willing to merge that in to another fork even if we don't end up continuing our use |
Sorry to have flaked on this, and not to have replied earlier @thomastaylor312. We continue to use our fork of this crate as part of the https://fatcat.wiki project. It would be wonderful to have a stable/maintained upstream. I don't have the bandwidth to do most of the things mentioned at the start of this issue, but would be happy to review and/or contribute if somebody else has the time to lead. |
Thanks @thomastaylor312, @bnewbold will check the forks out some time in the morning. I have the time to take up leading a project, but unfortunately little experience in that regard. I suppose this might be an appropriate challenge.🙂 I am quite keen though. Would be great to have a de facto macaroons crate. |
I've created a new org and repo: https://github.com/macaroon-rs.
|
@duncandean @bnewbold So It looks like we aren't going to continue forward with our use of macaroons, so we will not be helping maintain it. However, feel free to take our code as a starting point! |
Any progress on this? |
No changes from me. The |
Hi everyone, I haven’t made any drastic changes from where @thomastaylor312 left off. More setting up code coverage and maintenance automation at macaroon-es/macaroon. Also just contributed the logo. You can see the changes I’ve made. Mostly updates and some fixes to tests for these updates. I’m currently out of town with limited cellular reception, but I’ve invited @bnewbold and @jacklund as members to that org for now. |
I went ahead and deprecated my project in favor of https://github.com/macaroon-rs/macaroon, since y'all have done a lot of work to get it updated and into good shape. I also yanked all the versions of my project from crates.io, hopefully this would allow the other project to be published there using the I'll try to help out with the other project as well, as time permits. |
I think we can mark this issue as closed in favour of macaroon-rs/macaroon#40 🙂 |
Hello @jacklund!
This repository has not been updated for some time. From README:
so it's entirely understandable that this crate isn't receiving maintenance. However, I'm interested in helping maintain a reasonably polished and idiomatic macaroons library for Rust, and I've found this project to be the furthest along. Would you be willing or interested in co-maintaining or turning over the project?
Under the context that there seem to be very few or no crates depending on this one right now, and it's still at version 0.1.1 (so breaking updates might be feasible), my priorities would be:
Non-priorities (but maybe interesting to others) would be:
An alternative I've been thinking about is to just wrap the upstream C library, creating a "libmacaroon-sys" crate. However, I think the spec is simple enough, and the downsides of wrapping (potential security issues with bindings; friction of depending on external libraries) means a pure implementation is preferable.
The text was updated successfully, but these errors were encountered: