Be explicit about maintenance status and alternatives

[juliohm]

@ettersi please check if the warning and alternatives are well-placed in the README.

[evetion]

I don't think this is true? Looking at https://github.com/JuliaGeo/Geodesy.jl/commits/master/, there's activity, so the package works and is maintained to keep working.

[juliohm]

Please don't pretend that commits to Readme or github actions count as true maintenance. EDIT: Linking the [comment](#99 (comment)) where all this non-sense discussion started so that other people can assess the situation with the full context in the future.

[evetion]

Dude, you cannot single-handedly deprecate a package (and prominently plug your own package while doing so) without consensus, let alone the involvement of the original package authors or maintainers (insulting them in the process). It's incredibly rude.

[juliohm]

Facts:

1. Commit history tells the true maintenance status
2. Authors are no longer active (maybe not even using Julia)
3. I did not plug my package. I added TWO alternatives that are actively maintained

Now, if you prefer to insist on this situation here where you recommend Geodesy.jl over the alternatives, arguing that it is actively maintained because of some personal agenda, then go ahead. I don't really care.

If the authors of Geodesy.jl jump in supporting your suggestion, please feel free to undo this PR.

[juliohm]

Attaching the screenshot below for future reference, to eliminate any doubt in case someone is curious:

The source code is not touched in 2 years. The only files modified in the last year are the README (by me), LICENSE and .github actions.

[lazarusA]

I'm sorry @juliohm but that's not a good metric. And actually, I would say that we should have more working packages like this, namely, low maintenance. Would you put the same warning for DelimitedFiles?

Maybe, a more productive approach should be to listen to the community and act accordingly.

[juliohm]

I'm sorry @juliohm but that's not a good metric. And actually, I would say that we should have more working packages like this, namely, low maintenance. Would you put the same warning for DelimitedFiles?

DelimitedFiles is a standard Julia library. Comparing it with a normal Julia package in terms of commit frequency does not make sense.

The real problem here is that the alternative packages suggested in the README do not belong to JuliaGeo, and are not maintained by the people in this organization. Unfortunately, rigorous technical judgement is out of the room.

Maybe, a more productive approach should be to listen to the community and act accordingly.

I am listening to the community, and this is not the same thing as listening to the tiny group of 4 or 5 people here.

EDIT

Linking the comment where all this non-sense discussion started so that other people can assess the situation with the full context in the future.

[ettersi]

@ettersi please check if the warning and alternatives are well-placed in the README.

I'm happy with the consistency of the new README. However, like others I'm a bit surprised by how decisions were made here. I don't think it sets a good precedent if single individuals get to decide that a well-established and still working package is now unmaintained.

[juliohm]

Does the word "actively maintained" mean something different to you? I'm seeking evidence of a person driving change, implementing bug fixes, or improving the design anyhow. This is not a subjective matter. I don't care if that tiny group of people always jumps in issues to fight against knowledge sharing and efforts outside JuliaGeo. My only concern is always and will always be the community of unexperienced users who are having a terrible experience because of that. Em ter., 9 de jul. de 2024, 01:17, Simon Etter ***@***.***> escreveu:

…

@ettersi <https://github.com/ettersi> please check if the warning and alternatives are well-placed in the README. I'm happy with the *consistency* of the new README. However, like others I'm a bit surprised by how decisions were made here. I don't think it sets a good precedent if single individuals get to decide that a well-established and still working package is now unmaintained. — Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3IDZC246URUFSCNX4DZLNP67AVCNFSM6AAAAABKQRQ2YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJWGQ3TGOJXHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[visr]

In #97 I indicated the package is not "actively developed", and reached out to @ettersi to discuss the future of these packages (CoordRefSystems.jl didn't exist yet). Also I mentioned we should list alternatives. So naturally a PR like yours is welcome to clarify it to users. What people are upset about is that you pushed to main without giving reviewers a chance in #100, then doubled down after concerns in this PR. That is not ok. Especially if you never contributed to this package before and prominently plug your own package.

Yes, "actively maintained" means something different to me than "actively developed". There are no open bugs and it is receiving light maintenace when needed. In terms of https://www.repostatus.org/ "Inactive" probably comes the closest. Some users prefer to use stable packages that don't see breaking releases. CoordRefSystems.jl was created 5 months ago and is now on the 9th breaking release. That's fine, but that means it probably isn't for everyone at the moment, consider clarifying that in the readme.

As I mentioned in #97, it would be great to move towards one standard package that is properly maintained. In #99 (comment) you mention that your recommendations are always based on technical criteria. I haven't seriously looked into CoordRefSystems.jl yet, but at this moment my main concern is not technical, but social. These kind of discussions drain my energy and make me want to quit open source. I feel like it's about as effective as talking to a brick wall. Hence I'll lock the issue. Let's improve on the current text in another PR.