[Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Reunite Zope 2 and Zope 3 in the source code repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Sounds crazy, I know. But I'm serious. Looking for your comments at: > http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository Very well thought out, very well written. +1 from me. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDhJiF+gerLs4ltQ4RAglCAJ9a+9g2jqXROPuh+fEs/sAYiGfJmgCfU+G0 Wk9G3lsZ37AIrOS0Iafw74M= =XYaJ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Philipp von Weitershausen wrote: Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository Indeed this is madness I think I like. :) This sounds like a sensible step to make after the Zope 2.9/Zope 3.2 release. +1 from me. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Nov 23, 2005, at 10:16 AM, Philipp von Weitershausen wrote: Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ ReuniteZope2AndZope3InTheSourceCodeRepository I already spoke with Philipp on IRC about this, but for the record, and speaking personally, and very arguably selfishly: -1. I think it will place too much burden on the small group of Zope 3 developers, some (many?) of whom do not develop or use Zope 2. Yes, I understand the corresponding response is that Zope 2 devs would theoretically contribute more to Zope 3. If the merge happens, I suppose we'll see if Zope 2 "pollutes" Zope 3, doesn't affect it, or helps it. Arguing about the future is a tough job. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Wednesday 23 November 2005 10:16, Philipp von Weitershausen wrote: > Sounds crazy, I know. But I'm serious. Looking for your comments at: > http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository I am -1. If I could I would veto this proposal. Here is why: To be totally honest, I really, really don't care about Zope 2! I am a Zope 3 developer. If Zope 2 code is in the Zope 3 code base, I have to relearn it again and additionally learn Five. Why? Just so I can keep developing Zope 3. This may raise the contribution bar too high for me and I would consider stopping to contribute. If the bar is too high for me, what do you expect from other people? Next, there are several third party applications that do not care about Zope 2 either, but that use the trunk to do their development with. One example is SchoolTool. Having to checkout both, Zope 3 and 2 would just be ridiculous, to say the least! (Note that several contributions of mine during the last weeks were due to my work on SchoolTool using a writeable Zope 3 trunk checkout.) The proposal only benefits Zope 2 people, really. Sure, some of the stuff in Zope 2 that should be forward-ported, but that's minimal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: On Wednesday 23 November 2005 10:16, Philipp von Weitershausen wrote: Sounds crazy, I know. But I'm serious. Looking for your comments at: http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository I am -1. If I could I would veto this proposal. Here is why: To be totally honest, I really, really don't care about Zope 2! I'll debate with you this reason. I don't think that this changes your dislike of merging the repositories and this argument is on a side-track and not intended to convince you of this. What my point is here is that your attitude about Zope 2 is wrong: as a pure-play Zope 3 developer you *should* care about Zope 2. Some of us have been doing quite a bit of work of bringing Zope 3 to the Zope 2 world. I believe that at least partially as a result of this, Zope 3 is getting a lot more attention from Zope 2 developers. I think that this attention is extremely valuable to the Zope 3 project. There is an awful lot of experience, skills and knowledge in the Zope 2 world that is immensely valuable to Zope 3 developers. We *don't* have a full respresentation of these extremely valuable perspectives in the Zope 3 development community right now. If Zope 2 developers get the impression that core Zope 3 developers don't give a shit about Zope 2, they may not be so likely to actually come on board. That would be a disastrous development indeed. We really need an increased connection between the Zope 2 world and the Zope 3 world. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Sounds crazy, I know. But I'm serious. Looking for your comments at: > http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository > I'm -1 on this as well. Some Zope3 developers don't care about Zope2 and this is fair enough in my point of view. Zope2 starts to get old and appears to be really a mess compared to Zope3 in *2005*, plus it's not such an attractive platform as it used to be couple of years ago. (Don't get me wrong on this. Time just changed. I'm using Zope2 much more than Zope3 nowadays and still I like it even if I'm *dreaming* about only using a modern platform "à la" Zope3) I would fear that some new folks might find the Zope3 project much more confusing and less attractive because of the Zope2 mess around. (common mailing list, common repository etc...) Please, let's not mess up Zope3... Cheers, 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDhMNqGhoG8MxZ/pIRArjpAJwImKaJLnGO9URfgakS6njnzWzwPwCggHnY KHhFGbndADW7GLL2UFv33Sw= =Yppy -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: This may raise the contribution bar too high. IMO that 's the most important point. I' m -1, too. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Retaining ease of customisation
Hi all, First of all, a couple of apologies: for the cross-post, but I think this concerns all these groups; for my ignorance: I'm only starting to scratch the surface of Z3, via Five, coming from Plone; and for dragging this out again. However, I think this is important.; and maybe for the length. :) As open source developers, we are dependent on an influx of new talent. That talent starts when people get interested in our products. I got a whiff of Plone for a project, played with it, loved it, learnt about it, and before I knew it, I was a core developer. If ever I have the chance to help out Z3-core, it'll be by way of this path, too, and there are many like me. However, the initial hurdle is quite steep. I really liked the Z2 way when I first learnt about it, and I love the Z3 way even more now that I'm digging into it. But Zope uses obscure technologies that no-one's heard of, no matter how good they are. Hence, anything to lower the burden of entry should be viewed as important, but it's all too easy for those of us who once climbed the hill to be excited by ever-better ways of doing things that we sometimes forget what the learning curve was like. I'm already trying to formulate how we can document to new Plone developers how to take advantage of the Z3 component architecture via Five, and explaining the mind-bend required to think in terms of adapters is actually not so simple. :) But I digress. I think for a lot of people, what drew them to Plone and then Zope-based development was to ease with which one could re-use and override elements of the application, especially the UI. Take a look at http://plone.org/documentation/how-to and see how many of the user-contributed documents are from people who say "I'm not an expert, but I figured out ..." and then go on to talk about portal_skins/custom. Ideally, we'd like to make everything people want to do available with a nice UI, but this is unrealistic. The things people write about in those how-tos are the things real users want to do, and they find low-impedance ways of achieving them with through-the-web customisation. So, when my customer wants a portlet, he discovers that he can copy-and-paste an example he saw on the web into his browser and edit a text box in the ZMI, and suddenly he has his portlet. Okay, that scares me a bit, but it's actually really important. If he had to go to the filesystem, set up a folder with some arbitrary structure, enter some boilerplate python code, remember to name files __init__.py and make a crazy configure.zcml with funny angle brackets, well, frankly, I think he wouldn't bother. More work for me, perhaps, but he could just as easily have been the next optilude, learning, tinkering, testing, exploring and finally contributing something valuable. The arugments against TTW, at least in its CMF 1.x form with portal_skins/custom or, worse still, page templates scattered through a content structure with acquisition magic, are clear. But that doesn't mean the concept isn't valuable. The thing that scares me is that as we move to use more Five/Z3 Views in Plone, those templates stop being customisable through the web. And the more obscure and complicated it becomes for a new user just to change a minor element that can't be fixed with CSS etc. or some setting in the UI, the more likely that user is to give up. I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. As Tres pointed out, this shouldn't add a performance overhead and lead to maintenance woes for those who know what they're doing. Ideally, the site admin should be able to switch this off. Or even, the view creator should have to turn it on (e.g. by using a ZCML directive that makes a template TTW customisable. Or something). I know this strays away from best practice, that people will slap in crazy python: statements in TAL etc. Having a way of dumping this stuff to "real" views would be good, even necessary. But I think ignoring these users because the approach that's most accessible to them doesn't fit with the purity of our framework will seem to them elitist, and it'll probably drive more people to ruby-on-rails, who sell themselves on how easy it is to get started. I don't know how this may work, or whether it should sit in the Z3, CMF2 or Plone 2.x layer of the stack. My hunch is CMF, but I'd like to challenge those more in the know to explain how Z3/CMF/Plone can still accomodate these users, without hurting the more seasoned developers at the same time. Thank you, Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
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 > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Retaining ease of customisation
On Wednesday 23 November 2005 16:41, Martin Aspeli wrote: > I think there needs to be a solution for making quick, preferably TTW > customisation of UI templates. As Tres pointed out, this shouldn't add a > performance overhead and lead to maintenance woes for those who know what > they're doing. Ideally, the site admin should be able to switch this off. > Or even, the view creator should have to turn it on (e.g. by using a ZCML > directive that makes a template TTW customisable. Or something). I know > this strays away from best practice, that people will slap in crazy > python: statements in TAL etc. Having a way of dumping this stuff to > "real" views would be good, even necessary. But I think ignoring these > users because the approach that's most accessible to them doesn't fit with > the purity of our framework will seem to them elitist, and it'll probably > drive more people to ruby-on-rails, who sell themselves on how easy it is > to get started. You should have a look at CPSSkins for Zope 3 (developed by the Z3ECM project). Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Workflow support
On Tuesday 15 November 2005 12:56, Alec Munro wrote: > I may have brought this up before, but what is the current status of > workflow in Zope 3? As I recall, and please correct me if I'm wrong, > there was workflow code in the 3.0 distribution, but it was removed > for 3.1? zope.app.workflow was never released as part of Zope 3. I have provided an add-on package for it though. I recently accepted a bug report that fixes zope.app.workflow for the Zope 3 trunk. So you could download that. Having said that, you should not really use zope.app.workflow. All major parties are switching to zope.wfmc, zope.app.wfmc and ecm.workflow (based on zope.wfmc). Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] sqlscript outside of Zope
On Monday 14 November 2005 04:32, Andrew Veitch wrote: > I would really like to use sqlscript outside of Zope. Is it possible > to disentangle it from zope.app? Or are there just too many > dependancies? That would require some work, but could be possible. Basically you would have to split the zope.app part of the code from the core functionality. Of course, you would also need to disentangle zope.app.rdb from zope.app. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope3 design question
On Monday 14 November 2005 00:05, rubberduckee wrote: > >You would need persistent schemas. Unfortunately persistent schemas are > > broken right now. > > > >> Users would be able to 'extend' the schemas TTW. > > > >Persistent schemas do exactely allow this. The code is in the trunk, but > > your schemas will loose changes due to a bug. The problem is known, but > > has not been tackled. > > I'd like to help out with the bug (if possible). Do you know where I > can find more information on the problem and also the details on how > one would 'tackle' it? Jim knows the details. It is very deep interface woodoo. Whenever he explains it to me I forget it immediately. ;-) So, if you are serious, please contact him and ask him for details. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Wednesday 23 November 2005 18:49, Jens Vagelpohl wrote: > People keep telling Zope2 developers that the inclusion of Zope3 > doesn't mean you have to touch it, if you don't use it it is just > inert code that won't cause any change in your Zope2 development > style. Ok, I accept that, no problem at all. But why should this be > any different for Zope3 developers, obviously including Zope2 code > would mean exactly the same thing for them. Come on now. Personally, I have never advocated inserting Zope 3 into Zope 2. Some people really wanted Zope 3 in Zope 2, so that they could use the new technology. So they added it. That's fine by me. But if they then turn around and say, "Look we have Zope 3 in Zope 2, so you should also have Zope 2 in Zope 3.", then I am complaining loudly, because I do not want to have anything to do with Zope 2. And it just means that I am becoming a Zope 2 developer again. Forget that! I'd rather fork Zope 3, then work on a version that has Zope 2 in it. It is just too much overhead for me to know all the involved technologies (Zope 2 and Five). I have barely time to keep up with Zope 3 and stay on top of it. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Contained events interface inheritance order
Today the contained events interfaces are: class IObjectMovedEvent(IObjectEvent) class IObjectAddedEvent(IObjectMovedEvent) class IObjectRemovedEvent(IObjectMovedEvent) From the archives I can find this was decided after: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the motivation... Before that proposal, the hierarchy was: class IObjectAddedEvent(IObjectEvent) class IObjectRemovedEvent(IObjectEvent) class IObjectMovedEvent(IObjectAddedEvent, IObjectRemovedEvent) I contend that this second hierarchy is much more useful to deal with. The arguments I have are in the use cases explained in: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9 where you can see the hoops one has to go through to react to objects being created, deleted or moved with the current event hierarchy. I'd like to know what non-framework use cases people have today with the current event interfaces hierarchy, and if they really find it more useful than the old one. If not, or if the use cases are borderline, I'd like to propose that the hierarchy be moved back to the second form. This would have to go through a deprecation phase, I'm not sure exactly how, but if there's consensus we can find a way. Myself I consider the current hierarchy to be a design bug. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Reunite Zope 2 and Zope 3 in the source code repository
Martijn Faassen wrote: > Stephan Richter wrote: > > On Wednesday 23 November 2005 10:16, Philipp von Weitershausen wrote: > > > >>Sounds crazy, I know. But I'm serious. Looking for your comments at: > >>http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository > > > > I am -1. If I could I would veto this proposal. Here is why: > > > > To be totally honest, I really, really don't care about Zope 2! > > I'll debate with you this reason. I don't think that this changes your > dislike of merging the repositories and this argument is on a side-track > and not intended to convince you of this. > > What my point is here is that your attitude about Zope 2 is wrong: as a > pure-play Zope 3 developer you *should* care about Zope 2. > > Some of us have been doing quite a bit of work of bringing Zope 3 to the > Zope 2 world. I believe that at least partially as a result of this, > Zope 3 is getting a lot more attention from Zope 2 developers. I think > that this attention is extremely valuable to the Zope 3 project. There > is an awful lot of experience, skills and knowledge in the Zope 2 world > that is immensely valuable to Zope 3 developers. We *don't* have a full > respresentation of these extremely valuable perspectives in the Zope 3 > development community right now. > > If Zope 2 developers get the impression that core Zope 3 developers > don't give a shit about Zope 2, they may not be so likely to actually > come on board. That would be a disastrous development indeed. We really > need an increased connection between the Zope 2 world and the Zope 3 world. I couldn't have said it better, Martijn. Stephan might not care about the Zope 2 codebase (frankly, I'm mostly with him on that, which is why I'm working to improve it), but let's not forget that Zope 3 is currently actively managed by only 10 or so people. Everytime we make a release there are heroic efforts involved, mostly by Stephan himself. How long are we supposed to continue like this? Like Martijn, I strongly believe reuniting efforts will eventually mean *more* resources for Zope 3, not less (this is also a point where I disagre with Gary). As Martin pointed out with his own example, the reunification will tremendously lower the bar for more Zope 3 contributors which, given the time and resources other projects have and are willing to spend on the framework (e.g. thanks to Goldegg), should not be ignored. To give you another, much better example: Florent recently brought Zope 3 events ot Zope 2 and made a great effort in doing so. In return, this work now made him think about improving the Zope 3 object event hiearchy, the post to the zope3-dev list was even sent today. What better example of an improvement of Zope 3 due to Zope 2 integration can there be? Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Gary Poster wrote: > > Sounds crazy, I know. But I'm serious. Looking for your comments at: > > http://dev.zope.org/Zope3/ > > ReuniteZope2AndZope3InTheSourceCodeRepository > > I already spoke with Philipp on IRC about this, but for the record, > and speaking personally, and very arguably selfishly: -1. > > I think it will place too much burden on the small group of Zope 3 > developers, some (many?) of whom do not develop or use Zope 2. You are correct and I'm not going to argue over facts. My perspective on those facts is different, though. The "small group of Zope 3 developers", as you say yourself, could really use some help, couldn't it? I think a repository reunification (along with the development process reunification which has already happened for the most part), would actually shift more resources from Zope 2 to Zope 3 than the other way around. After all, all of the major Zope projects and solution providers do not argue with the fact that Zope 3 is the future. But, like Martin Aspeli nicely said, getting there is the hard part. > Yes, I understand the corresponding response is that Zope 2 devs > would theoretically contribute more to Zope 3. If the merge happens, > I suppose we'll see if Zope 2 "pollutes" Zope 3, doesn't affect it, > or helps it. Arguing about the future is a tough job. I don't think we have to be *that* speculative here. When some of the currently Zope-2-focused developers put their +1 on this proposal, I take it they also meant this as a commitment to further contribute to Zope 2 and 3. Thus by the amount of acceptance this proposal gathers, I think we can also measure the currently unused potential of Zope contributions. At least to a degree. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
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. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Dominik Huber <[EMAIL PROTECTED]>: > Stephan Richter wrote: > > > This may raise the contribution bar too high. > > IMO that 's the most important point. It raises the bar for Zope 3 developers a bit while lower the bar for Zope 2 developers tremendously. I'm looking at the bigger picture and see it all leans towards the positive, even for Zope 3 developers (joint efforts, more resources, bla bla. I could repeat myself...) Note that I also understand your motivation on voting -1 quite well. Leaving everything as it is is simply the easier thing to do. For the moment... Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Julien Anguenot wrote: > Some Zope3 developers don't care about Zope2 and this is fair enough in > my point of view. Zope2 starts to get old and appears to be really a > mess compared to Zope3 in *2005*, plus it's not such an attractive > platform as it used to be couple of years ago. (Don't get me wrong on > this. Time just changed. I'm using Zope2 much more than Zope3 nowadays > and still I like it even if I'm *dreaming* about only using a modern > platform "à la" Zope3) I would fear that some new folks might find the > Zope3 project much more confusing and less attractive because of the > Zope2 mess around. (common mailing list, common repository etc...) > > Please, let's not mess up Zope3... Messing up Zope 3 is specifically not the intention of this proposal. It says so explicitly in the "Your questions answered" section. I think it's undebated that there will always be a "Zope 3" distribution that contains the leanest and meanest Zope 3 components (what this distribution will look like in detail is something that Jim has been thinking about for some time now, but this is not part of this discussion). You state correctly that "some Zope 3 developers don't care about Zope2". This might seem like a suitable point of view, but as Martijn pointed out very well, it's also a foolish one. It limits the acceptance of Zope 3 within the Zope community. Zope 2 is a mess, I give you that. I'm not asking any Zope 3 developer to re-embrace it, though. In fact, the idea of this proposal is not that Zope 2 is going to stay with us forever. It is about speeding up the convergence process! There are a good amount of people, Martijn and me included, who are working towards improving Zope 2 and we simply want to attract more people to help us. Zope 2's architecture might be shitty, but its community is bigger, don't forget that. The few "Zope 3 developers [that] don't care about Zope2" are the minority and I think they could use the help from the rest of the Zope community. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
While I don't agree with the +1 voters, I understand and appreciate their arguments. That said... On Nov 23, 2005, at 6:49 PM, Jens Vagelpohl wrote: People keep telling Zope2 developers that the inclusion of Zope3 doesn't mean you have to touch it, if you don't use it it is just inert code that won't cause any change in your Zope2 development style. Ok, I accept that, no problem at all. But why should this be any different for Zope3 developers, obviously including Zope2 code would mean exactly the same thing for them. Come on now. ...this is not true. Zope 2 depends on Zope 3, via Five. Zope 3 does not depend on Zope 2. Therefore, making a change in Zope 2 cannot affect functionality in the slightest, let alone break a test, in Zope 3. The same cannot be said of the reverse. Zope 2 devs don't have to touch Zope 3 unless they want to leverage some cool new feature--in which case they are Zope Five devs, probably. Zope 3 devs must touch Zope 2, in this new world order, whether they want to or not, when changes break the stuff that Zope 2 has leveraged. To grant a point to Philipp's argument, it's possible that changes that break Zope 2 are non-backwards-compatible changes in Zope 3 that should have been caught. But consider this story: a Zope 3 dev changes something and deprecates an API. As part of the dev's responsibility, the checkin also makes all code in Zope 3 use the replacement API. Now Zope 2 works, but is generating deprecation warnings whenever the deprecated API is called. Is it the Zope 3 dev's responsibility to change Zope 2 to eliminate the deprecation warnings? What about in the following release when the old Zope 3 API is eliminated--whose responsibility is it then to fix Zope 2? If you view Zope 2 as a downstream client of Zope 3, you probably give one answer; if you view the two projects as a mingled whole, you probably give another. The question here is effectively whether all Zope 3 developers must become Zope 'Five' developers. As you said, Zope 2 developers can choose to proceed essentially unaffected. Zope 3 devs could not. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Julien Anguenot wrote: >> Some Zope3 developers don't care about Zope2 and this is fair enough in >> my point of view. Zope2 starts to get old and appears to be really a >> mess compared to Zope3 in *2005*, plus it's not such an attractive >> platform as it used to be couple of years ago. (Don't get me wrong on >> this. Time just changed. I'm using Zope2 much more than Zope3 nowadays >> and still I like it even if I'm *dreaming* about only using a modern >> platform "à la" Zope3) I would fear that some new folks might find the >> Zope3 project much more confusing and less attractive because of the >> Zope2 mess around. (common mailing list, common repository etc...) >> >> Please, let's not mess up Zope3... > [...] > > You state correctly that "some Zope 3 developers don't care about Zope2". > This might seem > like a suitable point of view, but as Martijn pointed out very well, it's > also a foolish > one. It limits the acceptance of Zope 3 within the Zope community. And what about the acceptance of Zope3 *outside* the Zope community ? Zope3 will look like more complicated and confusing doing a merge. I'm more concerned about the acceptance of Zope3 outside the Zope community because Zope2 developers will have to move to Zope3 at a certain time. It's juste much more easier than for the first people. > > Zope 2 is a mess, I give you that. I'm not asking any Zope 3 developer to > re-embrace it, > though. In fact, the idea of this proposal is not that Zope 2 is going to > stay with us > forever. It is about speeding up the convergence process! I understand your motivations Philipp. I just think this is too early. When Zope2 will look like a Zope3 'configuration' then maybe it could be of interest. > There are a good amount of > people, Martijn and me included, who are working towards improving Zope 2 and > we simply > want to attract more people to help us. I still believe Zope2 developers will come on Zope3 pretty easily. The challenge is people outside the Zope community and I'm more worried about them. > Zope 2's architecture might be shitty, but its > community is bigger, don't forget that. I never said shitty. Take it easy on the interpretation. I'm using Zope2 for years and it's with what I'm working daily. I said *old* and it's different. It's not as attractive as it used to be couple of years ago. This is a fact. This is why Zope3 exists. I still believe your proposal would be a mistake at this point for Zope3. Cheers, 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDhTLOGhoG8MxZ/pIRAmSwAJ0e8d2S/lyXgeTm3dAQgqBh50eJzwCeONEC 52QuaUKLeFESP+Ytar3NkDE= =bc5x -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Wednesday 23 November 2005 22:14, Gary Poster wrote: > The question here is effectively whether all Zope 3 developers must > become Zope 'Five' developers. As you said, Zope 2 developers can > choose to proceed essentially unaffected. Zope 3 devs could not. Amen. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Wednesday 23 November 2005 21:48, Philipp von Weitershausen wrote: > It raises the bar for Zope 3 developers a bit while lower the bar for Zope > 2 developers tremendously. I'm looking at the bigger picture and see it all > leans towards the positive, even for Zope 3 developers (joint efforts, more > resources, bla bla. I could repeat myself...) I totally disagree. I, as a Zope 3 developer, have to learn Zope 2 and Five. This raises the bar too high for me! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
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 -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Wednesday 23 November 2005 21:48, Philipp von Weitershausen wrote: > Note that I also understand your motivation on voting -1 quite well. > Leaving everything as it is is simply the easier thing to do. For the > moment... I will always vote -1 on such a move. I just simply punishes all those early adopters of Zope 3 and throw it in their face. Great appreciation! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Julien Anguenot wrote: > And what about the acceptance of Zope3 *outside* the Zope community ? > Zope3 will look like more complicated and confusing doing a merge. Why? The 'zope' namespace package is what Zope 3 is known as to outsiders and this will not be affected. > I understand your motivations Philipp. I just think this is too early. Aha, it's at least good to hear that you don't condemn the idea itself. I too wondered whether it's too early or not. I think it's exactly the right time, as Zope 2 is embracing lots more Zope 3 technology. > When Zope2 will look like a Zope3 'configuration' then maybe it could be > of interest. Getting there is the hard part. This proposal is about easing that. > I still believe Zope2 developers will come on Zope3 pretty easily. I think Martin Aspeli is not the only one who still has no clue on how to move forward beyond a certain Fivization of his Zope 2 products. If you do, then that's great, but I don't think everyone is in that fortunate situation. > > Zope 2's architecture might be shitty, but its > > community is bigger, don't forget that. > > I never said shitty. Take it easy on the interpretation. Yes, yes. You know how to interpret "shitty" very well... old, worn-out, inflated, etc... Seriously, when everyone gives gigakudos to Florent and offers him 10 gallons of beer for looking through Zope 2 security code, I think at least the maintainability of some of the Zope 2 code is shitty, or at least perceived to be shitty. > I still believe your proposal would be a mistake at this point for Zope3. So it's not a matter *if* but *when*. We're already one step further. I personally take on Martijn's suggestion and vote for after 2.8/3.2 is out. Why? Because some people, including me, have some major proposals for zope3ifying Zope 2 in the top-drawer of their desk, most of which would happen in 2.10 I presume. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Wednesday 23 November 2005 22:01, Philipp von Weitershausen wrote: > Messing up Zope 3 is specifically not the intention of this proposal. It > says so explicitly in the "Your questions answered" section. Though it is not your intend, the merge would in fact mess up the trunk, specifically from a Zope 3 developer's perspective. > You state correctly that "some Zope 3 developers don't care about Zope2". > This might seem like a suitable point of view, but as Martijn pointed out > very well, it's also a foolish one. It limits the acceptance of Zope 3 > within the Zope community. How is it foolish? I have no need for Zope 2, so why should I maintain it? I only make money doing Zope 3 projects and as a hobby I only enjoy working with Zope 3 technologies. There is nothing in for me here. And this is true for any pure Zope 3 developer. > Zope 2 is a mess, I give you that. I'm not asking any Zope 3 developer to > re-embrace it, though. But I have to relearn it for the pure purpose of developing on the Zope 3 trunk. That's just not right! > In fact, the idea of this proposal is not that Zope > 2 is going to stay with us forever. It is about speeding up the convergence > process! There are a good amount of people, Martijn and me included, who > are working towards improving Zope 2 and we simply want to attract more > people to help us. Yeah, you are forcing me to help you out! > The few "Zope 3 developers [that] don't care > about Zope2" are the minority and I think they could use the help from the > rest of the Zope community. It depends on the perspective you take. If you look at the whole community, then yes, we are probably in the minority (even though that counting all people that voted so far, there are more -1 votes). A more appropriate sample would be the people actually contributing to Zope 3 on a regular basis or the ones that exclusively use Zope 3. Using this group, we have about an 80-90% -1 vote count. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: > I totally disagree. I, as a Zope 3 developer, have to learn Zope 2 and Five. What makes you think so? I, for one, have not the slightest clue of how zope.wfmc works. Still I'm able to contribute to Zope 3, am I not? If I refactor something, I might even have to touch zope.wfmc, but for the most part this could be very superficial. And if not, I have some trusty community members who can help me on a branch. It's been this way for years now, there's no compelling reason why it should change. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: > On Wednesday 23 November 2005 22:01, Philipp von Weitershausen wrote: > > Messing up Zope 3 is specifically not the intention of this proposal. It > > says so explicitly in the "Your questions answered" section. > > Though it is not your intend, the merge would in fact mess up the trunk, > specifically from a Zope 3 developer's perspective. Really, *how* does it mess up the trunk? Half of the packages of Zope 2 are also in Zope 3 because they're either ZODB or Zope3-related anyway. Another quarter of the packages will go away within one year, I think (such as DocumentTemplate, StructuredText, etc., as they are duplicate implementations of zope.documenttemplate, zope.structuredtext, etc.). > > You state correctly that "some Zope 3 developers don't care about Zope2". > > This might seem like a suitable point of view, but as Martijn pointed out > > very well, it's also a foolish one. It limits the acceptance of Zope 3 > > within the Zope community. > > How is it foolish? I have no need for Zope 2, so why should I maintain it? No one is asking you to maintain it. You're confusing maintance with bringing up to speed with refactorings. > There is nothing in for me here. That I doubt. There's a lot of code and experience in the Zope 2 community which might be underestimated... > > Zope 2 is a mess, I give you that. I'm not asking any Zope 3 developer to > > re-embrace it, though. > > But I have to relearn it for the pure purpose of developing on the Zope 3 > trunk. That's just not right! No one says you have relearn Zope 2; you merely have to run the tests. See my other post about this. > > In fact, the idea of this proposal is not that Zope > > 2 is going to stay with us forever. It is about speeding up the convergence > > process! There are a good amount of people, Martijn and me included, who > > are working towards improving Zope 2 and we simply want to attract more > > people to help us. > > Yeah, you are forcing me to help you out! So are you with zope.wfmc, zope.contentprovider, zope.viewlet and all those other things that you and others checked into Zope 3 and I have no clue about whatsoever. Sorry, this argument is moot because not too long ago the Zope 3 repository was strongly advertised as a place for people to put their Zope3-related software so that it would be kept up to speed with refactorings and such. If that offer was for non-Zope-core software, it should especially be good for Zope itself. > > The few "Zope 3 developers [that] don't care > > about Zope2" are the minority and I think they could use the help from the > > rest of the Zope community. > > It depends on the perspective you take. If you look at the whole community, > then yes, we are probably in the minority (even though that counting all > people that voted so far, there are more -1 votes). A more appropriate sample > would be the people actually contributing to Zope 3 on a regular basis or the > ones that exclusively use Zope 3. Using this group, we have about an 80-90% > -1 vote count. Sure, I realize that. Note however that I'm looking to get more Zope 3 contributors with this action. As I've pointed out before, I treat a +1 from an active Zope 2 developer as a commitment towards Zope 3 contributions. Even pure Zope 3 developers will benefit from that because it takes work off their shoulders. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
Quoting Stephan Richter <[EMAIL PROTECTED]>: > 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. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Thursday 24 November 2005 00:05, Philipp von Weitershausen wrote: > Stephan Richter wrote: > > I totally disagree. I, as a Zope 3 developer, have to learn Zope 2 and > > Five. > > What makes you think so? I, for one, have not the slightest clue of how > zope.wfmc works. Still I'm able to contribute to Zope 3, am I not? If I > refactor something, I might even have to touch zope.wfmc, but for the most > part this could be very superficial. And if not, I have some trusty > community members who can help me on a branch. > > It's been this way for years now, there's no compelling reason why it > should change. Except that I have made deep changes in the past that affect the entire architecture. And the changes were deep. If there would be a merge, don't expect me to ever make such contributions again. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: > On Wednesday 23 November 2005 21:48, Philipp von Weitershausen wrote: > > Note that I also understand your motivation on voting -1 quite well. > > Leaving everything as it is is simply the easier thing to do. For the > > moment... > > I will always vote -1 on such a move. I just simply punishes all those early > adopters of Zope 3 and throw it in their face. Great appreciation! You know I can turn this around and say that by focusing all development on Zope 3, the Zope development team left Zope 2 out there to die in its old ways of doing things, despite the fact that some sort of transition capabilities were promised for a long time (maybe I needed to remind of you of this...). A rewrite from scratch is always easy, but dealing with the transition and deprecations is the hard work which is now left up to people who were early adopters of Zope *2* and hoping for that promised transition. Great appreciation! As you can see, this angle at looking things doesn't get us anywhere and I would rather not pursue it further. What I want is a sensible transition for the future. And it's not like Zope 2 people aren't willing to put an effort in it... Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: > On Thursday 24 November 2005 00:05, Philipp von Weitershausen wrote: > > Stephan Richter wrote: > > > I totally disagree. I, as a Zope 3 developer, have to learn Zope 2 and > > > Five. > > > > What makes you think so? I, for one, have not the slightest clue of how > > zope.wfmc works. Still I'm able to contribute to Zope 3, am I not? If I > > refactor something, I might even have to touch zope.wfmc, but for the most > > part this could be very superficial. And if not, I have some trusty > > community members who can help me on a branch. > > > > It's been this way for years now, there's no compelling reason why it > > should change. > > Except that I have made deep changes in the past that affect the entire > architecture. And the changes were deep. If there would be a merge, don't > expect me to ever make such contributions again. At least no one is expecting to make such big changes by yourself. Being stubborn and refusing to do further contributions, be they large or small, isn't going to get us anywhere. The people who are so far backing up this proposal have nothing but support to offer and you know that. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
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. > > 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Philipp von Weitershausen wrote: Really, *how* does it mess up the trunk? Half of the packages of Zope 2 are also in Zope 3 because they're either ZODB or Zope3-related anyway. Another quarter of the packages will go away within one year Perhaps that would be a more suitable time to consider such a proposal. not too long ago the Zope 3 repository was strongly advertised as a place for people to put their Zope3-related software so that it would be kept up to speed with refactorings and such. If that offer was for non-Zope-core software, it should especially be good for Zope itself. I think the time has come for this to change. With a maturing code base and with systems like BuildBot we should be able to assure cross project testing (between Zope 2, Zope 3, and non-core projects). Note however that I'm looking to get more Zope 3 contributors with this action. We do need to be careful that any such transition is handled correctly or we risk flooding Z3 with people (justifiably) unfamiliar with the project while simultaneously disenfranchising existing developers. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Thursday 24 November 2005 00:57, Benji York wrote: > > not too long ago the Zope 3 repository was strongly advertised as a > > place for people to put their Zope3-related software so that it would > > be kept up to speed with refactorings and such. If that offer was for > > non-Zope-core software, it should especially be good for Zope itself. > > I think the time has come for this to change. With a maturing code base > and with systems like BuildBot we should be able to assure cross project > testing (between Zope 2, Zope 3, and non-core projects). Right, Jim's main motivation for getting buildbot set up was so that we could do cross-project testing. Zope3/ should no longer be seen as a dumping place for add-on packages, including zwiki and bugtracker. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Thursday 24 November 2005 00:41, Philipp von Weitershausen wrote: > At least no one is expecting to make such big changes by yourself. Being > stubborn and refusing to do further contributions, be they large or small, > isn't going to get us anywhere. The people who are so far backing up this > proposal have nothing but support to offer and you know that. I am as stubborn refusing this proposal as you are pushing it. Right now there are more -1 votes than +1 votes. Maybe it is time retract the proposal? Furthermore, I have yet to see contributions for Zope 3 from people using Five. We are not even getting bug reports. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] "zope.app.application.HTTPPublicationRequestFactory" interprets "text/xml" requests as XML-RPC
Andreas Jung wrote: For Zope 3.2 publishers are pluggable and can be configure through ZCML. The registration is based on the request method and mime-type. Then what is this zope.app.application.HTTPPublicationRequestFactory that John has found? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] "zope.app.application.HTTPPublicationRequestFactory" interprets "text/xml" requests as XML-RPC
--On 23. November 2005 18:39:39 + Chris Withers <[EMAIL PROTECTED]> wrote: Andreas Jung wrote: For Zope 3.2 publishers are pluggable and can be configure through ZCML. The registration is based on the request method and mime-type. Then what is this zope.app.application.HTTPPublicationRequestFactory that John has found? I can't remember. Zope 3 uses at that point a bunch of abstractions you can't keep in mind without dealing with the code every day :-) -ajh pgp8ZRPkOOvLm.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
--On 24. November 2005 07:09:00 +0100 "Morten W. Petersen" <[EMAIL PROTECTED]> wrote: We are not even getting bug reports. Likely because Zope 3 *just-works* :-) -aj pgpC8hG89OHHQ.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source coderepository
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
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On 11/23/05, Stephan Richter <[EMAIL PROTECTED]> wrote: > Using this group, we have about an 80-90% > -1 vote count. I'll weigh in with a -1 as well, for all the reasons cited by the other -1 voters on this issue. Zope 2 and Zope 3 are far too different at this point. The only way I see for convergence to be a good thing is for Zope 2 to be essentially skin and configuration on top of Zope 3; I really don't want to end up with Zope 2. Jim's vision is strongly for convergence, and I'm sure he'll say that himself when he's back (he's away for a few days). I don't pretend to know what he'll say about this idea, though. I don't *think* he think's it's time, but he doesn't like people predicting what he'll say. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: > On Thursday 24 November 2005 00:41, Philipp von Weitershausen wrote: > > At least no one is expecting to make such big changes by yourself. Being > > stubborn and refusing to do further contributions, be they large or small, > > isn't going to get us anywhere. The people who are so far backing up this > > proposal have nothing but support to offer and you know that. > > I am as stubborn refusing this proposal as you are pushing it. I'm defending my case and trying to answer everybody's concerns. I think that's something that always happens with controversial proposals and it's definitely different than your saying "I will always vote -1 on such a move." (http://article.gmane.org/gmane.comp.web.zope.devel/9819). > Right now there > are more -1 votes than +1 votes. Maybe it is time retract the proposal? It's been out there less than 24 hours. Let's not be hasty. Jim, for one, hasn't said anything yet. > Furthermore, I have yet to see contributions for Zope 3 from people using > Five. We are not even getting bug reports. Let me refresh your memory about some contributors: Julien, Martijn, Yvo, Florent, Tres, etc. are all Zope 3 contributors coming from a Zope 2 background. Regarding bugfixes, it was the Five people, most notably Yvo, who made a bugfix of the X3 3.0 release line possible. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
Benji York wrote:
> Philipp von Weitershausen wrote:
> > Really, *how* does it mess up the trunk? Half of the packages of Zope
> > 2 are also in Zope 3 because they're either ZODB or Zope3-related
> > anyway. Another quarter of the packages will go away within one year
>
> Perhaps that would be a more suitable time to consider such a proposal.
Perhaps. Or perhaps it's exactly the right time for this proposal because of
synergies.
> > not too long ago the Zope 3 repository was strongly advertised as a
> > place for people to put their Zope3-related software so that it would
> > be kept up to speed with refactorings and such. If that offer was for
> > non-Zope-core software, it should especially be good for Zope itself.
>
> I think the time has come for this to change. With a maturing code base
> and with systems like BuildBot we should be able to assure cross project
> testing (between Zope 2, Zope 3, and non-core projects).
I agree that a buildbot system does solve problem #3 of my proposal ("Zope 3
refactorings
affect Zope 2"), though only on the surface: we'd be knowing there's a problem
but the
person responsible for the refactoring can dump the responsiblity on someone
else.
> > Note however that I'm looking to get more Zope 3 contributors with
> > this action.
>
> We do need to be careful that any such transition is handled correctly
> or we risk flooding Z3 with people (justifiably) unfamiliar with the
> project while simultaneously disenfranchising existing developers.
I agree. This is why I've tried to put a lot of thought in this proposal and
I'm inviting
everyone to add your concerns as a (perhaps unanswered) question under the "Your
questions answered" section.
Philipp
This message was sent using IMP, the Internet Messaging Program.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Thu, 2005-11-24 at 04:56 +0100, Philipp von Weitershausen wrote: > I think Martin Aspeli is not the only one who still has no clue on how to > move forward > beyond a certain Fivization of his Zope 2 products. If you do, then that's > great, but I > don't think everyone is in that fortunate situation. I really, really appreciate Phil taking the time to propose this no matter what happens. But I don't have much of a dog in this fight either way. If the SVN merge happened, that'd be ok with me; if it didn't, that'd be ok too. I'd personally be more likely to contribute to Z3 if it did happen, but given the extent of my recent contributions to Z2 (minimal lately), that may not be such a win for anybody. So I'm +0 on the idea. If it did happen, I'd do my best to help solve Five test failures caused by reasonable Z3 changes. All that said, because I think it may be valuable to somebody, I'll try to provide a perspective about convergence from someone who: - Is a long-time Z2 developer. - Works with Z2 more or less exclusively. - Does more paid work than volunteer work on Z2. (e.g. it's largely just business now, not a passion). This will be pretty long. ;-) As opposed to about 8 months ago, I'm not in a position anymore where I have zero clue about Zope 3. That said, any cluefulness that I have about Zope 3 stuff has come largely as a result of using Five for customer projects. So I'm still pretty clueless about huge swathes of Z3. I'd of course like to be less clueless. I do most of my learning "on the job", so in order to really begin to use Z3 in anger, I'll need to use it for paid work. But it's unlikely that I can port *existing* Z2 customer projects over to "pure" Zope 3 if only because I really can't ethically charge someone to do that, nor do people really want to pay for it even if I could. It's great to be able to use Five to gradually use Z3 things but they'll never be "Z3-only" apps. They work just fine now under Z2 and will for a few more years at least. There's just no reason to port them. Of course it's possible that some future customer apps will be Z3 apps. That said, most of the work I get these days is in one of the following categories: - We have a slow Zope 2 application, please make it faster. - We are Zope 2 developers and we need some help on a specific piece of a project. These projects are often not good Z3 candidates for the same "don't fix it if it aint broke" reasons I mention above about existing customer projects. However, when "new" work comes in where it's simply in the form of a set of requirements rather than an already-running code base, I can of course choose to use Z3. These kinds of opportunities have presented themselves a few times in the last year or so. But I have to admit that each time one has, I've decided to stick with Z2 because not doing so would mean reimplementing (or at least porting) a lot of stuff that I know already exists for Z2 but which either has no Z3 analogue or at least has no Z3 analogue that I could personally vouch for without doing a lot of research. It's not really *major* stuff... cache managers, database adapters, transactional mail host tools, active directory connectors, heavy production sessioning requirements, blah blah blah. Any one of which could probably be researched in a day and coded up in less than another day. But it's a day and a half that I'd need to bill the customer for. Those days add up. And I like getting repeat business, so I try to keep customers happy by not taking them down ideological rabbit holes. Of course, there's a market bias here. I get more Z2 work because I've been doing Z2 work for a long time. I'm also currently much more valuable as a Z2 developer for the same reason. as As a Z3 book author, Stephan likely gets offers for work involving Z3 more than he does for work involving Z2. So it's easy to get tunnel-vision on both sides. Some observations that may be due to tunnel-vision that lead me away from developing "pure" Z3 apps: - There doesn't seem to be as much of a commitment in the Z3 community to backwards compatibility as there is for Z2. Notes like Stephan's last one where he says "I have made deep changes in the past that affect the entire architecture" as if this may happen again at any time are pretty scary. It seems to imply that Z3 is still in an alpha phase. I know *the software* isn't but if this sort of deep changes are still deemed necessary, the design appears to be, which makes it almost completely uninteresting to use for production systems. Z2, for all its other failings, makes deep commitments about backwards compatibility. This shackles it in many respects but it also makes it an attractive development platform for people who are concerned about just getting the job done and having their software work over a long period of time across major releases. - Z3 has naive or non-battle-tested implementations of ke
