On Jul 9, 2006, at 10:47 AM, Andreas Jung wrote:
 But that
just illustrates that our current approach of "everyone is responsible
for everything" or, cynically, "no one is responsible for anything"
isn't working.

Isn't that the approach how Zope is working since years?

Yes, but Zope is much bigger than it was years ago. We are maintaining 2 separate Zopes and both continue to grow.

It is a working process

I beg to differ.

1. This security problem is a case in point.

2. Our inability to get releases out on time is another.

Responsibility for a particular code part requires a solid understanding of the code.

Right. That's why responsibility for everything doesn't work.

There are a bunch of modules where I assume that only a small number of people understands the code (who understand ZClasses except you and Dieter?).

I don't know. I am certainly willing to work on them if necessary as I did for 2.8.

Responsibility for a particular code part requires dedication.

Yes it does. I think users of a feature deserve to know that someone has that dedication.

You may find a maintainer for module X or Y but I doubt that some will show dedication e.g. to ZClasses....which is a perfect example...Some month ago we had again the discussion about ZClasses and their future and one person spoke up to do something (take over the code or reimplement them).....lots of noise...nothing else... in my experience most contributors are of course dedicated in the first place to their own code but very little to some cruft code that dates back to the DC and early ZC times.

Sure. I think we should take a hard look at some of these things in light of these discussions.

So my conclusion: dedication and taking over responsibility won't solve the general problem especially when it comes to security. As a maintainer you're usually blind or have a narrowed perception on things (which might depend on the personal skills and experiences)...not everyone of the contributors is a mastermind as you...that's just the situation..so only outstanding persons can help in such a situation (e.g. through regular reviews).

I don't understand this argument. On the one hand you seem to be saying that people aren't that dedicated so we should not use a process that requires dedication. I can't except that. Maybe we need to do much less, so that we have the necessary commitment to the things we do do. Of course that won't guarantee that there won't be problems,
but, hopefully, it will:

- Increase the likelihood that basic processes will be followed, such as actually reading the documentation (much less auditing the code) of 3rd-party libraries and including tests of critical features (or missfeatures).

- Make sure we have someone (preferably more than one person) we can call on when things go wrong.

- provide a basis for evaluation of whether or not to use a feature.

If ZClasses were an add-on product with documentation of how lightly maintained it was, it would allow people to better judge the risk of using them.

On the other hand, you say that many people who are contributing are not as smart as me. That's true, just as many contributors are smarter than me. It doesn't really matter. We have some capacity for management of software and we've exceeded it. We have to figure out what we *can* maintain with the budget of brain cells we have and be brutal about only maintaining what we can.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to