recipes that are too big to fail

[CJ-Wright]

There are core recipes which are "too big to fail". These are recipes, if they are built incorrectly will cause systemic problems across the ecosystem. For example the recent move of some recipes to noarch could have caused problems with conda itself.

We need to have tighter control of these recipes.

I think that we need to (at least):

1. Have all (or at least some) of core as maintainers of these packages
2. Require review approval to merge

[ericdill]

Can you start putting together a list whose goal is to provide exhaustive coverage of these too big to fail recipes?

[CJ-Wright]

Sure, although some help on that front would be good since this can be subjective.

[CJ-Wright]

I think we should also put this info in extra since this is a property of the feedstock best managed there.

[ocefpaf]

I would start with gdal, openvc, and qt.

[msarahan]

I disagree with gdal and opencv. I'm on the fence about qt.

Don't get me wrong, those are important packages. I don't believe that they are systemic, though.

Python, conda's core deps, the key compression and image libraries (bzip2, zlib, jpeg, libpng, libtiff) are more what I think of for this topic.

[ocefpaf]

I used gdal as a guide b/c all of

bzip2, zlib, jpeg, libpng, libtiff

are its dependencies. If we can rebuild the stack up to gdal we get roughly 80% of the important packages.

[CJ-Wright]

Side note, can we have a core Jinja variable which lists the core developers and then add that to the maintainers for these packages? That way we don't need to explicitly add everyone and as the make-up of core changes these recipes change too. My biggest concern is how conda smithy knows who to add to the feedstock, does it render the recipe?

We'd most likely want to put this variable somewhere central.

[ocefpaf]

I like that idea but maybe we may want that to be a subset of the core (maybe volunteers only?).