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

Thu Apr 20 16:40:03 EDT 2006

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

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

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

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

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

[1] http://www.mos.org/evolution/downloads/desilva.html

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

iD8DBQFER/Gj+gerLs4ltQ4RAu16AKDBkOGl3aoBIAVBQwUciAMwxRsUeQCfXv8u
7/D6eKGh5DO0uqJyvC5U1hU=
=tS58
-----END PGP SIGNATURE-----