On Mar 15, 2013, at 10:24 PM, Tudor Girba <[email protected]> wrote:
> Thanks for the report. > > It's great to see you doing a retrospective. I hope you will do it regularly > :). Yes we will do that everything cycle. a cycle will be around a month. > > Cheers, > Doru > > > On Mar 15, 2013, at 9:49 PM, Stéphane Ducasse <[email protected]> > 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." > >
