[Framework-Team] Re: proposed plone 3.1 timeframe

Wichert Akkerman wichert at wiggy.net
Wed Nov 21 22:30:56 UTC 2007

Previously Martin Aspeli wrote:
> 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 think it is much more important to do a time-based released then a
feature-based release. If we do the letter we will end up waiting months
before things are ready and we will end up with a 3.1 in june and 4.0 in

My aim is to use 3.x releases to get new features out to people
in a predictable and painfree way. If that means 3.1 is tiny and we'll
do a 3.2 4 months later I see no problem in doing so.

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

I'm aware of three things that should be ready in time. I'm sure about
two of them.

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

We decided earlier that migrations for 3.x have to be very minimal
or unneeded. So if a lot of tidy work needs to go into them we are
probably dealing with 4.x material anyway.

I don't think we can do time-based releases without this requirements.
And I consider those important for 3.x releases. Perhaps we can try
separate PLIP-approval and implementation-approval decision points to
reduce your risk.

> 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).
[.. snip ..]
>  - 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.

That would put the release at end of april / begin of may. That is 9
months after 3.0, which is a very long time for what should be a small
release. I think we can do a 3.1 and 3.2 during that period. Smaller
steps are a lot simpler to manage as well: they reduce the load on the
framework team, they reduce the risk of stability problems and they
are simpler to test.

Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

More information about the Framework-Team mailing list