[Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository

[Stephan Richter]

On Thursday 24 November 2005 00:25, Philipp von Weitershausen wrote:
> Quoting Stephan Richter <srichter at cosmos.phy.tufts.edu>:
> > This would be Zope 3's death blow
> > as we know it, because it would stall Zope 3 for several months.
>
> Why would it stall Zope 3 development?

Because you would immediately loose a bunch of contributors.

> > Honestly, I rather have less exposure and keep the code base clean.
>
> The code base stays clean, I dunno how often I shall repeat it. The 'zope'
> package will continue to offer clean software in the style of Zope 3. As
> for the other packages, I didn't think it was necessary to say that we all
> want them to go away at point or another, as their functionality is being
> integrated (if not already present) in the 'zope' package.

For me, anything that adds code to the file structure is clutter. Period.

> Can you give me an example of what kind of overhead you see? I've tried to
> think hard about it and the only things I could come up with (as pointed
> out in the proposal ) are:
>
>   * running Zope 2 tests in addition to Zope 3 tests; this is a no brainer.

Sure.

>   * if a test fails, fix it. Nearly *all* tests in Zope 2 that involve Zope
> 3 technology are in Five and they are doctests. No obscure magic, no
> horrible code. And for the 1% case of a huge refactoring, there can be
> joint efforts. I hereby offer my help to you for such cases (and I've done
> so in big refactorings in the early Zope 3 days, so this isn't new).

I know there will be frequent failures. This is unavoidable. Take this 
scenario. I often work on SchoolTool. When working on SchoolTool, I am also 
working with a writable Zope 3 trunk checkout. I now find a bug in Zope 3 
(which I frequently do). I fix the bug in Zope 3, write a test, test the fix 
with SchoolTool and I am ready to check in. If I now get a failure in Zope 3 
due to Five (which I do not know and do not want to learn), I rather work 
around the bug, instead of checking in a fix, since that is less overhead. 
One contribution lost.

More cons:

* One very substantial risk is the understanding of Zope 3 newcomers. I just 
sprinted with/mentored Paul Cardune (main developer of CanDo) this week and 
he tries diligently to learn Zope 3. They are also using the Zope 3 trunk, so 
they can immediately profit from the new features and make transitions 
easier. If the trunk becomes even larger, then the chance for Paul to see 
what fits together how becomes even larger.

* We have been constantly trying to make the trunk smaller, and suddenly we 
blow it up? This does not fit. In fact, I would claim that zwiki and 
bugtracker should now be moved out of the trunk and placed into top-level 
dirs themselves. They should be tested using the buildbot.

* I have a fear that people will be motivated to make Zope 3 changes to make 
them work better with Zope 2, inserting special code just for Zope 2. That 
would be about the worst case scenario I could imagine. Right now it is much 
easier to oversee the quality of Zope 3 and monitor the checkins. Once a 
merge happens, the control will get lost. I just do not have time to read 
Zope 2 checkins.

I could come up with more, but I am too tired to think.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training