DISCUSS: pause boost migration

[h-vetinari]

Hey @conda-forge/boost @conda-forge/core

I'm seeing way more breakage (from the first couple of PRs) for boost 1.86 than we've seen for 1.84 and 1.82. That impression may be subjective, but in particular it seems that there were a bunch of deprecations executed in boost::filesystem since 1.84 (removed members and even headers) that several projects seem to be running into -- so far 12 out of the feedstocks for which we have PRs:

• Rebuild for libboost 1.86 casacore-feedstock#92
• Rebuild for libboost 1.86 collada-dom-feedstock#12
• Rebuild for libboost 1.86 dakota-feedstock#50
• Rebuild for libboost 1.86 fenics-feedstock#215
• Rebuild for libboost 1.86 hpp-util-feedstock#18
• Rebuild for libboost 1.86 hugin-feedstock#63
• Rebuild for libboost 1.86 ledger-feedstock#39
• Rebuild for libboost 1.86 mongodb-feedstock#95
• Rebuild for libboost 1.86 qvina-feedstock#8
• Rebuild for libboost 1.86 scine-utilsos-feedstock#16
• Rebuild for libboost 1.86 standardese-feedstock#12
• Rebuild for libboost 1.86 vina-feedstock#18

AFAIU, to a degree the higher cadence for boost was predicated on these migrations running pretty smoothly. Since boost 1.86 is very fresh, we may want to give the ecosystem some time to adapt before we try this. The alternative is that the migration runs more slowly, and/or that we need to patch some things in affected feedstocks.

We can also delete the migrator instead of pausing, this PR is just to discuss that topic. I'm fine with letting it run, pausing it, or deleting it and retrying in a few months.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[hmaarrfk]

pausing it would really hurt packages that have already migrated.

i would rather delete to pause.

[beckermr]

We should let it run, marking it long-term if needed.

[isuruf]

If it's going to be long term, then it'll have to be a matrix of two builds. Otherwise, there'll be a fragmentation of packages for a long time. Will have to choose between deleting (not progrressing) vs two buidls (longer CI)

[h-vetinari]

If it's going to be long term, then it'll have to be a matrix of two builds.

Agreed. Though we've regularly taken 2-3 months for boost migrations without labeling them them longterm. Now that there's a bunch more PRs from the migrator, it doesn't actually look all that bleak. A bunch of them are running into the removed factilities in boost::filesystem, but overall I'd suggest that we give this at least ~2 weeks to see how things go. If we find that we're hopelessly blocked somewhere important, then we can switch to longterm with the double version.