Stephan Richter wrote:
> On Thursday 24 November 2005 00:25, Philipp von Weitershausen wrote:
> > Quoting Stephan Richter <[EMAIL PROTECTED]>:
> > > 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.
You still haven't given me a good reason why we would actually *lose*
> > > 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.
You're over-irrationalizing here. We all know that the Zope 2 code structure
but it's not like Zope 3 is perfect either. I don't think clutter is a real
so let's not make it one.
> > * 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.
Can you read and potentially fix doctests? I *know* you can :). Tell me, other
fact that you keep saying you refuse to learn Five, makes fixing a Five doctest
from a, say, zope.app.tree doctest? It's not like you've modified a line here
or there in
other people's code before which is why your particular dislike of Five
> 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.
I'm sure that Zope 3 newcomers can live with the fact to only use stuff from
package. We've always said a repository checkout looks different and contains
more than a
distribution. If you use it, newcomer or not, don't complain about the
And again, it's not like Zope 3 doesn't have additional stuff right now and it
stopped Paul, has it.
> * 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.
You'd be surprised, I agree. Zope 2 is different from zwiki and bugtracker,
though. Zope 2
is tightly linked to Zope 3 now, technology-wise and, much much more
scheduling-wise. To quote Steve Alexander: "You're comparing apples to an
salad served with cream." :)
> * 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.
At least I expect code to be refactored to ease its reuse in Zope 2. This is
one of the
explicit goals mentioned in this proposal. I can take Florent's case as an
He got in touch with object events through the Zope 2 integration and he's now
bugfix of that in Zope 3. Sure, his objective is making it work better in Zope
seldomly a change like that would count as "special code just for Zope 2".
Also, good use cases have never prevented us from checking in any code. If that
happens to occur in Zope 2 and *not* in Zope 3, so be it. It's still a use
case, and it's
not like it wouldn't find its way into Zope 3 in the long run; my point is to
make it easy
to do so.
> That would be about the worst case scenario I could imagine. Right now it is
> 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.
Maybe we don't have to combine the checkins list. zope3-checkins would catch
package, zope-checkins everything else.
This message was sent using IMP, the Internet Messaging Program.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -