Hi Philipp
[...]
Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeR epository
Yes, you are right this sounds crazy.
Reading the response to this mail, I guess developer working on existing Zope2 projects agree on this proposal.
And developer where build projects only based on Zope3 will not.
As somebody how don't know Zope2 I'm -1 on this.
Regards Roger Ineichen
Philipp
Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
Roger Ineichen wrote:
Reading the response to this mail, I guess developer working on existing Zope2 projects agree on this proposal.
And developer where build projects only based on Zope3 will not.
As somebody how don't know Zope2 I'm -1 on this.
I could repeat here what Martijn and I wrote in response to Stephan...
I know that you, Roger, have been contributing a lot to new exciting features in Zope 3. In doing so, you would never have to worry about Zope 2 because Zope 2 will only explicitly use certain Zope 3 features. I believe you would in fact benefit from the Zope 2 combination because the features you write would get much better exposure to a large install and development base that is *hungry* for Zope 3 technology. Also, you could combine efforts with people who, until now, have been implementing framework-level stuff in their own projects.
Bottom line: I find the risk of your having to dig through horrible Zope 2 code much lower than the chance of joint efforts on Zope 3 technology. Of course, it'd be quite surprising if I didn't believe that as the author of the proposal *wink*.
Philipp
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wednesday 23 November 2005 21:43, Philipp von Weitershausen wrote:
I know that you, Roger, have been contributing a lot to new exciting features in Zope 3. In doing so, you would never have to worry about Zope 2 because Zope 2 will only explicitly use certain Zope 3 features. I believe you would in fact benefit from the Zope 2 combination because the features you write would get much better exposure to a large install and development base that is *hungry* for Zope 3 technology. Also, you could combine efforts with people who, until now, have been implementing framework-level stuff in their own projects.
So you think it is better to loose the existing Zope 3 developers in anticipation of more community involvement? This would be Zope 3's death blow as we know it, because it would stall Zope 3 for several months. Honestly, I rather have less exposure and keep the code base clean.
Bottom line: I find the risk of your having to dig through horrible Zope 2 code much lower than the chance of joint efforts on Zope 3 technology. Of course, it'd be quite surprising if I didn't believe that as the author of the proposal *wink*.
You are kidding, right? You know April 1st is not for another 4 months. In all honesty, I think you are downplaying the new overhead of Zope 3 developers too much.
Regards, Stephan
Quoting Stephan Richter srichter@cosmos.phy.tufts.edu:
On Wednesday 23 November 2005 21:43, Philipp von Weitershausen wrote:
I know that you, Roger, have been contributing a lot to new exciting features in Zope 3. In doing so, you would never have to worry about Zope 2 because Zope 2 will only explicitly use certain Zope 3 features. I believe you would in fact benefit from the Zope 2 combination because the features you write would get much better exposure to a large install and development base that is *hungry* for Zope 3 technology. Also, you could combine efforts with people who, until now, have been implementing framework-level stuff in their own projects.
So you think it is better to loose the existing Zope 3 developers in anticipation of more community involvement?
I think you're exaggerating here. No one would give up Zope 3 because the repository has a few extra packages laying around.
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?
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.
Bottom line: I find the risk of your having to dig through horrible Zope 2 code much lower than the chance of joint efforts on Zope 3 technology. Of course, it'd be quite surprising if I didn't believe that as the author of the proposal *wink*.
You are kidding, right? You know April 1st is not for another 4 months. In all honesty, I think you are downplaying the new overhead of Zope 3 developers too much.
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.
* 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).
Philipp
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Thursday 24 November 2005 00:25, Philipp von Weitershausen wrote:
Quoting Stephan Richter srichter@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 wrote:
On Thursday 24 November 2005 00:25, Philipp von Weitershausen wrote:
Quoting Stephan Richter srichter@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.
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.
On Thursday 24 November 2005 01:18, Philipp von Weitershausen wrote:
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.
Because they will not bother contributing, if the prospect is that they have to fix Five things; something they have nothing to do with.
Regards, Stephan
On Thursday 24 November 2005 01:18, Philipp von Weitershausen wrote:
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.
It is opinion against opinion. This is a deadlock. I Am not going to reply anymore, because (a) it is Thanks Giving and I am going out of town and (b) I am just repeating myself anyways.
Regards, Stephan
On Thursday 24 November 2005 01:18, Philipp von Weitershausen wrote:
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.
Yes. Because I worked very hard the last 3.5 years to have a very deep and fairly complete understanding of Zope 3. This is the reason I can fix doctests and bugs in almost every part of Zope 3. I do not want to spend time acquiring this skill in Five or Zope 2 (again). I have no motivation to do that.
I have been a Zope 3 developer for over 3 years and I have worked very hard trying to make (some) money with Zope 3 when it was not easy to do so. Now that I have finally plenty of Zope 3 work, you come around and force me to learn Five and Zope 2 again, if I want to continue developing for Zope 3. And that's plain bullshit. The strong resistance of some of the other pure Zope 3 developers should give you a hint.
Regards, Stephan
I think this change can possibly make sense when we have replaced Zope 2 authentication with Zope 3s, and when we have replaces Zope 2 publisher with Zope 3s and when we have replaced the Zope 2 traversal with Zope3s, and maybe a couple of other things.
At that point, Zope2 will more or less be Zope3 + App, DateTime, OFS, Products and some other stuff. Then something more of a merge might make sense.
Up until then, we have a functioning system now, and I'm guessing the benefits will not outweigh the work.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Lennart Regebro wrote:
I think this change can possibly make sense when we have replaced Zope 2 authentication with Zope 3s, and when we have replaces Zope 2 publisher with Zope 3s and when we have replaced the Zope 2 traversal with Zope3s, and maybe a couple of other things.
Exactly. In this case Zope2 will be a more a 'configuration' of Zope3. Well, I'm repeating my self here ...
At that point, Zope2 will more or less be Zope3 + App, DateTime, OFS, Products and some other stuff. Then something more of a merge might make sense.
yup. This is my impression. This is too early...
Up until then, we have a functioning system now, and I'm guessing the benefits will not outweigh the work.
I can only agree with this on this.
J.
- -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
Lennart Regebro wrote:
I think this change can possibly make sense when we have replaced Zope 2 authentication with Zope 3s, and when we have replaces Zope 2 publisher with Zope 3s and when we have replaced the Zope 2 traversal with Zope3s, and maybe a couple of other things.
At that point, Zope2 will more or less be Zope3 + App, DateTime, OFS, Products and some other stuff. Then something more of a merge might make sense.
This is a really really good point ;-) I think unification is probably a good idea, but not yet...
Even so, I'd much prefer to see Z3 stay "light" of Zope 2 and just have Zope 2 become smaller and smaller as it leverages more and more of Zope 3.
Put differently, I have no problem with the repositories merging, but I'd like to see the bits of Zope 3 seperately available, without Z2. I know ZPT and testbrowser already work like that, and the more that works like that the better...
Chris
Stephan Richter wrote:
- 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.
This is a very very good point...
- 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.
Another good point.
cheers,
Chris
Stephan Richter wrote: [snip]
So you think it is better to loose the existing Zope 3 developers in anticipation of more community involvement? This would be Zope 3's death blow as we know it, because it would stall Zope 3 for several months. Honestly, I rather have less exposure and keep the code base clean.
I don't think that threats to leave and portrayals of utter doom are a fair way to discuss this, Stephan. I must say I find it extremely ironic to hear from you that stalling Zope 3 for several months is a death blow to Zope 3 -- where was this sentiment in the past? :)
Like it or not, merging the repository or not, you'd better get used to the fact that Zope 2 developers are here in your community and that they will speak up to let their interests be known. It's in your interest to make us happy, actually, as we're working to make Zope 3 a better community and a better system.
Regards,
Martijn
On Thursday 24 November 2005 05:36, Martijn Faassen wrote:
I don't think that threats to leave and portrayals of utter doom are a fair way to discuss this, Stephan. I must say I find it extremely ironic to hear from you that stalling Zope 3 for several months is a death blow to Zope 3 -- where was this sentiment in the past? :)
Note that I don't claim that my leaving would stall the development. I just use my case as an example. I always consider myself of someone, who accepts a very high bar for contributing. So, if I think the the bar is too high, my thinking goes, then others will also conceive it as too high and that causes the stalling.
Everyone is replaceable, I have learned that in the US. But a certain group might not as easily be.
Like it or not, merging the repository or not, you'd better get used to the fact that Zope 2 developers are here in your community and that they will speak up to let their interests be known. It's in your interest to make us happy, actually, as we're working to make Zope 3 a better community and a better system.
I know that The Zope 2 people are around. And I try to answer Five questions on the lsits and on IRC as good as I can. I also have nothing against hearing the interest of the Zope 2 community. But I am also in a position where I must protect the interests of the Zope-3-only community as well. And in *my* opinion, in this particular case the Zope 2 community has a lot to gain at the expense of the Zope-3-only community. I have outlined my arguments for that statement in the many E-mails before.
Regards, Stephan
Philipp von Weitershausen wrote:
Bottom line: I find the risk of your having to dig through horrible Zope 2 code much lower than the chance of joint efforts on Zope 3 technology. Of course, it'd be quite surprising if I didn't believe that as the author of the proposal *wink*.
I agree with the points your raise but I worry about the arrival of the pragmatists and making nasty botch jobs to help out some half broken code in Zope or Plone...
cheers,
Chris
-
Chris Withers -
Julien Anguenot -
Lennart Regebro -
Martijn Faassen -
Philipp von Weitershausen -
Roger Ineichen -
Stephan Richter