[Framework-Team] Re: proposed plone 3.1 timeframe

Martin Aspeli optilude at gmx.net
Wed Nov 21 22:12:25 UTC 2007


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





More information about the Framework-Team mailing list