A process proposal for 3.10

Giovanni Corriga giovanni at corriga.net
Mon Oct 16 08:31:02 UTC 2006

Hi all,

since we've started discussing 3.10/4.0, I'd like to relay some thoughts
that I've expressed some times ago on #squeak about a possible
development process for Squeak 3.10.

This proposal is based on two points:
- decentralization of development
- fixed duration of iterations ("timeboxing")

"Decentralization of development" means moving most of the
responsibility of development from the release team to the single
package mantainers (stewards). The release team should just be an
integrator of the code blessed by the stewards, and should facilitate
coordination between the stewards of different packages.
"Timeboxing" means having a fixed length release cycle, at the end of
which a new stable version is released. This means that if there are
some problems with a new feature, the deadline doesn't get postponed;
instead it's the feature that gets dropped from the current development
release and rescheduled for the next release.

How would this work? Here's a more detailed description.
The SqF board will appoint a release team for 3.10. This team will have
3-7 members; 5 would be the sweet spot.
The first task for the release team will be to find a mantainer for each
one of the packages currently in the image. If they can't find a
mantainer for a package, than said package _will get dropped from the
image_ without any further discussion.

After having found mantainers for every package, there's a package
selection phase, during which the team and the maintainers:
- decide which packages currently in the image should get removed from
the image and turned into SqueakMap-loadable packages.
- decide which new packages can be added to the image or replace other
packages currently in the image.
Input from the community and the stakeholders will be taken into

After deciding which packages will be in the 3.10 image, the release
team, the mantainers and the community will work on creating the release
Each package mantainer will announce what it plans to do for 3.10. The
release team will integrate these proposals into a coherent release
plan, solving possible conflicts and coordination problems. The
community will be able to make comments and/or requests.

After all these steps, which shouldn't take more than a month, the
development of 3.10 can start.

Development will have three stages:
- a 3 months alpha stage
- a 2 months beta stage
- a 1 month gamma/RC stage.
The deadline for each stage will be decided at the beginning of the
Every week during each stage the release team will integrate the new
releases of each package blessed by the package mantainers.

Package mantainers will be the main responsible for development of their
package and they'll be free to manage development as they like; ideally
they should create a development team.

If at the end of the alpha stage some of the work items of the plan
aren't near completion, _these items and the corresponding code will get
dropped_. If this is not possible, the code will be kept in the image,
but it will have not to break the other code in the image.

During the beta and gamma stages, no new features will get added to the
image; only bug fixes can go in. During the gamma stage, only
showstopper bugs will be fixed; other bug fixes (eg. cosmetical fixes)
will be scheduled for 3.10.1.

During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or
whatever) will get appointed and will work with the package mantainers
to form the release plan for the next version.

Here's a an example of how things could possibly work.

Release plan:
During phase 1, the various package mantainers propose work items. So
let's pretend that...
  - VMMaker team will want to:
    * integrate the async event patches useful for SqueakGtk.
    * integrate the Ffenestri code in all VMs, including the Unix one.
    * work with the Kernel team/maintainer on CompiledMethod cleanup.
  - Nebraska team will work on removing it from the image.
  - Pavel will want to work with various mantainers to integrate his
patches for his KernelImage system.
  - Tools team will want to:
    * better integrate AST and the Refactoring services.
    * make Omnibrowser the default browser.

Now let's pretend that at the end of the alpha stage, the Tools team
still hasn't produced an Omnibrowser based debugger. Since it's the end
of the alpha stage, the OBDebugger will be punted to the next release,
and 3.10 will have a class browser based on OB but still the old

I believe a process such as the one I'm proposing can work and help
produce good quality releases.

I'd like to hear comments on this, even if they just say that my
proposal sucks.



More information about the Squeak-dev mailing list