[Zope3-dev] Re: RFC: The browser:page compromise

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:

> Tres Seaver wrote:
> 
>>>>>- Deprectaion of an older, stable alternative, *no matter how grotty,*
>>>>>  should go hand in hand with *lots* of confidence that the new favored
>>>>>  alternative really is superior, and by enough margin to make the
>>>>>  switch worthwhile.  In my mind, this means that the new
>>>>>  implementation needs to be rolled out *in production* and tested in
>>>>>  the wild *before* we can deprecate the older alternative.
>>>>
>>>>I think that's a big burden for refactorings. Under such a rule, Jim
>>>>wouldn't be allowed to roll out neither his adapter registry
>>>>improvements nor his Component Architecture simplification.
>>
>>Refactorings *need* a bigger burden than we have recently been imposing:
>>
>>  - Doing a refactoring right means adding BBB code, which itself
>>    increases the maintenance burden for core developers.
>>
>>  - As an example, the twisted server became the *default* in Zope 3.2
>>    in spite of the fact that it broke ZEO because the developer who
>>    landed the change doesn't use ZEO, and hence missed seeing the
>>    damage.
> 
> I guess we didn't have enough tests. Now we have a test that exercises
> ZEO. Plus, we dealt with this problem before any final release (perhaps
> even before the beta?). That's what alpha and beta phases are for...

My point here is that the 'refactor mercilessly" meme has left people
feeling free to make chnages of debatable value (Twisted is *still* not
accepted in the Zope community as a superiour choice for publishing
HTTP), without full weight being given to the needs of folks who aren't
up to their elbows in the code every day.

>>  - The packaging changes introduced in the 2.9 release cycle broke
>>    usecases which many developers care about ('make inplace' is broken,
>>    instance home testing broke, etc.)  Worse, and ironically, the
>>    breakage was incurred on behalf of 'zpkg', which is itself slated
>>    (now) to be deprecated.
> 
> Forgive me if I'm a little rough on this subject, but here it goes:
> 
> I've had it with this whining about make inplace etc. It's been nearly
> half a year since 2.9 is out and nobody has even made the attempt to fix
> this so I guess nobody really needed it. Yet there's still whining. Yes,
> I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
> process strongly suggested it. If there were alternatives to zpkg,
> nobody has suggested them and nobody seems to have explored them so far.
> All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
> they got.

Zope 3 is a *library* for Zope 2 -- I don't see any necessary reason to
have Zope 3's packaging model drive Zope 2's.  What I recall about this
discussion was the following:

  - There was distaste in the Zope 3 world for the carefully
    hand-maintained code which made Zope 2's 'configure && make && make
    install/inplace' dance work

  - Jim proposed ripping it out in Zope 3 in favor of the "generate
    everything via zpkg' dance.

  - In order to "move toward the Zope 3 way", you proposed doing the
    same for Zope 2.9.

  - Immediately after you landed the change, folks began to point out
    issues with it

    o in-place builds were broken (the 'bin' directory was not created)

    o out-of-tree builds broken  (e.g.:

     $ sudo mkdir /opt/zope29
     $ sudo chown tseaver:root /opt/zope29
     $ cd /opt/zope29
     $ /path/to/zope29/checkout/configure && make && make inplace

    o 'make instance' and 'mkzopeinstance' producing borked instances,
      (since fixed for 2.9, but still broken in Zope 3)

  - We stayed the course, and *today* are still stuck with a 2.9 branch
    which *cannot be used* as the 2.8 branch was in a checkout.  The
    problem appears to be intractable, as the changes needed to make
    'zpkg' work completely invalidated all our former experience and
    knowledge of how to use a checkout tree.

    Effectively, the only folks who can maintain the 'zpkg'-centric
    build don't care about these usecases, and so we are stuck.

  - Not only that, but we did it to support 'zpkg', which has proved to
    be a failed experiment, even for packaging Zope 3.  For instance,
    at this point, a Zope 3.2 checkout tree can be uesd to do only:

    o Run the unit tests.

    o Generate a "release distribution".

    It cannot be used as the basis for running developer sandboxes, at
    least not without major hacking of the generated instances.  Here is
    a sample:

     $ svn co $ZSVN/Zope3/branches/3.2 Zope-3_2-branch
     ...
     $ cd Zope-3_2-branch
     $ /path/to/python setup.py build_ext -i
     ...
     $ /path/to/python utiltiies/mkzopeinstance.py -d /tmp/z32
     ...
     $ cd /tmp/z32
     $ bin/zopectl fg
     ...
         ConfigurationError: ('Unknown directive',\
           u'http://namespaces.zope.org/zope', u'role')

    I don't think this is a useful place for us to be in Zope 3, and I
    *don't* want to emulate Zope 3 in this direction in Zope 2.  I would
    in fact be in favor of a return to the setup.py used in Zope 2.8,
    as a precursor to a Zope 2.x release built around eggs, rather than
    zpkg.

>>  - Jim's current changes will most likely land for 2.10.  If we don't
>>    spend enough time in the beta cycle with them, we may be seeing
>>    similar effects, or may need to be prepared to "un-deprecate" some
>>    of the stuff currently on the doomed list.
>>
>>
>>>>We're not "refactoring mercilessly." We're thinking about problems,
>>>>writing proposals, measuring risks, providing BBB and writing tests.
>>>>We'll have to trust our tests to a certain degree. If we don't then
>>>>perhaps we need more tests. We surely could use more functional tests.
>>>>
>>>>I'll be fine with creating new directives instead of changing the old
>>>>ones, if that's what the majority prefers. But then I'd very much like
>>>>to see a Death Certificate for the old directives made out for some time
>>>>in the future (doesn't have to be 2 releases, could be more).
>>
>>I don't think we are going to come to consensus about the appropirate
>>"standard set" of directives anytime soon:  the current state of the
>>debate reminds me eerily of the "lumbers" vs "splitters" rift in the
>>world of paleoanthropology[1], which has been unresolved for more than a
>>generation now.
> 
> 
> I'm not sure if this is a matter of what the "standard set" is or not.
> <browser:page /> is a big pile of magic. See one of my replies to Rocky
> Burt and the interpreter example. It makes code really really hard to debug.
> 
> I also think it makes it hard to understand. In response to this
> proposal, several people have asked me "By the way, what's the
> difference between <browser:page /> and <browser:view /> anyhoo?" That
> alone has proven my point that the current system makes it absolutely
> incomprehensible of what's going on behind the scenes.

Documenting ths *semantics* of the current implementation isn't that
tough;  explaining the *implementation*, on the other hand, is plenty
hard.  I'm all in favor of simplifying the implementation, as long as we
don't induce gratuitous breakage on the developers and admins who
followed our lead and installed Zope3 (or Zope2 and Five) already.

>>I stand by my claim that the "reductionist" strain in our current debate
>>is backed by developers who *also* admin the systems they have deployed,
>>and that this sample is not representative of the audience to whome Zope
>>is pitched.
> 
> 
> Many of my recent proposals were driven by my book because it goes
> through great difficulties explaining certain Zope 3 behaviour (or
> magic). So if I have anyone in mind besides myself for the audience of
> such "reductions", it is probably the reader of my book.

I'm proposing that introducing gratuitous changes in the semantics you
have already documented is not going to benefit the readers who already
bought the book.  Let's make sure we have a better place to jump to
*before* we jump.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
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

iD8DBQFESD0Q+gerLs4ltQ4RAv+wAKCNSdC1XLLJWgdwlAFyYUM0VLClIACgi7eZ
HFNHvhq6/A75dfTFOUvhkCQ=
=Zhpz
-----END PGP SIGNATURE-----