New Resolver: Rollout, Feedback Loops and Development Flow

I’ve been thinking a bit about #988 (duh!) – specifically how to roll it out so as to minimize breakage and maximize the opportunity to get useful feedback from users.

Filing this issue now that I finally have both thumbs + time at hand to do so. Obviously, all of what follows is up for discussion. 😃

---

My current plan for rolling out the new resolver is based on exposing the new resolver behind a flag. The flow would be to not document it initially and add big fat warnings on the use of the flag. Once it is less experimental and more beta-ish, we can start inviting users to play with the new resolver. This would involve CTAs to users for asking them to try it out and provide feedback. This information might also be printed when run with the flag.

In terms of feedback management, I am thinking of requesting for feedback on a different repository’s issue tracker. The reasoning behind putting issues on a different issue tracker, is to minimize noise here + allow more focused discussions/investigation. I’d bubble up anything that’s more than a “bug in the resolution” to the main issue tracker (this one).

In terms of transitioning, I think once there’s enough confidence in the new resolution logic, we can look into how we want to handle the transition. Having put this behind a flag, we’ll have 2 options – directly switch over in a release or “stabilize” the new resolver and do a (maybe multi-release?) “transition period”. I do think that we can do the transition planning later, when we have a better understanding of the exact trade-offs involved.

In terms of git/GitHub, this is probably the first “experimental” feature implementation within pip. FWIW, I’m planning to do experiments etc on my fork and regularly merging progress to pip’s main repository itself (solely code, into pip._internal.resolution). I don’t want to be noisy on the main repository but I do want to keep master in sync with work on this.

---

Note that I’m putting #5051 as a blocker for this work because of how painful dealing with build logic was when building the prototype.

[pfmoore]

I’m young, dumb and optimistic

😃 And I’m sometimes too old, weary and cynical. Let’s go with your philosophy, it sounds much better 😃

[di]

Here’s my rough plan:

• Start a discussion on discuss.python.org asking for support
• Direct folks to a Slack channel that could serve as a communication channel between everyone
• Start a document outlining some FAQ and our responses
• Include a decision tree for new issue -> triaged issue
• Share this with the channel once we have a known release date
• Try and roughly schedule volunteers to be online & triaging in the days following the release