[Framework-Team] Re: PLIP deadline overly aggressive?

Martin Aspeli optilude+lists at gmail.com
Sun Jun 21 04:32:19 UTC 2009


Joel Burton wrote:
> Hello, Framework Team!

A lot of very sensible things were said in this thread.

I have two concerns:

  1) We shouldn't let 4.0 be the excuse to let trunk languish 
indefinitely. There are important, innovative things we want to do there 
(like Deco and Tiles) that we need to be moving ahead with to stay 
competitive in the WCMS world.

  2) We shouldn't let 4.0 get so big that it pushes into Q1/Q2 2010. 
That's a real risk at this point, given the sheer number of PLIPs in the 
tracker.

So, based on that, I think the following would work (mostly as suggested 
by Hanno and others).

  - We stick to the original mantra for 4.0 of being mostly about 
packaging up things that have already been build and bringing them 
forward so people can start using them. Zope 2.12, CMF 2.2, blobs, a 
more Deliverance-friendly default theme, etc.

  - We also include a few good-but-low-risk things. Again, largely 
things that already have an implementation in the wild. The idea is that 
once the 4.0 base settles down (based on David's backporting branches), 
we can quickly merge these things in and get an alpha out.

  - We use this PLIP review cycle to start assigning PLIPs to 4.1. 
There's no reason we can't and shouldn't start planning for that now. 
So, if a PLIP looks like it'll take longer to do, we can still vote +1 
in principle, but target it for a 4.1 release that can come not too long 
after 4.0 is out.

Looking at the current list, I think it should be possible to designate 
PLIPs as 4.0 and 4.1 in this manner. The controversy will probably come 
about when delaying a PLIP to 4.1 would mean a more substantial change 
in 4.1, thus breaking the expectation of stability in point releases. In 
that case, we need to either bring it forward into 4.0, which would 
require pretty strong commitment to get it done quickly or an existing 
implementation to start from, or push it back as a 5.0 feature.

To illustrate this, here are a few examples that I think could follow 
this rule:

  #8808 - Require Python 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0

No-brainer for 4.0. Same with #7822 (blobs).

  #9249 - Add TinyMCE as the default visual editor

If we are to do this before 5.0, it needs to be in 4.0, because it's too 
radical a change to go into a 4.x release. Doing this would require some 
strong commitment to do the work and keep up with maintenance and bug 
fixes. If we have that, I'd vote +1 to 4.0. Not that my vote counts. :)

  #9214 - support logins using e-mail address instead of user id

Possible for 4.0 because there's an existing implementation in a third 
party product. If there hadn't been, I would've said this was more 
suitable 4.1.

  #9292 - Group management delegation

This would be a nice feature to have, but the PLIP author hasn't thought 
about how to implement it yet. :) This should be aimed at 4.1 IMHO.

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