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.
-----------------------------------------------------------------------
PHASE 0: RELEASE TEAM FORMATION
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.

PHASE 1: RELEASE PLAN
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
account.

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
plan.
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.

PHASE 2: DEVELOPMENT
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
iteration.
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.

EXAMPLE
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
debugger.
-----------------------------------------------------------------------

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.

	Ciao,

		Giovanni