List of defunct packages

[CJ-Wright]

After version bumping all the bobs I found out that they may be defunct.

Would it be possible to keep a list of these defunct packages somewhere?

[djsutherland]

So what does "defunct" mean? It seems like the packages are still developed, but the maintainers aren't actively maintaining the feedstock anymore, because now they maintain their own channel (info).

In some sense that doesn't matter? We can still maintain conda-forge versions of the packages, if we want to, we just maybe need a different maintainer to do it. That said, it seems like basically nobody is using the recent versions, though people did use the older ones, probably because their website used to instruct people to use conda-forge and now it doesn't; so maybe it's not worth actively maintaining the feedstocks.

[CJ-Wright]

I agree "defunct" means that is the code is still good but the package isn't being maintained.
The questions that come to my mind are:

• Is there an issue if security fixes are in new versions but we don't bump?
• What do we do if the maintainers don't maintain the package?
• Do we actively seek new maintainers?
• Do we have a group of foster maintainers which take over in the interim?
• Should we have a list of feedstocks that aren't actively maintained so we can a) tell users b) provide a place for foster maintainers to go to see which feedstocks need help?

[183amir]

About bob (https://www.idiap.ch/software/bob/) packages, since we already have our own channel, we don't want them to be available in conda-forge (at least the new versions). Please do not consider maintaining them here as well. It would just confuse our users and burden you with the maintenance. I am still interested in conda and conda-forge though and contribute from time to time.

It would be great to mark the feedstocks here somehow as defunct or archived so people don't try to fix them when somebody does a major update in all feedstocks. In Gitlab you can archive repositories (basically disables pushes to the repository and disables issues and pull requests) but I don't know if Github has such capability.

[CJ-Wright]

I think GitHub can also archive, but I don't think that would be enough. Ideally we'd also put something where the bot could find it (especially for bob, since building everything just to have the PR be rejected would be very painful use of time)

[isuruf]

How about,

extras:
  deprecated: true

?

[183amir]

Why wouldn't Github archive be enough? Can't your bot check that? Archived projects usually do not even show up in searches.

[183amir]

Having something in the recipe would not disable the issues and pull requests. So I will still get notifications from the feedstocks. Adding deprecated:true to the recipe means now you need to write code to automatically parse it and be aware of it too.

[CJ-Wright]

One could do both. However, having the meta.yaml be the singular source of truth might be a good thing.

[scopatz]

I am in favor of the deprecated: true, as it seems the most straight forward way to sunset a package.

[CJ-Wright]

@conda-forge/core thoughts?

[183amir]

So you want to go over all these 30 feedstocks and push deprecated:true into their recipes and then write a bot which reads that recipe and archives the github repository?! Can't you just use Github API to archive these feedstocks? https://developer.github.com/changes/2017-11-08-archiving-repositories/

[scopatz]

@183amir - I think that is a separate question. We may indeed want to archive some repos, the question we are trying to answer here is how would we even know which repos to archive in the first place. It seems like adding something to the meta.yaml is the easiest way. Ideally, we'd have a solution that works for all of conda-forge, not just N specific packages.

[183amir]

how would we even know which repos to archive in the first place.

In order to archive a feedstock, someone must raise an issue like this one. So you would know to archive it. I don't really see a point to go through all these hassle for archiving feedstocks. Someone must raise an issue before conda-forge/core goes and archives the feedstocks. Then you could have a simple script somewhere that uses Github API to archive feedstocks:

$ archive_github_repos bob.extension bob.io.base ... bob

Only conda-forge/core can archive feedstocks.

Maybe you want to know which ones are archived or not. You can use Github search filters for that.

[183amir]

okay I see where the confusion is coming from. You may be thinking that any feedstock maintainer should be able to deprecate a feedstock (hence the meta.yaml approach) while I think only core should be allowed to do this.

Well, I guess this is a decision for core members. I would say since core will not be getting a lot of requests like this, maybe you can do it with a simple script for now?

[scopatz]

Yeah exactly. Core is overloaded as it is. Anything that can reduce the burden very welcome :)

[183amir]

Yes, but have you considered the abuse of this? What if maintainers don't understand what this is for? What if someone wants to maintain the feedstock after it's archived or archived it by mistake? Core will need to unarchive it, right? Or you are going to have an automatic approach for that too?

[jakirkham]

Raised this on gitter somewhere, but having an empty maintainer list seems like the easiest way to mark something as no longer supported (and archive-able). There's less chance of misunderstanding the meaning of this change as it clearly means I don't want to maintain feedstock X any more and no one else is stepping up for the job. We could also reverse it by having a maintainer take over. Though core will need to interceded at that step as @183amir noted. That said, core already needs to step in when a maintainer goes AWOL. This would merely formalize that process.

Going to the points on abuse, only maintainers of an existing feedstock (or core) could do this operation. Even if someone submitted a PR that was not in this group, it would be reviewable and mergeable by the aforementioned group. So am less concerned about abuse here. It's true core could do this stuff manually. However as with most automation in conda-forge, it's about improving the reliability of the process.

If we are concerned about that change going in undetected by a less than sufficient review, we could have the linter point out any membership changes and ping relevant parties. Have already been thinking about this idea of late. Though in practice have not seen a need as people are pretty good at self-policing membership changes on individual feedstocks as other maintainers are friends and colleagues that they are interested in keeping good relationships with.

[jakirkham]

Related: We may opt to move packages of unsupported feedstocks to an archived label instead of outright deleting them. That way users can choose to get them if they need to and we can move them back if it was a mistake (for whatever reason).

[CJ-Wright]

Just as an update, currently the autotick bot handles archived repos by noting them as such (in the node attributes) with the PR fails saying that the repo is archived. The autotick bot then doesn't try to PR against that feedstock. If the repo was un-archived then we would need to reset that attribute and the bot would start PRing against that again.

[djsutherland]

@CJ-Wright says (and I agree):

It would be nice to have a webpage where we list the archived feedstocks in case someone wanted to become a maintainer.