September 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] pharo-2.0-tests Â» mac - Build # 331 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» linux - Build # 331 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 330 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 330 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» linux - Build # 330 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» 32,win - Build # 328 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 329 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» linux - Build # 329 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 329 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

Re: [Pharo-project] integration/review process

by Frank Shearar

On 7 September 2012 11:52, Camillo Bruni <camillobruni(a)gmail.com> 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

Sept. 7, 2012