previously: [Pharo-project] nil key in last literal in instance side methods (reproducible)
No, I'm just suggesting a poor man's simple diff in a mailing list, like squeak trunk. -1) inbox diff : you open a review to the whole community for comments,
ok, why not on a separate mailing list that might make sense
-2) commit phase (whatever the checks you perform now are unchanged, except you have to take above review into account) -3) trunk diff : you open a last chance review (or post mortem analysis) to retract/correct commits
that is (almost) up and running with our github export: https://github.com/PharoProject/pharo-core
It's totally informal, and why would it work? You have to answer this question first: - how many people have ubiquitous web access to read the code and qualified enough to emit a useful comment? - how many people are downloading an image, updating to some version, opening a MC browser, browsing the diffs?
You are proposing a much more ellaborated process to review code before integration. I agree, this information belongs to issue tracker. But formalizing and programming this process is involving (think about concurrent solution, roles, requests/answers timelines etc...) As you said, who will do it?
From pragmatic POV, I prefer a light process that provides some help, than no help at all (which is close to what you get with current state of issue tracker). The code producing the diff and sendig the mail already exist, (you'll have to handle SLICE though)... Bonus: it's Smalltalk code.
If you prefer to wait for something better, then let's wait...
well the solution would be to simply switch to git for the whole version management. github.com provides an excellent example of how to deal with you aforementioned issues. - pull requests - single commits - full history plus - everything can be commented / annotated from within the website => 0 setup needed so for me something like github is the future for development.