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
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
