Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Nov 30, 2005, at 2:18 PM, Chris Withers wrote: Gary Poster wrote: Zope 2 depends on Zope 3, via Five. Zope 3 does not depend on Zope 2. A very good point, but one which makes me feel that Zope 2 shouldn't be merged in with Zope 3 ;-) Actually, yes, all of my points were made to that end--so AFAICT you are agreeing with me, not disagreeing. :-) Gary ___ 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
Chris McDonough wrote: I really, really appreciate Phil taking the time to propose this no matter what happens. Chris, I won't bother you with a detailed answer (esp. to some points that were not quite correct about Zope 3 not caring about backward compat). I just wanted to say that I also really, really appreciate your taking time to write this post. You're exactly the kinda guy my proposal is addressing: Lots of Zope 2 experience on dead serious sites, lots of ideas on how to improve certain things in Zope 3, but no or little opportunity so far to get your hands dirty. 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
Jim Fulton wrote: 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. Hee hee. And they believed it? Do they wanna buy a bridge? ;) This is an age old argument made when someone wants to add a new feature to a development system. It is patently false. I recall a slightly different discussion I was involved in. I remember Zope 2 core developers worrying about the inclusion of Five in Zope 2.8; they were worried they'd need to maintain its codebase. The arguments against this were: * there's a lively development community around Five, don't worry * Five has a minimal impact on Zope 2; Zope 2 sources itself weren't changing. Both were true. I don't think it was claimed that your development style wouldn't be affected, as obviously we hope people will actually *use* Five in Zope 2 development. With Zope 2.9, this story is starting to change, as Zope 3 technology is making it deeper into Zope 2. Then again, I think the people who worried then have been becoming more familiar with Five since then, so hopefully appreciate it more now as a feature, not just as a potential maintenance burden. Regards, Martijn ___ 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
Chris McDonough wrote: On Nov 24, 2005, at 8:37 AM, Martijn Faassen wrote: I recall a slightly different discussion I was involved in. I remember Zope 2 core developers worrying about the inclusion of Five in Zope 2.8; they were worried they'd need to maintain its codebase. I was one of these people. Since then, I've completely changed my mind; it was a pure win. It makes me happy to hear that. Thanks! Regards, Martijn ___ 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 Nov 24, 2005, at 6:42 AM, Stephan Richter wrote: On Thursday 24 November 2005 01:39, Chris McDonough wrote: - 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. Except that I have provided full backward-compatibility. That's good! But maybe you can clarify. You said in response to Phillipp's proposal that you needed to make deep changes to Zope 3 in the past and if the Z2 repository was merged you would be unwilling to make such contributions again. The implication seems to be that being able to change the codebase without regard to its external dependents is one of your main requirements for Z3 contribution. Is that not what you meant? - C ___ 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
Paul Winkler wrote: On Thu, Nov 24, 2005 at 11:03:35PM +0800, Philipp von Weitershausen wrote: I'd love to participate in some sprints on these. Me too. PyCon Dallas 2006 is only 3 months away and would be a great opportunity for such sprints. There's nothing about Zope here yet: http://wiki.python.org/moin/PyCon2006/Sprints I plan to attend and I would really love to sprint on further fivification of zope 2. That'd be really cool. p.s. No, I can't volunteer to do any coordination work for this. I'll already have plenty to do preparing for my two (Five-related) talks. Cool to hear you're giving Five related talks. Is there any description of these available online? (not that it's likely I'll be able to attend PyCon, but I'm very curious) Regards, Martijn ___ 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, Nov 24, 2005 at 06:59:46PM +0100, Martijn Faassen wrote: Cool to hear you're giving Five related talks. Is there any description of these available online? (not that it's likely I'll be able to attend PyCon, but I'm very curious) http://wiki.python.org/moin/PyCon2006/Talks They're just basic How to develop with Zope and ...CMF talks, with as much Five as I can squeeze in since it's 2006 and it would be criminal to ignore it :-) I will not even remotely attempt to be comprehensive or deep. It will be very challenging to work in the short time slots alotted! I was a bit surprised that both talks were accepted, I figured I'd be trumped by presentations from better-known people, but maybe there weren't any! -- Paul Winkler http://www.slinkp.com ___ 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: [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: [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: [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 key services.
