exclude known broken feedstocks from migrations

[h-vetinari]

We have a couple of feedstocks that are effectively dead, yet constantly get retried by the migrator, for example:

• https://github.com/conda-forge/hdk-feedstock
• https://github.com/conda-forge/tomviz-feedstock

Given the general reluctance to archive feedstocks, we should at least take better care with our resources. What I'm imagining is a list somewhere (either in the pinning or here) where we just hard skip any migration for that feedstock (perhaps we can leave the Version-Migrator; I'm talking primarily about the ABI-Migrators). We can pair that with an issue on the feedstock pointing this out, so that if such a feedstock ever gets revived, it can be easily undone.

CC @beckerm @jakirkham @jaimergp

[jakirkham]

Wonder if we could raise issues on these to suggest archiving

If we don't hear back in a week, go ahead and archive

---

Know there have been concerns raised about archiving before, but maybe it is worth understanding what we could fix in the archiving process to make that better

For example was thinking recently that we should consider putting archived feedstock in channel notices. Or perhaps this can be captured in the repodata somehow (maybe an extra label)? That way users can get a warning about archived packages

What other concerns should we fix to make archiving more viable?

[h-vetinari]

For example in tomviz, the statement was (~2 years ago):

Currently Tomviz supports 3.7, we plan on testing/updating to > 3.7 in future, but this work hasn't been done yet.

I guess there's a sliver of a chance the feedstock could come back. That's why I don't want to get into a general archiving discussion here, which (from experience) always get stuck. I want to discuss an orthogonal solution that can be done without nearly as much back-and-forth, and would start saving our resources on a much shorter time horizon.

[beckermr]

Mostly we're going to catch folks by surprise. They are going to make the feedstock, do some work, move on, and then in the mean time we are going to archive their feedstock because our tools are not smart enough. Then they come back and are going to have lots of questions.

I think it is important to remember that the bot (and the conda forge approach in general) is eventual consistency. There are just too many moving parts and different people involved. We have over 20k repos maintained by over 1k people (more if you count not so active folks). Given all of the possible permutations of maintenance states, responsiveness of maintainers, etc, we are simply not going to be able to design a rules-based system that makes the correct decision each time.

You should think of conda-forge feedstocks and the bot like a woven tapestry and a loom. We build the loom and set the grand design, but it is always going to be frayed a bit at the edges. However, if you take the long-term approach, hang your tapestry on a wall and step back, it's pretty awesome. 😀

[beckermr]

We can simply be more aggressive in closing migrations to solve this. Once a migration is closed, the keys end up in the pinnings always. If someone comes back to revive a feedstock, they will rerender and get all of the update prs they missed.

[h-vetinari]

then in the mean time we are going to archive their feedstock because our tools are not smart enough.

That's just not true. If there were even a whiff of maintenance on these feedstocks, we could work it out with the maintainers. But if it's years of radio silence, we shouldn't be retrying their broken feedstocks on +/- every bot run.

We can make every effort to make them aware (as I said, raise an issue on the feedstock), but long-term ignoring the worst cases eating into our resources for nothing is just absurd.

We can simply be more aggressive in closing migrations to solve this.

No. Not workable.

[h-vetinari]

To clarify: some migrations legitimately stay open for a very long time, because their respective upstream isn't compatible yet. As long as the PR has been opened, that doesn't cost us any resources. But during that time, broken feedstocks involved in these migrations keep consistently wasting bot share.

We should not be more aggressive in closing migrations where it's not merited to work around this issue. We should fix it.

[beckermr]

Yeah I don't agree here. I'm happy to discuss more but if we're dealing in absolutes we're not going to make progress.

[h-vetinari]

Which statement do you perceive as absolute? The only thing close to that is that I consider it plainly our responsibility to not retry a broken feedstock thousands of times over the course of years where nothing changes, wasting enormous resources for zero gain - that's a hill I'll happily die on, though it would seem uncontroversial to me.

How we define the threshold/criteria, how we implement it technically, and how we advertise this to affected parties are all completely open though. What I do consider out of scope are things like "just migrate faster" - we're constantly pushing the limit on how fast our migrations can go, both from a human, technical & social standpoint, and we should not make this process even harder for our maintainers, just to work around such a broken window.

I guess I'll bring it up in the next core call then.

[beckermr]

We should discuss with core, but note the bot governance is not under the purview of core in the usual way given the bot subteam charter.

I'm not looking to argue with folks. I am looking for easy wins that don't involve a lot of hand-tuned logic to make one migration out of hundreds that we run move faster.

[jakirkham]

Sorry I didn't mean to get us to a controversial place. Had thought a few years of being unmaintained was uncontroversial. Plus we have a few specifically named feedstocks. Are we ok just raising issues on those 3 feedstocks suggesting archiving, waiting a week, and if no response archiving?

Also happy to pick up the controversial part in the next core call. We shouldn't shy away from hard conversations either

[h-vetinari]

a lot of hand-tuned logic

I proposed a manually curated list of worst cases.

to make one migration out of hundreds that we run move faster.

How is saving resources across all bot runs related to any particular one migration?

I'm not looking to argue with folks.

Neither am I. Please don't dismiss a given topic out of hand, then we can have a more productive discussion.

[beckermr]

Yes proposing to archive the feedstocks in the usual way seems fine.

No reason to be sorry. We should discuss things openly of course!

[beckermr]

I'm looking back and not seeing where I dismissed things out right in an absolute sense. I assume I did and I am sorry for that.

We should discuss more!

[h-vetinari]

Alright, no worries, sorry also from my side if I came across the wrong way.

As noted in #2612, this issue would be resolved without any further specific action if we just open PRs for long-failed attempts, which would only be beneficial to my mind anyway for several reasons.