[Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository

[Chris McDonough]

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