[Zope-dev] the Zope Framework project

[Hermann Himmelbauer]

Am Mittwoch 04 März 2009 08:16:26 schrieb Lennart Regebro:
> On Wed, Mar 4, 2009 at 07:52, Chris McDonough <chrism at plope.com> wrote:
> > Tather than reply in kind here, let me summarize:  I'm glad we agree more
> > than we disagree, and I apologize if I've attributed to you beliefs that
> > you don't have.  It's heartening to hear that you're in favor of most of
> > the things I'm also in favor of.  But we do have real differences in
> > opinion I think.  I'd rather be constructive than obstructionist here: at
> > the end of each item below I ask for an opinion based on a suggestion.
> >
> > 1)  I'm not in favor of a single steering group for the *entirety* of all
> > Zope software.   We've tried a similar thing in the past (via the
> > foundation structure); it didn't work and I'm not sure how we'd expect
> > things to turn out any differently this time.  Instead, perhaps the focus
> > of groups should be on some much smaller subset of Zope-related software
> > (e.g. the
> > zope.interface+zope.component group, the zope.schema group, the ZODB
> > group, etc).  Could we consider this?
>
> It's better certainly, but isn't this small enough in itself that
> these groups will form naturally by whoever is working on it?

But isn't that the current situation?

I think there are two scenarious when people will deal with a package in-depth 
on their own:

1) They found a bug: I made the experience that in case I find some bug and 
dig into some Zope 3 code, things tend to become very complicated and I often 
can't understand/fix it. For instance, I found some bug/misbehaviour 
regarding combination of virtual hosts and ++xyz++ URL-variables (forgot the 
name for that) and was not able to apply a clean fix due to lack of 
understanding. I could not find anyone on the list, who was responsible for 
that piece of code, so I did some hacking and never committed this (dirty) 
hack as it's certainly not up to the Zope 3 standards.

2) They want to extend a package: In order to do that, I'd first like to 
understand the package in-depth, so that my extensions don't break concepts 
and code. But it seems that there are many packages (and even core packages) 
where nobody seems to feel responsible for, or, I just don't know who it is 
and can therefore not get to the required information.

If there's no one that is motivated by (1) or (2), the package is abandoned 
(although it may even have core functionality). And my impression is that 
this has already happend for some packages, which is bad.

Therefore I think it would be a great advantage if there is some group that 
makes sure that each package has someone associated with, who has in-depth 
knowledge and maintains it. And if there is no interest in a package anymore 
and it's not used, this group may give it the status "umaintained" and kill 
it off.

Best Regards,
Hermann

-- 
hermann at qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7