> August 21, proposal freeze (review bundles must be ready)
I don't think this is too bad - perhaps push back by 2 week or so, but definitely start getting the word out now and make people start acting.
> September 25, feature freeze (all features have been merged)
This worries me more. How complete must a review bundle be? For example, I'll probably be involved in at least three bundles:
- The contentrules stuff that's Markus' SoC project - we'll definitely have the basic infrastructure and tests in place, as well as documentation. But there's more work to be done on the Plone UI and the implementation of more specific rules, that may also need the help of others.
- The plone.portlets stuff - Pete Rosales is doing this for SoC, but he's gone AWOL and we're a bit worried about it. Dorneles, Geir and I are planning (hoping) to get this into a similar kind of shape as the contentrules - basic infrastructure and tests in place, but more work around specific portlets and UI integration.
- The content menu componentisation - this is mostly done, but needs some merge work and a bit of UI strapping on.
so...having one month to complete all that seems very little. Bear in mind most people won't have several hours every day of the week, or even every week. Also, it may be easier to find help if a review bundle is in place. If these bundles are accepted, I certainly intend to get them finished!
I'd like to put the bar at "useful and achievable". That is, we should recommend a bundle if it looks like the functionality is architectually sound and meets a real use case in a good way, and if we believe it can be done in time for the release. That will probably be dependent on the author producing a plausible plan for how it will get done.
Note that bundle != merge. It may be that some bundle is rejected a bit later in the process if it becomes clear that it's stalled.
Another option I'd like to consider, is that sometimes a bundle may be reviewed and nurtured, but we may ask that it lives outside Plone. For example, in some cases we may be able to add a viewlet or an even or a hook in Plone (low-risk) to let some feature live as an add-on component that then isn't time critical for the release. Thus, we could accept a bundle that ended up only containing very small changes to Plone core (and those changes only would be subject to the rest of the roadmap dates as far as we're concerned).
October 22, first beta releas
December 18, first release candidate
January 24, expected release
So maybe what I'm suggesting is that we put a bit more of the gap inbetween bundle and merge, rather than put it before bundles are going in, and encourage people to submit bundles that contain a clear plan, not just near-finished code.
The main problem with this roadmap is that some of us had a discussion
on IRC and we felt that the dates are far too soon. Right now nobody
really thinks about Plone 3.0 or puts any time in it, we aren't really
putting any time into Plone 2.5 right now either... we cannot seriously
stop accepting features in four weeks.
Before there's an announcement and before people see a big fat deadline, they will slack (read: do other important things). We also need to not be too arrogant - people have personal lives :) If someone says, I can do this, but I need three more days, I think we should give them three more days, and work with them to get the bundles in the right format etc. It's all about lowering the barrier to contributing as much as possible.
The result of our little IRC discussion was that we wanted to shift all
those dates two month back. With the PloneConf at the end of October it
might make more sense to only push the deadlines back one month, so we
would have a feature freeze right before PloneConf which would give Limi
the option to actually talk about the new shiny features of 3.0 in his
I think he can talk about anything for which there is a review bundle. Some bundles will be further along than others (and easier to show off). Some we may have more confidence in than others. We can work with him to take a view as to what's safe to promise and what's "hopefully-ware".
If we would aim for the one-month-back option we would have another
eight weeks until proposal freeze.
Actually I'm not sure what the better option is here and think we need
some discussion before proposing anything. Which leads to the next
problem that we are only meant to propose those dates to the release
manager for Plone 3.0 who hasn't been found yet AFAIK.
http://plone.org/products/plone/roadmap suggests Wichert may have something to do with that ;-)
_______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team