[Checkins] Re: SVN: zope.session/trunk/ Move core component from zope.app.session to zope.session

[Philipp von Weitershausen]

Stephan Richter wrote:
> On Wednesday 26 September 2007 02:18, Baiju M wrote:
>> Roger Ineichen wrote:
>>>  Log message for revision 80044: Move core component from
>>>  zope.app.session to zope.session
>>>
>>>  Note: Some of the next commits will be broken because I have a
>>>  chicken and egg problem.
>>>
>>>  The zope.session uses zope.app.authentication in it's test setup.
>>>  This requires to change the zope.app.session, zope.session and
>>>  zope.app.authentication all at once which is not possible. Because
>>>  they depend in it's test setup on each other.
>>>
>>>  I'll do the next steps in the nice old trunk, it's impossible to do
>>>  it with the egg development process. So I will add eggs later after
>>>  the trunk works
>> You can develop two or more packages concurrently using buildout.
>> In zope.* package's buildout.cfg, you can see a line like this:
>>
>>   develop = .
> 
> Roger is aware of this, since we use this feature in z3c.form* development all 
> the time. However, often you do not even *know* what other packages are 
> affected, so I cannot test them together. With the trunk, you always have 
> this check.

Perhaps I'm missing something. But I don't understand at all why there 
would be a chicken and egg problem, or why you woudl have to break stuff.

If you're just refactoring stuff, you shouldn't have to break backwards 
compatibility at all. This is our new policy now, by the way. Since 
there wasn't any proposal (I don't consider the awkward "Free Views" 
proposal a sufficient proposal for this), I have to assume that this 
work won't break backwards compatibility.

Whatever it is you guys are doing, you can't break existing software

> Further, when working on zope.app.session, it does not even make sense to add 
> zope.app.authentication as a develop egg, since it is not a dependency nor 
> will be tested.
> 
> The issue Roger has here, and I agree with him, is that you do not notice 
> these type of problems until you are working on a project that requires both 
> packages. But not all development is project-driven; for example a sprint.

The splitting up seems *very* project-driven to me. You're taking a 
single package and then split it up into two. Again, I'm probably 
missing somethign, but I just don't see where this creates a problem for 
other packages. I also don't see how the single Zope3 tree would have 
been more helpful here.


-- 
http://worldcookery.com -- Professional Zope documentation and training