That would be much much better than what we currently have with mix of code agnostic google issue tracker + ST only MC repository... Another plus is also to make code visible/searchable/indexable outside our community, be it with less specialized (not so less powerfull) IDE.
Nicolas 2012/9/7 Frank Shearar <[email protected]>: > On 7 September 2012 11:52, Camillo Bruni <[email protected]> wrote: >> 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. > > And in answer to Nicolas' comment about ubiquitous web access, GitHub > can mail interested parties when something interesting happens - a new > issue, issue state change, new comments - and you can reply to those > via email. > > frank >
