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 attitude.

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 unrealistic. :)

I'd suggest:

- 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 "mergeable" state.

- 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 of slack.

My two cents - obviously this is all up to you - but cents based on experience if nothing else. ;-)

Martin

--
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
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to