Thanks for the report. It's great to see you doing a retrospective. I hope you will do it regularly :). Cheers, Doru On Mar 15, 2013, at 9:49 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Hello happy pharoers

Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process. Here are the notes taken by clement from the meeting led by esteban with all the team here.

Pharo 2.0 Retrospective meeting by Esteban Lorenzo

The Good • BugTracker as Backlog • Sprint / mini - sprint / pair programming • Locking changes before release • Community getting involved • Web doc • jenkins : the monkey, zeroconf script • Smalltalkhub The Bad • Trello • We need a place to backlog what to do. We should use the FogBugz bug tracker • Long development cycle (1 year), Focus problem : most things works but are not finished • We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements. • New failing test in Jenkins, Red builds on jenkins stayed forever • We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users • In case of a red build, we need a quick meeting to pick someone to fix it. • We need to fix the red builds on the friday' mandatory mini sprint • Integrator bottleneck • More intelligent monkey • better tools (spec tool idea from Esteban where you just click accept and the slce is integrated) • New features accepted only with tests and comments • Only slices accepted no more change sets • Pointless discussions on the mailing list • Documentation : class comments, ... • do not integrate undocumented features • add code critics features in the monkey • change the template of the class comment The Ugly • 2 weeks lost : broken image during ESUG • 2 weeks lost : beginning of the year : no VM working, jenkins couldn’t test things. • -> we will staged development. • Communication failed : team and community • For new features, send more mails to the Pharo or RMOD mailing list and less to the RMOD mailing list or private mails between few people • Infrastructure • VM : stability • Stability : 1 VM release per Pharo release. 1 official Vm which is not just some VM from a build. • Stability : VM not release if an acceptance list does not work with the VM. The acceptance list is for now all the Pharo core, seaside and Moose

-- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

Stéphane Ducasse wrote:

Hello happy pharoers

Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process. Here are the notes taken by clement from the meeting led by esteban with all the team here.

Pharo 2.0 Retrospective meeting by Esteban Lorenzo

The Good

All great initiatives and really adds a lot to the professional feel of Pharo. Nice to see such a review.

The Bad

Long development cycle (1 year), Focus problem : most things works but are not finished We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. As a user this is really interesting and attractive. Here is a related article on Software Inventory [1] by Joel of Trello & Fogbugz fame. Some of the philosophy is a little strong for me, but mostly it sounds right. [1] http://www.joelonsoftware.com/items/2012/07/09.html.

With a faster release cycle, users might find 'major.minor.bugfix' semantic versioning more useful. Perhaps if submitted slices could be tagged new-feature or bug-fix that would help the CI and integrator automation. The CI could automatically take care of semantic versioning the builds, replacing the current #20534 type of build name. I understand that limited resources is an impediment to managing multiple branches, but perhaps it gets easier with CI and integration automation, such that only bugfixes directly advance the mainline while new-features are tested against the mainline and various combinations of each other.

Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements. New failing test in Jenkins, Red builds on jenkins stayed forever We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users In case of a red build, we need a quick meeting to pick someone to fix it. We need to fix the red builds on the friday' mandatory mini sprint

Perhaps if a build is red for too long there can be a default mechanism to revert the last change. cheers -ben