[Zope] Re: Presentations Available

[Nick Davis]

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.

>> - 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..........

>> - 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.

>> 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!

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.
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.