search

conda-forge / cfep

conda-forge's Enhancement Proposal
BSD 3-Clause "New" or "Revised" License
18 stars 24 forks source link

CFEP-8: Too Big to Fail #11

Closed CJ-Wright closed 4 years ago

CJ-Wright commented 6 years ago

Proposal for how to handle packages which are too big to fail

ocefpaf commented 6 years ago

Since we have qt there why not add gdal :wink:

CJ-Wright commented 6 years ago

Feel free to add that under 3 (Systemic Risk). I'm sure that we all have packages which we experience as posing as a systemic risk, and I don't know if I can compile a metric to evaluate that kind of risk.

CJ-Wright commented 6 years ago

@conda-forge/core I think this is ready for review/discussion.

scopatz commented 6 years ago

Is this something that we are voting on?

CJ-Wright commented 6 years ago

@scopatz I guess this falls under the Overall workflow and packaging policies clause, so yes?

scopatz commented 6 years ago

I think we need to be more explicit about when a vote is being called for. Probably @conda-forge/core

scopatz commented 6 years ago

Here are my thoughts on this as it stands:

  1. It is certainly true that there are packages that are too big to fail and this gives some fine criteria for defining them.
  2. I am not sure that I believe that "having a member of core as a maintainer" is a useful or approiate thing to do for most feedstocks, even TBTF ones.
  3. I am confused as to how the other mitigation point of having a reviewer helps. Don't these PRs have to have a review already? And aren't most of the migrations PRs put out by the bot?

To elaborate on point 2 a bit more, TBTF feedstocks where there is not a core maintainer simply means that no member of core is personally invested in those packages. I don't think that we should, by fiat, force people to be involved in a feedstock they don't care about. On the other hand, say there are maintainers (who do care) but happen to not be a members of core, and their packages suddenly cross the threshold and become TBTF. Why should a member of core be added to their maintainence team when they were doing a perfectly adequate job before their project breeched the TBTF criteria?

The above is basically to say that the conda-forge has a federated model, and I think this is one of its major strengths. This CFEP seems to want to give the executive (core) more control and oversight without specifiying a clear (to me) mechanism for addressing the TBTF problem.

It seems to me that most TBTF issues are going to be wholly distinct from one another, in which case adding a core member to the mix doesn't necessarily help.

I am not trying to shoot down this CFEP as a whole. But I think it could be restructured to something less hands-on. For example:

CJ-Wright commented 6 years ago

I'll flesh this out more tomorrow, but we might consider making some tbtf recipes run their full test suite during builds and that their upstream dependencies run tests via the downstreams meta.yaml key. This might help to find issues before they become systemic and don't require additional maintainer or core overhead beyond the initial recipe fix.

CJ-Wright commented 4 years ago

I think this should be tabled for the moment, so I'm going to close, but not delete the branch so we can open at another date if needed.

ericdill commented 4 years ago

I'd change the Status to "Deferred" and merge this in.

CJ-Wright commented 4 years ago

@ericdill ready for merge

isuruf commented 4 years ago

Agree with @scopatz on this. For eg: I've been building the compiler packages and blas packages and nobody has been interested in helping out. That's fine by me. What's not fine is that I have to wait for somebody who is not interested in helping out when I want to fix something.