Possibly migrate to SciML for maintenance?

[ChrisRackauckas]

It seems like this library hasn't had maintenance for 4 years, and it's starting to show. It's been missing Apple Silicon support for awhile now, it doesn't have a Documenter.jl docs build, it's missing standard library compats, etc. I'd be happy to help with the maintenance of this library, whether it be kept where it is or (preferred) folded into SciML where the rest of the maintenance structures can then be used to keep this library up to date.

[luchr]

Hellp Chris,

unfortunately I'm busy with other projects (and in offline-life). If you want to help with the maintenance, I'm very glad.

What do you need for "folding" the project into SciML? Does "to fold" in this context mean "to fork" and then, of course, a notification-link here at this repo pointing to the new location?

What’s important to me is that all software licenses are properly followed, see the many licenses here LICENSE.md. Because all these (Fortran-)solvers were for a very long time (before julia and julia's growing ODE-support with native julia code) the only way to get state-of-the-art solvers at this time. Hence the authors and their licenses should be properly followed.

[ChrisRackauckas]

What do you need for "folding" the project into SciML? Does "to fold" in this context mean "to fork" and then, of course, a notification-link here at this repo pointing to the new location?

I mean to migrate the main repo. The reason is because we have a lot of maintenance structures doing things like having bots go around and fix up compats, test with next Julia releases, re-building binaries for new architectures, etc. and so it would be trivially easy to cover this repo if it was moved to SciML and just reused the same infrastructure. We can keep you as an admin on the repo but I just want to make sure everything in here just keeps up with the latest CI/BinaryBuilder/etc. infrastructure since we rely on it a lot in regression tests and benchmarks.

What’s important to me is that all software licenses are properly followed, see the many licenses here LICENSE.md. Because all these (Fortran-)solvers were for a very long time (before julia and julia's growing ODE-support with native julia code) the only way to get state-of-the-art solvers at this time. Hence the authors and their licenses should be properly followed.

We have no intention to change the licenses. In fact, no intention to change most of the code, mostly just making sure the routine maintenance setup automates to keep everything up-to-snuff on the latest Julia versions as they release and that pre-releases get tested and fixed before hand. This mostly came to mind because I had to patch around the missing Apple Silicon support in the build scripts here, which was fine with some Yggdrasil stuff, but if we had it in our system it would've gotten covered automatically a few years ago. So it's things like TagBot, CompatHelper, handling any version bumps, handling the eventual Julia v2 update, etc. keeping the repo alive and well.

[ChrisRackauckas]

And we'd be happy to keep the attributions to you in the README and Project.toml, since you did the heavy lifting here.

[luchr]

Let me reformulate my question

What do you need for "folding" the project into SciML?

I wanted to know the following:

What can I(!) do to prepare the 'folding' process and/or to make this process possible? Are there any tasks where I can help? I've (very) limited time, but perhaps I can help somewhere. What's the "migration plan"?
[For my availability: In a few days I'm going to vacation where I have no access to the internet at all.]

[ChrisRackauckas]

Sorry had some travel.

What can I(!) do to prepare the 'folding' process and/or to make this process possible?

The process is just to add me as a contributor to this library, and then I send it to SciML for the migration, and add you as a repo-specific admin in that org on this repo.

Are there any tasks where I can help? I've (very) limited time, but perhaps I can help somewhere. What's the "migration plan"?

The main ones are to get the modern workflows setup. I'll admit it's not entirely well documented, but Modern Julia Workflows has some information on this:

https://modernjuliaworkflows.org/sharing/#github_actions

Basically Travis.CI and AppVeyor are pretty much discontinued (bought by private equity, now don't really run with free credits) so the whole ecosystem moved to Github Actions. So first step is to migrate to github actions, like https://github.com/JuliaSymbolics/Symbolics.jl/blob/master/.github/workflows/ci.yml. Then https://github.com/luchr/ODEInterface.jl/pull/31/files and #30 should get completed so that the standard bots tag and check for dep changes. https://github.com/luchr/ODEInterface.jl/blob/master/Project.toml#L16 the compats then need to be updated to the post v1.10 form where compats are required on standard libraries https://discourse.julialang.org/t/psa-compat-requirements-in-the-general-registry-are-changing/104958 . That covers the basics. It would probably be good to all set this up with the formatter when that's ready.

[ChrisRackauckas]

#36 is probably the main thing right now, given the library does not load on v1.12