A process proposal for 3.10
andreas.raab at gmx.de
Tue Oct 17 04:45:26 UTC 2006
Hi Giovanni -
I fully agree with the meta goals of your proposal, namely to enable
people to do their own development and to limit the amount of time spend
on each individual part of the release.
That said, I'm in almost complete disagreement with the rest of your
proposal ;-) The fundamental flaw in it is that you are trying to commit
other people's time. Starting from "the board appoints a release team"
(phase 0) over "the teams announce the development plans" (phase 1) and
"code will get dropped" (phase 2) up until "the VMMaker team will want
to..." (the example) you're happy committing other people's time. In my
experience this has *always* been a fatal error in a volunteer open
The *only* time you can commit is your own. And given that, how much of
your proposal works if the only time that you can count on is your own?
Even if we want to change the release process we cannot change some
fundamentals about the environment we're in. And one of those
fundamentals is that (on a scale where it matters) you can't tell people
what to do. They're doing it voluntarily, they're doing it for their own
reasons and trying to change that simply won't work. To give a more
concrete example, the maintenance work I do for FFI, Graphics, Balloon,
and Compression packages is purely a volunteer effort. If you ask me
about my "development plans" for the next six months, all I can say is
"uhm ... ". Most importantly, because I have a fulltime job in a startup
I for example couldn't possibly commit to a six months active
development plan. It's simply not doable and even if it were I'd reject
it on the grounds that unless you pay me for it I'm not going to treat
this serious enough to make six month plans ;-)
Both Stef and Markus understand that basic point. They both understand
that in reality, all they can count on is their own time and they have
reacted by investing more and more of their own time and effort in the
process. And I would like us to change that process from one that leaves
people burned out into one that can be done in a reasonable amount of
time with a sustainable amount of energy.
That change starts by admitting that we're all volunteers. Whether
something will happen depends on so many factors that it's basically
useless to try to do serious upfront planning for it. And again this is
meant on scale - for each individual team it may make perfect sense but
on scale I think you really can't.
To emphasize that point even more I'll give you two recent examples:
First, we have been talking for *years* about changing the source
pointer in the methods. That it happens *now* is (from my point of view)
exclusively due to the fact that we got a new sources file in 3.9 and
lost the entire previous history for the single reason of the source
limitations. Could anyone really have planned for that? I don't think
so. Second, the SSL implementation we got recently. A while ago we
started looking at SSL ourselves and decided to go with OpenSSL - we
talked about Crypto team and their work but honestly, I would have
called anyone a nut who would have told me that this stuff will be ready
by now (I probably would have just laughed them out of the room). At
least for me, this project came out of the blue, completely unforeseen
and again nothing you could have possibly planned for.
My point here is (in case you haven't guessed it by now) that in a
volunteer community "planning" on the scale you are looking at is in
many ways a futile exercise. Things happen for their own reasons at
their own speed and not because you want them. And unless you want to
put in endless amounts of energy by developing all the stuff that "your
release" needs, you better find a way of dealing with that.
Which brings me to the proposal I made earlier. The main goal of that
proposal is really to get away from the upfront feature planning process
and deal with the chaotic reality of open source development by
*embracing* it. So instead of feature list of things that we SHOULD do,
I'd like us to discuss things we HAVE done. Instead of wishful thinking
I'd like us to talk about all the cool stuff that is actually happening!
I think that this may be the only way to make sure we can survive the
release process in a volunteer community like ours and it's surprisingly
similar to what we did at SqC - the main difference is that SqC (instead
of the community) picked which of the contributions got adopted and
which ones didn't. At SqC (or any other commercial entity that I have
been involved in) we have always been aware of error 33 and therefore
never relied on the open source effort to produce specific results in a
specific time frame. That's what companies do, that's why they take
money to do it. However, anything that happened was always welcome and
often a surprise. And I can say for sure that during those times nobody
got burned out by the process. And I think that process can be recreated.
Giovanni Corriga wrote:
> 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
> 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.
> 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
> 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