[Framework-Team] Re: proposed plone 3.1 timeframe

Martin Aspeli optilude at gmx.net
Thu Nov 22 08:50:41 UTC 2007

Wichert Akkerman wrote:

> So by now a number of you have complained that this schedule does not
> work very well. So I think it is time for me to mention another reason I
> have for setting a short deadline, even if that is not attainable for
> most people: at the moment almost all big development is deadline-based.
> There is very little happening when there are no deadlines looming
> in the near future. That is very problematic when planning releases: 
> we see too many changes in a short time period which puts a lot of load
> on everyone and it will very easily lead to delays. We have been seeing
> that for pretty much all releases.

I think this is endemic in how people work (and of the fact that 
everyone here is over-subscribed, spending time on add-on products and 
customer work as well as core Plone work). I don't consider it realistic 
to completely change the way people work.

> What I would like to see is more continuous development process where
> new stuff is being developed all the time and submitted for inclusion
> when it is ready. If we have a shorter release cycle that should be
> able to make things a lot smoother. The 3.0.x maintenance releases that
> we have been doing for the last couple of months prove that we can do
> time-based releases without too much hassle.

True, but bugfix releases are a very different beast. There's no review 
process, no PLIPs to be written, and the tasks are by and large much 
smaller and much better understood.

> KSS is a good example of how things should work: they are always working
> on improving KSS and have their own release schedule. The jquery work
> Martijn Pieters has done is another good example: he implemented that
> completely at his own time and pace and it's been almost ready for
> merging for a month already

I agree - we need more of this, but I still think that for the majority 
of features, having targets helps focus people. We should use the power 
of process and deadlines to our advantage, not against contributors in a 
"well, you should've thought about that before" kind of way. ;)

> Giving everyone the freedom to develop at their own schedule combined
> with making smaller by making quicker releases that guarantee that things
> will not collect dust for half a year or longer before they can be
> merged.

Of course that's the other side of the same coin. I completely agree 
that we don't want that either. Hence my preference for setting shortish 
(mid-Jan is only 1.5 months away), but realistic deadlines based on the 
calendar, what else is going on (e.g. sprints) and what work has been 
done to date.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Framework-Team mailing list