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. Sessioning appears to be super-naive in Z3 (I'm not absolved of this fact, I know). Some database adapters seem like they're just promises of an actual database adapter. It's not as if these services' implementations aren't elegant or as if they're ugly or something, it's just usually that they're broken-in-the-real-world-outside- of-the-test-runner-in-some-slight-way. The first point I think can only be solved by providing a clear committment to backwards compatibility; deprecations are OK, but give folks time to fix the code before you yank out the rug, and so on. I think this commitment already exists but I can't really be sure given some of the language being tossed around here lately by Stephan. The second I think as a Z2 developer I could help Z3 out with. There are many more Z2 servers in production than there are pure Z3 servers. Lots of lessons have been learned by Zope 2 and Plone folks revolving around actual, real, honest-to-god, needs-to-run-today-and-I'm-not-joking operations and production issues. Existing Z2 developers could help bring solutions into Z3 that they've already performed for Z2 here. (Sometimes code that appears unclean is that way *because* it actually works, not in spite of it. ;-) In summary: I think it would be helpful to treat Z3 as a stable product which means trying to resist dreams of ripping it all apart again and redesigning it in fundamental backwards-incompatible ways in order to make it cleaner. It could also use some TLC from a larger developer base who has a broader range of operational requirements. Anyway, just some observations from a casual user. I'm sure I'll get toasted for something I said here because I'm sure there are inaccuracies and whatnot above this but it probably can't be helped. ;-) I've already spent more time writing this mail than I actually feel like I have to spend on the subject.
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 think "without automated tests" is the definition of shitty. Anyone who changes old Bobo-era Zope code either writes missing tests or at least begins to "own" the code to some extent. The code itself is not uniformly awful, some of it is actually quite good, but the fact that in order to go in to make a simple change, you become responsible for either writing a comprehensive suite of tests for some component or become the code's owner (or both) is what makes the situation unpleasant. Z3 is much better in this respect because the test coverage is better. The code might still be spotty, but the tests catch it. - C