2012/9/7 Camillo Bruni <[email protected]>: > > On 2012-09-06, at 22:26, Nicolas Cellier <[email protected]> > wrote: > >> 2012/9/6 Mariano Martinez Peck <[email protected]>: >>> >>> >>> On Thu, Sep 6, 2012 at 9:45 PM, Nicolas Cellier >>> <[email protected]> wrote: >>>> >>>> A bot providing simple diffs would help more eyes reviewing code... >>>> By now this important work is restricted to a narrow team of busy >>>> active developpers. >>>> Of course, CI may help a bit, but monkeys don't read code they just >>>> evaluate it. >>>> >>> >>> I am not sure if the changes in this slice are important. I think it just >>> happens that for certain reason, we have this problem of the last literal. >>> >> >> I just can't tell if it would help or not, without diff I'm totally blind ;) >> But sure, a correct code can uncover a bug elsewhere... > > Sorry I don't get it? where do you want a diff? on the google code website? > -> we thought once about writing an external website doing that > - list the changes > - list the results from code review > - list the test results > > basically each bugfix should result in a "review" image which can be > downloaded > and checked... > > but then again, somebody has to write it... >
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... Nicolas
