AW: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.

[Jim Fulton]

On Oct 2, 2007, at 9:24 AM, Roger Ineichen wrote:

> Hi Jim,
>
>> Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred
>> imports errors.
>
> [...]
>
>> 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
> the trunk.

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  
unchanged packages.

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  
try it.

Jim

--
Jim Fulton
Zope Corporation