On
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, -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
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â¦
is there a setting in ss3 that can do that? How this is done in squeak?
Nicolas