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

[Philipp von Weitershausen]

Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> Tres Seaver wrote:
>>>
>>>> - Introducing new deprecation warnings in "third-dot" releases is
>>>>   probably inappropriate:
>>>
>>> When we have we done this?
> 
> 2.9.1 just did it (see below).
> 
>>>> - Deprecating an API without cleaning up *all* core uses is a *lie*;
>>>
>>> In some of the few cases where this happened was oversight and not
>>> intentional. When you deprecate something, none of the core should still
>>> use it. I think that's pretty clear.
> 
> Zope 2.9.0 shipped deprecating the OFS.content_types module without
> removing all uses (I cleaned that up back in January).

Wow, that sucks.

> Zope 2.9.1 deprecated zLOG without removing all uses:  testrunner output
> is *still* littered with deprecation warnings for zLOG. As far as I'm
> concerned, that means 'zLOG' is *not* deprecated in the 2.9.x release
> line, and may not therefore be ripped out unitl the appropriate interval
> *after* 2.10 (i.e., in 2.12, not 2.11).

Yes, I was quite annoyed by that too. In fact, I'm a bit annoyed by some
weird deprecation warnings in Zope 2 (zLOG, ZClasses, some ZCatalog
index) that still exist! I know who added all of them, I can assure you,
it wasn't me...

>>>> - 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...

>   - 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.

>   - 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.

> 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.

Philipp