Re: [Zope-dev] RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the sourcecoderepository
Roger Ineichen wrote: ... And please stop telling that there will be a migration path for somthing. Please stop saying that there won't be. I guess there will never be such a path. I guess differently. Perhaps custom products can be rewriten based on Zope3 libraries, but a real migration path like known from other software will never be supported. Normaly Zope2 based projects are to highly customized and this will make it impossible for a clear migration path. Perhaps this will be different for standard use of a Plone or Silva. Butdo you really know somebody where is using Plone or Silva out of the box? I'm convinced that there will be a migration path. I don't know if it will be painless or automatic. It may take the form of Zope 2's lower-level infrastructure being replaced by Zope 3's. I think this is entirely possible and would constitute a real migration to Zope 3. It's very possible that there will be a Zope 2 in the future that supports Zope 2 paradigms and Zope 3 paradigms simultaneously. This would look very different from many pure Zope 3 applications, but perhaps no more different than a number of sucessful Zope 3 applications such as Schooltool and applications being built by Canonical. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the sourcecoderepository
Hi Philipp Roger Ineichen wrote: 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. That's not true. E.g. if you register interfaces with bad docstrings, you will break the zope.app.apidoc package functional tests or other wrong registrations will fail in broken links etc. So keeping Zope 3 packages up to speed can also be hard. What's your point? That keeping Five or Zope 2 packages using Zope 3 code up to speed is a different quality of hardness? I don't think so. I think it's not that easy and functional tests will become a hard part to maintain in the future if we mix both framework. Now, *that* you'll have to explain to me... If I do a refactoring on existing Zope3 code I proable have to support backward compatibility on other z3 packages for a clean commit where all unit test will pass. If we merge the Zope2 code into one trunk, we have to take care on this unit tests as well. Or we will see broken unit tests in the future. And if not, I have some trusty community members who can help me on a branch. That's excatly what we don't whant. We are not able to develope and ask others for fixes. This whon't work. It has worked in the past. Stephan and I used to do a lot together on geddons. Just recently Fred and I complemented each other on several things related to zpkgutils. Let's not pretend we're not teamplayers because we usually are. So future development will become pure XP programming. On Zope3 developer and one Zope2 developer for each commit ;-) Btw, what's next. Do we have to merge CMF, Plone and CPS also into the core only because other whon't be able to develop with otherwise. You know that's not what I'm proposing. I'm not even going to go into this point further. My proposal is up for discussion, nothing more, nothing less. I think you are proposing to mix two totaly different framework into one big trunk and the benefit will be in getting Products back from Zope2 developers. We are not in that state right now. We have a lot to do before we can take car on Products. I thnink we have to do several refactorings before we can do such a joint venture. Common, if somebody is not able to install Zope3, Zope2 and Five, I dont' think he will be able to help. I'm really afraid about the idea if a merge will be the part where developer bring to the Zope3 core development. I'm afraid I don't see the reason for such fear. I see a few risks, as I've laid them out in the proposals, and I see lots of opportunities. Btw, I can't here reasons like that. Every half year there is another reason what we should do for Zope2 developer so that they will contribute more. I might be mistaken, but I think this proposal is the first serious attempt, ignoring the two books out there *wink*. I think you don't speak for all of them and belive that a good skilled developer is able to get ver easy into the Zope3 development. Tres, Jens, Martijn, Martin, Morton, and Chris -- all people with strong Zope 2 background -- have given me the opposite impression. Do you really think it's easier for Zope2 developer to get into Zope3 only because the code lives in the same repsoitory. Yes. You draw the picture a little bit to easy. Perhaps. I think if somebody will become a Zope3 developer he has to learn the totly new framework first. And not only download the code. Take Chris McDonough's excellent post. He's *exactly* the kinda guy I want to address. He has TONS of experience of running actual serious sites with Zope 2 and he sees several points in Zope 3 that can be improved. Why haven't these points been at the tip of his fingers yet? Do you think he's unable to learn Zope 3? No, we really need developer like Chris. But the organization of a development trunk has nothing to do with that. Regards Roger Ineichen Not everyone had the luxury of being an early Zope 3 adopter... 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/dev%40projekt01.ch ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the sourcecoderepository
Hi Philipp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp von Weitershausen Sent: Thursday, November 24, 2005 10:33 AM To: [EMAIL PROTECTED] Cc: zope3-dev@zope.org; [EMAIL PROTECTED]; zope-dev@zope.org Subject: RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the sourcecoderepository Roger Ineichen wrote: Btw, do we really count developer where are voting but never contributed to the z3 trunk? I think normaly yes. But this is a proposal where I think should be up to the Zope3 developer to decide. Uh, why only Zope3 developers? This affects the whole Zope community! Really, I'm quite tired of trench wars like Zope 2 vs. Zope 3. Like Martijn said, we need to come together, not apart. I'm starting to get the feeling that some Zope 3 developers rather see Zope 2 die than embrace some of its experience and community. May I remember everyone again that we once said we'd do something about the transition (we even boldly called it backward compatability back then, but even I thought that this was quite too unrealistic). So far, nobody from Zope 3 has done anything in that direction, it's always been left to the Zope 2 people. Don't take me wrong, I'm not accusing, it naturally developed that way. But now that Zope 2 people want to join efforts, the Zope 3 developers close the gates under the excuse of saving their early adoption investment? that's not fair. I didn't say something in this direction. I'm only tired to hear thing like; if we do this or that, Zope2 developer will come and solve all our missing parts or fix everything. If Zope 2 developer will join the development on Zope3 there are very welcome. And if you see the past, they allways get answer from the mailinglist. I dont think one of each framework is better then the other, but they are to different for such a merge. I really like to see more real work done from Zope2 developers in this direction before we take such a project on our shoulders. (Again I don't say they do nothing, but there is to less interest or commitment which makes me belive that this is the right time to do a merge.) I whouldn't argument this way if I whould see more then 2% of Zope2 developers working on a migration path for Zope2 to Zope3. And don't tell me not merging the trunk is a show-stopper for that. And please stop telling that there will be a migration path for somthing. I guess there will never be such a path. Perhaps custom products can be rewriten based on Zope3 libraries, but a real migration path like known from other software will never be supported. Normaly Zope2 based projects are to highly customized and this will make it impossible for a clear migration path. Perhaps this will be different for standard use of a Plone or Silva. Butdo you really know somebody where is using Plone or Silva out of the box? I really think we should stop draw a vision where we will get a on cklick migration for custom projects. Then this is what people normaly expectt if we speak about a migration path. There will be a lot of work to migrate such a application. And I'm not sure if it's the best way to migrate via Five. What'a about the idea to write a new application pure based on Zope3 and then migrate the existing data in the ZODB? I guess this will be much easier for many projects then migrate via existing hooks and reflect every future refactoring over the next years. This will be another reason for not having Zope2 in the Zope3 trunk. As I know, Stephan was using such a migration on parts in SchoolTool allready. This means non exsiting package/class instances where migrated to totaly new code directly in the ZODB. Regards Roger Ineichen Again, the base idea isn't that bad at all. But since no Zope3 develper will support it, it will be a bad idea to force it. I'm a Zope 3 developer. Martijn is too. Don't jump to premature conclusions :). 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/dev%40projekt01.ch ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the sourcecoderepository
Hi there, Roger Ineichen wrote: [snip] I really think we should stop draw a vision where we will get a on cklick migration for custom projects. Then this is what people normaly expectt if we speak about a migration path. What vision is this? I don't think anybody has been proposing this vision. I'm not sure how any such visions relate to this discussion anyway. There will be a lot of work to migrate such a application. And I'm not sure if it's the best way to migrate via Five. What'a about the idea to write a new application pure based on Zope3 and then migrate the existing data in the ZODB? I guess this will be much easier for many projects then migrate via existing hooks and reflect every future refactoring over the next years. One question: Who will pay for all this work? Given lots and lots of free programmers that will do all this development, this can happen. I don't see these resources, though. :) So, we usually don't have that luxury. People have real projects in production and we want to start using Zope 3. One main route open to us maintaining existing applications is one of gradual evolution. Of course the other alternative is to forget about evolving towards Zope 3 at all and Zope 2 just going its own way, but I don't think anybody wants that, right? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
