On Oct 2, 2007, at 9:24 AM, Roger Ineichen wrote:
Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred
Yes, please do. It's up to people making changes to use some
judgement. I mentioned in that thread that when I make changes to
"core" components, I often do test against the old trunk tree.
Despite all of your complaints about the need to do this, you didn't.
That's not true. I did test the package against the trunk.
But the problem was, I also adjusted the imports in the packages.
hehe. This sort of practice makes any arguments for testing against
the "trunk" kind of meaningless.
What I was missing is to run the tests against a older version of
So perhaps now you want people to test against old versions of the
trunk? How many old versions?
A better approach would have been to add backward compatibility tests
for each backward-compatibility support change you made, as Lennart
suggested. Even then, to be more sure that you caught everything,
you should have made the changes in two stages:
1. Refactor the package in question providing backward compatibility
support, including tests of that support. Test against other
2. Then change the other packages is you must.
I know there is no difference between the old trunk and the new egg
development testing. This error whould also happen to me if I where
doing it in the old trunk setup. My problem was not test my work
against a older version of the trunk. Or like Lennart told,
the missing tests for integration (import changes).
The latter. The 2-step process that we've used in the past would
also have helped.
I personaly think, less test -- more errors.
So test! What's stopping you? The old tree is still available!
The crapy "do it by your self test setup" is stopping me really
hard or at least slowing me down right now more then the it should.
Maybe it should slow you down more.
It's not easy to follow all the ideas behind egg, setuptools,
easy_install, buildout in such a speed like we changed to this
patterns. I agree "Speed kills", but I think switch to eggs
force us to "take it all or nothing".
We probably do need more formalized testing/release methodologies. As
I'm sure Tres and others will rightly point out, there's probably a
lot we can learn in this area from linux distributors. In the mean
time, changing packages that lots of other people depend on requires
judgement and care. If you don't think you're up to it, then don't
Zope3-dev mailing list