Transferral of repository

[brendanzab]

Seeing as this repository seems to be getting some love now (thank you to @sebcrozet in particular!!), I'm wondering if it would be a good idea to transfer it to a more appropriate org? I don't really have the time or energy to maintain it myself, but I feel bad stealing the clout.

[sebcrozet]

Hey! Thanks to you for making this crate.
I can offer to move this to the Dimforge organization, which would strengthen my personal commitment to maintain the crate. However I don’t know if this transfer would be well perceived by you or the community considering that Dimforge is a company.

[jonaspleyer]

@brendanzab @sebcrozet I have recently forked approx to include many of the propsed PRs and would be open to maintaining the package, possibly with other users as well. In case you are reading this at any time, let me know how you feel and how to proceed.

https://github.com/jonaspleyer/approxim

[brendanzab]

@jonaspleyer Hello, thanks for all the interest in the crate! I was wondering if you might be interested in helping out upstream some of these improvements into approx? I don’t really have the bandwidth to do regular maintenance on it myself, but it’s nice to see some movement on this stuff, considering there are so many people currently using the crate it might be challenging to transition everyone over.

[jonaspleyer]

@jonaspleyer Hello, thanks for all the interest in the crate! I was wondering if you might be interested in helping out upstream some of these improvements into approx? I don’t really have the bandwidth to do regular maintenance on it myself, but it’s nice to see some movement on this stuff, considering there are so many people currently using the crate it might be challenging to transition everyone over.

Hi @brendanzab thanks for taking the time to answer. 😃 My fork approxim was not really supposed to be a permanent solution but rather intermediate for when approx merges some of the PRs which are floating around. Since approxim is based directly on approx it would probably be the easiest solution to merge the whole crate and rename it again. This would include all PRs which I have commented on.
The other way would be to manually go through all PRs again and merge them. But I would like to avoid this path as it means repeating work which I have already done.

Lastly, the question of derive macros came up previously. I have written my own derive macros under the approx-derive crate and would be open to include them within approx.

[kitt159]

I would like to push this forward. This crate has so many users that unresolved bugs can cause a lot of bugs in dependent crates (my case, by the way).

[jonaspleyer]

I would like to push this forward. This crate has so many users that unresolved bugs can cause a lot of bugs in dependent crates (my case, by the way).

What specific bug are you referring to ?

@brendanzab What would be the most suitable steps in order to upstream the changes? It would very much be possible to merge approxim into approx. Let me know if I should open a PR which does that.

[kitt159]

What specific bug are you referring to ?

#65

[stgeo]

@brendanzab @jonaspleyer Any news on the upstream merge or move of the repository?
We use approx but will probably switch to approxim for the extra features until the merge happens.

[jonaspleyer]

Unfortunately, I have no update. My means of communication is through these threads such that everyone is able to follow the most recent events.

[brendanzab]

If most of the changes in approxim are largely backwards compatible we can probably pull them back into approx directly. Having some sort of changelog might help users make the transition as well, but I’m not sure how drastic the changes are.

I can give Jonas PR access on this repository and pull in the changes, and also rights to push new versions to crates.io. Longer term it might be best to transfer the repository to Jonas’ GitHub account or to a separate organisation to provide continuity of referral links etc.

Just want to apologise for all the delay with this stuff. I’ve got a lot of guilt for leaving approx unloved for so long, which is part of what makes coming back to this difficult.

[stgeo]

If most of the changes in approxim are largely backwards compatible we can probably pull them back into approx directly. Having some sort of changelog might help users make the transition as well, but I’m not sure how drastic the changes are.

I can give Jonas PR access on this repository and pull in the changes, and also rights to push new versions to crates.io. Longer term it might be best to transfer the repository to Jonas’ GitHub account or to a separate organisation to provide continuity of referral links etc.

Just want to apologise for all the delay with this stuff. I’ve got a lot of guilt for leaving approx unloved for so long, which is part of what makes coming back to this difficult.

No guilt necessary from my point of view, this is how it is in the open-source world: one person contributes their personal time and effort and when they cannot do it any more, someone else takes over (or the project dies). Thankfully, Rust makes it easy to switch to a different fork, which is what we have done for now. Still, I think it would benefit the community to pull the changes from approxim and give Jonas maintainer access to approx, since it is still the far more popular crate.

[jonaspleyer]

I can give Jonas PR access on this repository and pull in the changes, and also rights to push new versions to crates.io. Longer term it might be best to transfer the repository to Jonas’ GitHub account or to a separate organisation to provide continuity of referral links etc.

Thanks so much for the trust. I would be very happy to act as a maintainer of the crate. In general it is always better to have multiple people with access such that the community is not solely reliant on one individual for the long term. For now I would suggest to just give me access to the repo and crates.io such that I can start with the migration process.

If most of the changes in approxim are largely backwards compatible we can probably pull them back into approx directly. Having some sort of changelog might help users make the transition as well, but I’m not sure how drastic the changes are.

The main changes have not altered the core components of the crate. Only additional implementations for types such as Option<T> or Vec<T> were added. The test suite was only extended, not changed. So I believe that the additions should be backwards compatible. Nevertheless, we should probably create a release candidate for a new major version and then wait if any bugs occur before releasing it.

Just want to apologise for all the delay with this stuff. I’ve got a lot of guilt for leaving approx unloved for so long, which is part of what makes coming back to this difficult.

I can only agree with @stgeo. You have created a really useful crate and there is no obligation from your side towards anyone. By agreeing to grant access to the repo you have made clear that you are operating in the interest of the community and all of your users. This shows true character.

[brendanzab]

Thanks for the kind words, and for your continued interest! Let’s hold of on transferring the repo then. I’ve added you to the Github and cargo crate.

The agent based modelling stuff looks quite cool by the way!

[jonaspleyer]

The agent based modelling stuff looks quite cool by the way!

Thanks!

I will take some time (probably in the coming week) to start with the migration process and will keep you updated.

[jonaspleyer]

I will leave this issue open. For everyone reading this: If you are interested to participate in the maintenance of approx, feel free to contact me.