[Framework-Team] Re: Release roadmap for 3.0

Martin Aspeli optilude at gmx.net
Wed May 10 22:02:43 UTC 2006


On Wed, 10 May 2006 20:37:27 +0100, Rocky Burt  
<rocky at serverzen.com> wrote:

> Hmm... I'll let the date proposals stew in my mind for a little bit...
> but just a comment on the SoC projects.  My feeling is that we shouldn't
> assume *any* SoC project should make it into plone core for 3.0.  The
> reality is that as Alec pointed out on irc today none of that stuff will
> really have any chance to get battle-tested in the wild.

I think there are a three things to think about here:

  - Sometimes we build things in Plone that were built for Plone, and as  
such doesn't really have any decent chance of existing "in the wild" for  
some unspecified amount of time before we "integrate" it.

  - Some of the SoC projects are very directly related to PLIPs that we  
want to see completed for 3.0, and that were begun in Norway. Applicants  
with the appropriate skill and/or mentorship may well be able to have  
"good" (i.e. well-tested, well-designed) code in place for 3.0.

  - The .0 releases were always meant to be more revolutionary than the .5  
releases. 3.0 *has* to be accompanied by a marketing push, and has to  
offer enough new features and fixes to old problems to entice people to  
upgrade not just because their Plone developer/consultant told it would  
would make their jobs a bit easier (which is what the .5 releases are  
about, grossly exaggerated of course). Plus, there are a few things in  
Plone as it stands now that are just embarrassing by their omission.  
History shows us time and again that without ambitious targets, and  
without giving people a shared sense of purpose that we are stretching  
towards something great, no-one actually ever solves these problems.

For these three reasons, I think it's a very bad idea to send out the  
signal that the SoC code and the many great things that were begun at the  
Archipelago Sprint stand little chance of being ready in time and if even  
if they are, they will be met with scepticism. The elusive goal of a grand  
3.0 release was the driving force in Norway, and will certainly be the  
driving force going forward. People don't spend their spare time on code  
that may or may not be used, at some time. But they put the effort in if  
they feel they have a responsibility to do so.

We need locking, seriously. We need a better portlets infrastructure. We  
need that to drive the dashboard, which we need to drive speed  
(non-cacheable portlets stay out of every bloody page and end up in a  
single, personal page). We need to AJAX-enable some of our UI to make it  
more responsive and easier to work with (and not seem so last century when  
people drool over Rails). We need link integrity, because broken links in  
a CMS are just embarrassing. We so much need to ship with workflows that  
actually make sense for the vast majority of use cases. We need to make it  
easier to collaborate on documents.

That may sound ambitious, but it is within our reach, with the right  
combination of sticks and carrots. A large part of that is showing the  
developers who are able to work on this the proper respect for their work,  
and at the same time demand the proper respect for our release schedule.  
There's a lot of pushing and teasing to be done for sure.

But in my opinion, if it's November or December instead of October that's  
necessary to make this happen, that's a pretty small price to pay for a  
release that we can market as a great step forward, not just another  
trickle.

> I'm more concerned with staying within reasonable dates with the rest of
> our stack.  It frustrates me to no end we keep lagging behind our stack
> releases so much (I know 2.5 and 3.0 will fix some of that).

I think this is absolutely true. We will certainly require Zope 2.10,  
which by that point will have been out in the wild for a while (at least 2  
months). We'll almost certainly use CMF 2.1, too.

So why not Zope 2.11? Well, frankly, we need some time to develop against  
it, as well. Developing against trunk of Zope while we're trying to push  
new features is pretty insane. If we can discover in the last two months  
that 2.11 will "just work" or be painless enough, maybe we can even move  
to that, but being 4-6 months behind Zope 2 releases isn't that big a  
deal, in my opinion, and is probably even quite ssensible.

Martin

-- 
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006




More information about the Framework-Team mailing list