Migrating davitpy to archived status

[asreimer]

Given: 1) pydarn development nearing a full release, 2) the demonstrably unsustainable bloat that davitpy has become (it was pretty awesome bloat while it lasted!), and 3) the ending of the VT server that supplied data and radar.sqlite file, etc

We should migrate davitpy to an archived status. I propose we do this by either: 1) closing issues we don't think we can fix with a couple simple commits, or 2) close all issues with a won't fix and all outstanding PRs.

then making a final release with a deprecation warning and an archived status message.

Finally, we should upload this to Zenodo so that on the off chance someone needs to cite davitpy, they can actually do it.

Thoughts?

[ksterne]

@asreimer, looks as though you've already started on some of closing issues and PRs. I was almost certain that I'd made a note about this repo being deprecated. Maybe I'm thinking of the VTRST repo.

Definitely agree here once pydarn is available. I've been passing along for more than a year that pydarn was coming soon. Will be glad to see it come along.

[asreimer]

Is there a meaningful difference between waiting until pydarn is at 1.0 and archiving before? Why not just point everyone over there officially and ASAP?

Effort spent testing pydarn is better effort spent in my opinion. Leaving davitpy lingering like this only invites those "not in the know" to trying it and wasting time I think.

On Wed, Oct 2, 2019, 18:10 Kevin Sterne notifications@github.com wrote:

@asreimer https://github.com/asreimer, looks as though you've already started on some of closing issues and PRs. I was almost certain that I'd made a note about this repo being deprecated. Maybe I'm thinking of the VTRST repo.

Definitely agree here once pydarn is available. I've been passing along for more than a year that pydarn was coming soon. Will be glad to see it come along.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vtsuperdarn/davitpy/issues/372?email_source=notifications&email_token=ABDEHE7EGIB7J2Y4XHNPNDDQMVA7ZA5CNFSM4I44R3T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAGVE5I#issuecomment-537743989, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDEHEZRYYXPM7SH5UDBLX3QMVA7ZANCNFSM4I44R3TQ .

[aburrell]

I agree with @asreimer that we start closing issues with 'wontfix', since it will make it clear to people that any changes they really want made will need to be done on their own.

I also think that yes, once pydarn is release we should definitely upload this to zenodo so that both we and other people can access it. I, for instance, do not want to lose all my tdiff and FoV routines.

[asreimer]

Just to be clear, the process I've proposed is: 1) Archive davipty ASAP, or archive it after making some minor fixes and release a 0.9. Here's a nice guide on how to do this: https://medium.com/maintainer-io/how-to-deprecate-a-repository-on-github-8f0ceb9155e 2) We will not remove the source code from github 3) We will explicitly tell people what works in davitpy as part of the archiving process

Everyone should have a look at https://help.github.com/en/articles/archiving-a-github-repository

I think we should also put a message in the README and on the repo that davitpy is being superseded by pydarn.

@aburrell @ksterne what is the benefit of waiting until pydarn is 1.0 before archiving davitpy? I only see a downside in that we aren't clearly communicating the reality of the situation to prospective users and then when they post an issue wanting help, we don't help them.

[ksterne]

@asreimer, thanks for the links here on archiving. I haven't read them yet, but that's handy to know where to go. I agree on putting a message at the top of the README that will indicate that this repo is deprecated as well as where continued efforts are going. I've found some repos that don't do this and find it frustrating as I can never tell where the latest development is.

My desire to wait until pydarn is out is that it's been a long road in getting pydarn out. And while there are some that are working on getting it together, it may not happen as quickly as we all might want. That is not to say the people working on it are bad, I understand that things slip and tasks take longer to complete than expected. So I see the benefit of waiting so that the limbo period between when this is deprecated and when the next is out is minimal.

I can understand the downside/concern you've expressed that users are coming here instead, but since this repo has had minimal activity in the last year I don't know that we're getting many issues where we can't help out.

[mts299]

I am trying to avoid getting involved with this. However, it is kind of disheartening to see these comments. I have to remind you, I am the only one besides Marci with Borealis conversion developing pyDARN with other jobs. @aburrell is the main tester and reviewer with some side help from @asreimer. It would be nice to get some users to start looking at pyDARN giving suggestions and helping out if they can. We currently are on the last stretch of just getting the documentation ready before the actual release.

If you have time here to help people on issues then maybe you have some time to also help on pyDARN? The more we stay divided the longer pyDARN's release is being prolonged.

I see no issue putting a deprecated notice on davitpy, and that no further development will be on it. Archive it or leave it as is for now. But help push people over to pyDARN and help bring some of your attention there.

[ksterne]

@mts299, my deepest apologies here as I did not mean to belittle the effort that you and others are putting to pydarn. My only notes on this is that it's been longer coming than we've thought which I again completely understand as things take longer than expected.

If we think closing this down and pushing people to pydarn will help out, then lets go for it. I'm not certain it will get you much as there's been little activity here. If anything, davitpy has (had) become more of a tool for just acquiring SuperDARN data which we disabled several months ago.

I don't have much time to help people here and I'm not sure when I'll have some time to help pydarn out (not that I don't want to, I would love to help out). @asreimer, do you want to take the lead on the steps you mentioned before to deprecate and archive this repo?

[asreimer]

No one is expecting a sudden large influx of users to pydarn simply because we archive davitpy, but the fact that we have any users still using davitpy when it isn't being supported anymore is not a good thing.

In my mind it's: 1) expectation management for the SuperDARN community members on what they can expect if they use davitpy (no support anymore), and 2) pydarn is what they should look to for a python based SuperDARN community tool.

If people want to still use davitpy they can, but currently they are doing so with an implicit expectation that it works and that there is a community of developers still backing it. This is not the case. That's why I don't see any utility in prolonging the archiving of this repo. Archiving it means people can still use it, but will do so knowing that no one is supporting them.

I'll keep whittling down the issues as I've been doing when I can spare the time and make a final release PR. The PR will either have some small fixes or none at all depending on how much time I can dedicate to it.

[ksterne]

You might be seeing this from the darn-users list as well as the top-level README.md, but I've started the process of deprecating and/or archiving this repo since pydarn had it's v1 release a few weeks ago. Sorry it had slipped my mind to do this. Care to close this @asreimer (meaning this sounds like a good plan)? Again, my apologies to all here on wanting to delay doing this. I'm very excited to get more into pydarn and great job getting a first release out @mts299!

[ksterne]

I guess there is still the question of making the final 0.9 release and making a Zenodo citation. I think those are good ideas to do.