[Framework-Team] Re: [plone4] Release process

[Ross Patterson]

Hanno Schlichting <hannosch at hannosch.eu>
writes:

> - Plone 4 will be primarily a feature based release, not time-based
...
> - Plone 4 will be released based on an agile approach

+1  I like this approach a lot.  I've been worrying about how to be
ambitious while still ensuring that Plone 4.0 is something more than
perpetual pie-in-the-sky.  The proposed approach seems to strike an
ideal balance.

> We need to address various major problems with Plone of which some
> will block a new release from my point of view. For example noticeably
> increased performance, unifying similar concepts (portal skins vs.
> Zope3, viewlets vs. macros vs. portlets), a better page composition
> story (no more folder_listings, display menu) and a leap in our
> technical base (Python 2.6 and WSGI).

+1 There are a lot of issues I think need urgent improvement in Plone,
but I also agree it's important to be as conservative as we can in terms
of what issues we allow to block Plone 4.  This list is pretty much
exactly what I'd restrict myself to were it left to me.

> The possibility to easily use a non-Archetypes based content type
> story is blocking a new release for me as well. Switching to a new
> default story is something I don't consider possible in the next year
> right now, but might be convinced otherwise.

+1

I think it would be a mistake to switch to a non-AT based story as
the default story before 4.5.  My reasons are largely psychological and
anthropological.  I think many in the integrator community and the
accidental-technologist-turned-developer community are dealing in part
with a sense that Plone is too much of a moving target.

OTOH, many in the developer community, such as myself are having less
fun coding with Plone because of all the history represented in the code
base.  Many in the consultant community are also having more pain from
projects that find the learning curve and rabbit holes that stem from
keeping history alongside new technology.

It seems that we have fairly widespread agreement that getting this
balance right is one of the most important things we need to fix with
Plone 4.  So I would like to see something of a slight-of-hand here.
I'd like to get us to the point where there is a new content type/schema
definition story that will make developers happy again.  I'd also like
to ensure, however, that small Plone deployments with a few custom AT
content types don't have a psychological assault when they *read* that
AT is no longer the The Way in Plone 4.  I'd prefer a carrot to a
stick.  "Your AT content types should be fairly easily portable to Plone
4!  BTW, if you want your content types to perform better, take a look
at dexterity (or whatever)!"

I think it's also important, however, that there be a *flavor* of Plone
that uses *only* the next generation of content type/schema definition
for those developers like myself that are eager to just move on.
Fortunately, this seems easily doable in a setuptools world.

Of course this raises the concern of yet again running two different
technologies side-by-side.  To mitigate this, I'd be in favor of moving
very quickly to a 4.5 that completely removes AT as a part of
Plone-the-product at the very least.

Ross