Hash: SHA1


Philipp von Weitershausen wrote:
> Reading the changelog should be enough.

I partially agree on that. This obviously is one issue if you're living
on the trunk or a pre-release branch. It's not clear when to re-read, so
following the checkins is required here.

>> I try to, but I can't. And I think that normal developers
>> shouldn't have to try to.
> They read the changelog. That's why we do it, right? If no-one reads it
> and doesn't find it useful, we might just as well not do it at all.

It's definitely detailed and all the information is in there, however,
the change log for Zope 3.3 in comparison to the last 3.2 release is
approximately 410 lines mostly 2-3 liners, so about 90-100 change
entries. That's a lot of information that nobody can read and instantly
remember. I'd love to see a more weighted report for people who come
from 3.3 (see below)

>> When Philipp explained the zope.component thing in an earlier post I got
>> annoyed again because I was relying on information that obviously was
>> false.
> You were just making a wrong assumption. You THOUGHT things were like X
> but they were Y. I don't know what led you to the assumption, but it
> can't be Zope's fault if you make it :).
>> That's probably my fault because I didn't digg deep enough to
>> verify the truth whether zope.component.provideUtility works against the
>> thread local component registry or not.
> Dig deep enough? How about digging ALL THE WAY (sorry, being ironic
> here) to zope.component.interfaces and reading the declaration of
> provideUtility:
>     def provideUtility(component, provides=None, name=u''):
>         """Register a utility globally
>     ...

Again, you're right. The information is there, but I didn't *expect*
that the docstring contains any important information (for me at this
point in time and when I was looking for the correct signature of the
method). If had expected that change, I would probably have read the

> How is that not clear? If you don't read interfaces for what we provide
> them (declarative documentation), then I'm running out of ideas on how
> to satisfy you.

I read them. This is a bit of psychology turning against me here, I was
looking at the line above, but failed to read the line below because my
expectation didn't include that the docstring has any additional
information to what I was looking for.

>> When I saw that
>> zope.*app*.component does that I got scared because it's so similar and
>> maybe hard to distinguish.
> Is this a rant about our development process or about the complexity of
> zope.app.component?

It's all about process right now. I can deal with the complexity of
zope.app.component. I think. ;)

>> What I'm worried about is that we have to come up with a *MUCH* better
>> way to tell people "What is *the single* way to do this or that?" and
>> "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!".
> I'd welcome any constructive suggestions. I, for one, suggested a
> "What's new in Zope 3.X" article.  Baiju M started such an article
> (google it) and I contributed a few things here and there to it. (Thanks
> to Baiju, btw!!!)

Ah. I think I saw that on the list once as a work in progress or
proposal. I hadn't had time back than to look into this. I just found
the URL and skimmed over it. I think this is probably exactly what I
would love to see for major releases. I think I'll start translating
that to german until the final release of 3.3.

Those things deserver a lot more visibility than they get right now.
Hopefully the new zope.org website will handle that.

>> Again, maybe I'm only hitting this all the time because I'm living most
>> of my live on pre-release-branches or the trunk, but still.
>> I think if Zope 3 shall be used by many people, this is a major obstacle.
> Whether it's many or just few people... RTFMing is all it takes for them
> to get started. I've written a whole friggen book for them, for cryin'
> out loud :)

Sure, but that doesn't hold up for 3.3 and I don't carry it around with me.

Additionally RTFMing with Zope is hard because:

- - there is no TFM
- - I (and I think quite some other people too) don't even have the
expectation anymore to find something in the FM because e.g. "The Zope
book" had only two or three sentences that I came back to (via google)
for references and was always barely up to date.
- - When I don't know that something changed or is different than I think
(and it doesn't seem to behave wrong in the first place) I don't start
looking into the code.

Again, I agree that I could be much more on the hook if I

- - read all proposals
- - read all checkins
- - follow and participate in all zope3-dev discussions

So, I agree that "normal" developers might not have the same problem as
I do, because they get the benefit of having a fixed point in time where
they get the release and then just read the change log and can be happy.

Then it only imposes a problem for me and maybe other people who want to
contribute to Zope and work on and with the pre-releases and trunk. This
is a much smaller focus group, but it's also a very important one,
because we really could do with more people contributing.

And if more people would be contributing the situation might get worse
because I would miss even more stuff.

I wonder whether I'm the only one who feels like it's hard to keep up?

>> I hope I don't annoy anybody, but I had to get that off my mind.
> Sure. Grab a cool beer, cool off and start improving the situation
> tomorrow (and tell me how so I can do it in the future too) :)

I'll stick with some non-alcoholics, but I'm trying to cool down,
rationalize and provide constructive thoughts.


- --
gocept gmbh & co. kg - forsterstra├če 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to