[Framework-Team] Re: proposed plone 3.1 timeframe
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
> 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