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 >
