On Wed, 10 May 2006 21:05:04 +0100, whit
<[EMAIL PROTECTED]> wrote:
/me dons grumpy old former FWT member hat
remember, all that SoC stuff has to have bundles and be approved by you
guys. No implementing proposals after the fact. That's about the only
standing rule for this team.
I agree entirely.
So if you are looking at this sort of
schedule, likely almost none of the SoC stuff will go in until until a
later 3.x release.
And, as I just replied to Rocky, this isn't something we can just take
lightly. It may not matter to you or me, but it matters a hell of a lot to
the guy who is debating whether to put the effort in to deliver some
killer feature. If the battle is lost before it's even begun, he won't
bother, and it'll more likely be 4.5 than 3.5 before it gets picked up
again (there's a reason why versioning is PLIP #8 and we have 157 PLIPs
spanning several years).
Also, 3.0 really should be just one louder than
2.5, regardless of the number.
I don't agree with this - and I don't think this was the intention with
the UI release/framework release split. As I recall it explained to me,
the plan was that .0 releases would be the big bang - once a year, we
release a new version of Plone with impressive new features, where we
progress and make some hard decisions about what we may need to break or
strongly deprecate to move Plone-the-product forward.
Then, we let the dust settle. We don't introduce anything that rocks the
boat too much, but we enable a .5 release to improve the framework, to
give developers better tools to build upon, to ensure consistency and
currency with the lower parts of the stack (e.g. new Zope/CMF versions).
These versions are easier to migrate to, they are about safety and
stability. And it may take until the subsequent .5 until some of the users
of the *previous* .0 are willing or able to upgrade.
I'd argue that Plone-the-product, as far as end users is concerned, hasn't
really progressed very much since Plone 2.0. We still don't have
versioning, locking, staging, taxonomy/categorisation in anything more
sophisticated than a folder, we still have a very static UI, with many
slow page reloads, we have a fairly inflexible portlets infrastructure
that makes it awkward to make the CMS personalisable. And some of the cool
things we've talked about for years that real users really love, such as
contextualised help and actions, or UI improvements to selection widgets
and folder navigation, are still unrealised.
Meanwhile, there *is* competition. The big name right now is Alfresco, and
they are *killing* us on many aspects. We still have a stronger community,
we still have a better business model, we still have a better UI (though
their's ain't that bad). The other big one is (slightly awkardly) Rails,
where all the innovation in web UI seems to be happening. If Plone is to
survive, it needs to stay ahead of the curve, to be sexy and intuitive. It
also needs to avoid having too many red crosses in the feature matrices.
So, the step from 2.1 to 2.5 was a natural evolution, to incorporate Zope
3 much more into our stack, which in turn has unleashed a lot of power
that we can use to drive the more real use cases. It was a joy to see how
much power we could get out of this discussing implementations of PLIPs in
Norway.
But 2.5 is a whisper to our end users, to the people who review Plone in
magazines and online journals. About the only innovations I can think of
off-hand are drag-and-drop folder re-ordering, placeful workflow (which I
fear most people won't need), and maybe the history tab making a
re-appearance for a poor-mans audit trail. PAS? Views? Users don't care
(developers do of course). If 3.0 is no louder than that, we'll get maybe
two or three of the Archipelago PLIPs in place, and Plone will make what I
fear is another release that goes the world quietly by, and then community
gets tired of the release frenzy, settles down to do other things, and
very little happens.
Take a look at http://plone.org/products/plone/releases/3.0
How great would it be if Plone could have even the majority of those
features? Let's not give up before we've begun.
I would argue that the proposal freeze *is* the feature freeze *is* the
last date that the framework team accepts bundles for review.
From that point of view, sure, though there is a much greater informal
period before that (which has arguably already begun) where we work out
what we would like people to work on and what to push for. The process of
even starting on a bundle isn't random, we have a pretty strong list of
features we really want Plone to have at 3.0, that have something to do
with how we want to market Plone and how we want to ensure it's not being
left in the dust by the competition.
Martin
--
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
