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* 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. You're over-irrationalizing here. We all know that the Zope 2 code structure has flaws, but it's not like Zope 3 is perfect either. I don't think clutter is a real problem here, 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 than the fact that you keep saying you refuse to learn Five, makes fixing a Five doctest different 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 surprises me. > 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 the 'zope' 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 additional stuff... And again, it's not like Zope 3 doesn't have additional stuff right now and it hasn't 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 importantly, release scheduling-wise. To quote Steve Alexander: "You're comparing apples to an entire fruit 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 example again. He got in touch with object events through the Zope 2 integration and he's now proposing a bugfix of that in Zope 3. Sure, his objective is making it work better in Zope 2. But 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 use case 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 > 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. Maybe we don't have to combine the checkins list. zope3-checkins would catch the 'zope' package, zope-checkins everything else. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
