Wichert Akkerman wrote:
Now that we have a new framework team it is time to start planning the
3.1 release. 3.1 is intended to be a low-risk upgrade which can follow
the 3.0 release quickly. The release cycle has to be short so we can
get things out to people. Here is my proposal:
- all proposed updates for have to be submitted by christmas
- framework team finishes reviewing by january 9
- accepted changes are merged in the days after that
- first pre-release for 3.1 happens on january 15
- final release for 3.1 happens first half of february
In order to make reviewing simple all updates have to be submitted in
the form of a working buildout. And to keep the 3.1 process smooth they
have to include all migrations, finished user interfaces and
documentation. We will not do any polishing after merging - that has to
be done beforehand.
Judging by the current activity I expect there to be only 2 or 3
proposals in a mergeable state. That is not much, so you should be able
to enjoy some christmas vacation as well :)
I think you should set a threshold here. Doing a release for only 2 or 3
proposals may just be too much work for everyone to be worth it. That
is, unless we aim for a quick 3.2 as well (in which case I suggest this
team stays on for that release as well to keep the overhead of finding a
new team down).
I also think you need to give people a bit more warning. No-one works
without a deadline. I'm not aware of any serious 3.1 branches at the
moment, apart from a few sprint leftovers. If you spring a deadline on
the community that's only a few weeks away, people won't take it
seriously (or just won't react at all).
Personally, for 3.1 I'd like to:
- Add GS better handlers for portlets and content rules
- Improve portlets blocking UI
- Ship with collection portlet
- Ship with plain-text/kupu portlet
- See the UberSelectionWidget finished
- Support inline/KSS editing for formlib-based content
- Support inline/KSS validation of formlib forms
Now, most of the above are begun, but none is in a mergable state right
now. I'm not going to wreck myself over Christmas to get it done, when
I'll be with my family. I suspect I'm not the only one that has that
Secondly, if you expect working buildouts, with full migrations for the
review deadline, I think you're asking a lot. There's a lot of "tidy"
work to go into migrations and final polish, especially when it comes to
keeping up with other movements on the 3.0 branch. I won't spend that
time upfront on all the proposals above because (a) I don't have time
and (b) you may say no to my PLIPs, in which case all that work's wasted
(migrations are unlikely to stay current even if they're pushed for 4.0).
That's a roundabout way of saying I think these deadlines are
- Demanding PLIPs (text only) in two-three weeks - this focuses people
and allows you to give direction on how useful or appropriate a feature is.
- Giving people till mid-January (in effect, respecting the Christmas
as a holiday, not Ploniday) to get review buildouts in shape.
- Reviewing buildouts based on functionality with fresh sites (so no
testing of migration), and giving some leeway on UI and other polish.
- Doing your reviews very quickly (this was a problem last time around
- it took several weeks to get through all the bundles).
- Giving feedback to authors on what they need to do to reach
- Setting a second deadline about a month after your voting completes,
when approved buildouts have to be mergeable. This should include
reacting to feedback you give (e.g. suggested/required improvements).
Note that I *absolute* support the notion that nothing should be merged
if it's not almost 100% complete, including migrations, tests and UI.
- Doing a 3.1 alpha two weeks after that, to allow the merge to settle
down, and then go through a quick beta phase before reaching rc, again
for about a month.
I know talking in months rather than weeks sounds dreadfully long, but
I'm pretty sure we're either going to have a release with virtually
nothing in it, or end up shifting the deadlines anyway, if we don't give
ample time up front. Plone can be a slow ship to turn sometimes, and
co-ordination across everyone who needs to be involved introduces a lot
My two cents - obviously this is all up to you - but cents based on
experience if nothing else. ;-)
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Framework-Team mailing list