Chris Withers wrote:
Nick Davis wrote:
there seem to still be migration problems and broken products which
prevent people going to 2.1 yet.
this strikes me as a bit unfair. to quote stefan holek from a post on
plone-dev earlier today, most reported migration problems are due to:
- Upgrading to Zope 2.8 without reading the release notes.
- Third party products that are not yet fully compatible
with Plone 2.1 and/or Zope 2.8.
- Sites that have customized parts of Plone they shouldn't
have touched in the first place.
- Plone Team stupidity.
thus, while it's true that we have made mistakes (and will continue to,
no doubt), most of the problems are issues beyond our control.
as for the broken products, that is a pandemic within the open source
community, hardly unique to plone. how many zope products are out there
of dubious quality, or that are poorly maintained? whenever you get a
large community of developers, you get a mixed bag of talent and of
follow-through. the suggestion you make in your talk of having a peer
rating process for add-on products is a good one, certainly, and one
that's been discussed before, but getting there takes some effort.
My colleague has spent a long time trying to migrate a Product he
wrote, from Archetypes 1.2.5 to 1.3.4, due to the fact he had to hack
around problems with references.
Archetypes is the chief sinner in all of this, I'm afraid. It's trying
to solve a very difficult problem, and one which needs tackling with
structure and upfront and intuitive design rather than the organic
tacking on of new "bitz" whenever anyone felt like it that AT has
My fear is as more features are added, what you describe as a shaky
stack of complex fragile components will get ever more dependencies
and therefore ever more complex and fragile.
yes, AT is in many ways a mess. but, as you say, it's tackling a very
difficult problem, and, like most attempts at tackling difficult
problems, the first iterations were somewhat less than perfect. the
same can be said for zope itself... there's a reason z3 was a complete
AT's problems are entirely recognized by those of us who use it heavily,
and i can assure you that the AT developer pool has no intention of
continuing to pile more cruft on top of a shaky stack. instead, we're
looking at how we can break the framework apart into components that can
all be glued together in a nice z3 fashion. there are a great many
tools available to us now that were not available when AT was originally
developed (adapters, events, views, etc.), and we have every intention
of making use of them to improve the stack (by making it leaner and more
efficient, NOT by adding features willy-nilly!). ideally, you'll be
able to pick and choose from the various AT features, using adapters to
glue the functionality you need (and only what you need) into your own
the first iterations of this will probably also have some warts. but
please don't assume that plone/AT developers don't see the same problems
that you see, and that they aren't willing and able to learn from their
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -