Improve acceptance speed repodata-patches-feedstock

[julian-belina]

Comment:

Hello everyone,

I would like to suggest an improvement to the RepoData-Patches-Feedstock feedstock using a bot. Would it be possible to set up automatic acceptance of merge requests for the feedstock maintainer that should be patched on GitHub at https://github.com/conda-forge/conda-forge-repodata-patches-feedstock?

I have been thinking about how to deal with the upper dependency constraints in the packages that I maintain. In my opinion, there are currently three options for dealing with upper constraints:

1. Create a merge request at https://github.com/conda-forge/conda-forge-repodata-patches-feedstock, which can take a long time to be merged.
2. Create a new build of the affected library version. Unfortunately, this can result in the old version being installed in new environments, as the solver identifies 'a better solution' with the old version and its more relaxed constraints.
3. Set the upper constraint to the dependencies that have actually been tested. However, this could result in the need to release many builds.

The best option would be to enable speedy merge requests for RepoData-Patches-Feedstock. This would allow fewer builds and updated package metadata to be combined.

[hmaarrfk]

You can either be:

1. Conservative with the upper bound on dependencies, and then "loosen" with a new build.
2. Loose with upper bound on dependencies, then use repo data patches to tighten them.

You are right, "2" is dependent on someone at conda-forge-core merging.

IMO, if you really care about "correctness" you should use "1", but that can lead to alot of churn.

But there isn't really anything we can do with the current infrastructure due to the centralized nature of the patching process. It is quite invasive, and should be used sparingly.

To "improve" the situation, continue your involement with conda-forge, propose a new process, and become a member of some "core" team (or adjacent, such as staged recipes team) to help out!

[beckermr]

I'd be ok allowing staged-recipes maintainers merge repodata patches as well.

[hmaarrfk]

the challenge for me, is that it is "separate" from the "feedstock" itself, thus harder to "audit".

If we "moved the patching" to the individual feedstocks, then it would be easier to audit and thus, help when things go wrong.

[julian-belina]

I'd be happy to get involved, but I don't currently have enough knowledge of the Conda-forge infrastructure to suggest an alternative solution.

I thought the bot solution I proposed could be implemented with moderate effort compared to changing the whole infrastructure. However, I think there should be some kind of check to ensure that only the project's maintainers can apply patches to the libraries they maintain.