[Zope] Re: Presentations Available

[Rob Miller]

Nick Davis wrote:
> Hello
> Some thoughts :
> 
>>> - Upgrading to Zope 2.8 without reading the release notes.
> 
> I followed the release notes but this didn't fix catalog errors. I am 
> not the only one. This is apparently fixed in Zope 2.8.2 but that 
> doesn't look like it can be downloaded yet.

in some cases the problem will go away if you simply execute a 
'len(catalog)' command, either from a script or from zopectl debug.  YMMV.

>>> - Third party products that are not yet fully compatible
>>>   with Plone 2.1 and/or Zope 2.8.
> 
> Should this perhaps be the other way around? If those products used the 
> APIs correctly, perhaps a new release of Zope/Plone should still support 
> old APIs and/or deprecate them gradually and with warning? This is a 
> difficult problem to address but sometimes it may be better to hold back 
> on releasing something new if it causes things that depend on it to 
> break. On the other hand I can understand peoples desire to release 
> something new and cool (even if not quite ready) . ;-)
> And its hard to know quickly what the bugs are if you don't release it 
> to the real world. So hard to know what to do..........

the problem is not with the APIs... those we have taken care to 
deprecate.  the problems lie within template code (such as the problem 
you describe below), where it's much harder to maintain backward 
compatibility and still move forward.

>>> - Sites that have customized parts of Plone they shouldn't
>>>   have touched in the first place.
> 
> This is an important issue. It is difficult not to touch things that one 
> shouldn't. A trivial example - If you want your breadcrumbs to just list 
> the breadcrumbs instead of say "you are here" you have to copy across 
> global_pathbar.pt and take out "you are here". There is not another easy 
> way to do it that I can see. If you then migrate to 2.1, that .pt has 
> changed so you have to copy the new one and re-do it otherwise nothing 
> renders. If you want to add another logo on the right of the header you 
> have to hack Plone's templates further. Each change is in itself trivial 
> but they add up and when you migrate, you;re left with stuff that 
> doesn't work and spend quite a while resolving it. And thats for those 
> of us savvy enough to use the filesystem. Those who customised through 
> the ZMI will have a bigger headache.

tres responded to this more eloquently than i'd be able to...

>>> as for the broken products, that is a pandemic within the open source 
>>> community, hardly unique to plone.  
> 
> True.
> 
>>> 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. .
>>> 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 mistakes.
> 
> It would seem Archetypes has improved over time.
> 
> My real worry is when we do have a new release of Plone sitting on top 
> of Zope 3 we'll have a whole new set of bleeding edge code sitting on 
> top of other bleeding edge code, while stuff that did work with a mature 
> AT1.3.x (or 1.4.x or whatever) suddenly stops working.
> Hopefully this will prove to be an unjustified fear!

as tres said, z3 isn't really bleeding edge any more.  i'm not saying 
that there won't be migration bumps.. i expect there will be.  but there 
are a lot of folks with a lot of working code dependent on this stack, 
and we'll all be working together to get to the next level.

> Probably this is no-one's fault. It is the nature of open source. To 
> compare, have to admit I tried to get Bricolage to work a while back, 
> and ran into CPAN dependency hell.
> 
> I wonder if perhaps the real problem is trying to do so much with so few 
> resources.

this is, to me, the crux of the problem.  there are a million things 
that could be better.  i've got far more ideas for improvement than i 
have the time to give those ideas... we've all still got to get billable 
hours in.

that being said, things are getting better with time, and i expect them 
to continue to do so.

> Linux has a very mature platform as much of its base, and a lot of 
> commercial support which helps.
> Perl and the CPAN is quite mature now and also had quite a lot of 
> commercial support.
> The good thing about commercial support is people being paid to do grunt 
> work and run loads of tests and update documents.
> Both Linux and CPAN are very modular. It is relatively easy to change 
> one part without knowing about other parts.
> I think it would be easier to find someone who could patch a broken CPAN 
> module, than someone who could delve inside Zope and Plone. This is 
> because many of us don't understand the various components of the 
> underlying architecture, and a lot is changing for Zope 3. Also many 
> Perl modules are widely used by many applications, whereas a lot of Zope 
> code is only used by other Zope code.

again, tres hit this pretty well... this problem is fundamental to z2's 
monolithic, mix-in based approach.  there was no way, until z3 came 
along, to play w/ zope and still remain strongly componentized.  now 
that z3 is out, and we have five to expose z3 tech w/in z2, we're all 
eager to tear apart our monoliths into their little pieces/parts, making 
it easier for developers to be productive without having to understand 
the entire stack.

it's not perfect now, and it never will be.  but there are a lot of 
smart people involved, and things have been improving and will, IMO, 
continue to do so.

the one point that chrisw concedes to plone is that it has a rockin' 
community.  i will attest to that... and would ask folks to not 
underestimate the power of that.  i've had more fun at plone sprints 
than i can put into words, and i'm no stranger to fun, so my bar is 
pretty high.  i've also learned more about programming from this group 
of folks than any other single source of information, period.  when i 
showed up, i was a novice w/ no best practices knowledge, and probably 
wouldn't have been allowed to the table if the community was inherently 
exclusive of those w/o pre-existing development skills.  now i'm on the 
core team, and have gained a bit of respect w/in the community as 
someone whose code and ideas can be trusted.  the social fabric that the 
plone community has developed IS the key to its success, and will 
continue to be, and that's just fine w/ me.

-r