While I am hardly doing any work here, I would think it might be a way to:
- For someone brave to revert the dispatcher patches. I suspect vrurg's guidance will be helpful to note what should and shouldn't be reverted.
- With this, we can do a release. There are plenty of goodies, actually: GC fixes, changes etc.
- If vrurg project is not dependant on some features that will be implemented in next months, one can just stay on certain commit for this project. I know it indeed causes nuisance, but with rakudobrew / whatever and a bit of scripting I wonder if that'd be really bad.
- The project or some test cases from it might be helpful as regression tests for the new dispatcher implementation as well.
End of June is pretty ahead. If new dispatcher stuff will be in place before that, nice! If not, is it a problem to say "This requires some experimental features which will land in master soon"? Or "We implemented an experimental support of that and now working on it being more awesome"? I am not aware of the scope of the project, so possibly this is not an option, tell me if that is not.
This way, we have:
- A release without performance loss, with fixes, and with Not Fixed, But Stable behavior of dispatchers.
- Potentially "all works out nicely" for vrurg's project and in the worst case it is just "You have to use my rakudo branch or wait a bit" at the conference.
- jnthn has lots of time ahead and the deadline is soft here.
ping @vrurg for comments.