[Framework-Team] Re: proposed plone 3.1 timeframe
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
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