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