[Zope] Ruling from the bench regarding 'Hotfixes' :)

[Bill Anderson]

On Fri, 2001-08-24 at 14:14, Brian Lloyd wrote:
> > > Jargon: why not "coolfix" instead?  It connotes:
> > > 	1 - No severity (cool vs. hot)
> > > 	2 - Novelty (cool==neat)
> > > 	3 - It does indeed make some changes to the core, but nothing
> > > crucial
> > > 	4 - It doesn't require you to feed it bananas ;)
> > 
> > Although saving money on bananas would be good, "fix" implies 
> > that something
> > is broken.
> 
> Right. I'd be fine with monkey patch (or anything else that doesn't
> include "hot" "fix" or is otherwise confusable with hotfix).

('we' here is used collectively, iow, what i am gleaning from the list)

Ok, we seem to be expressing a need to differentiate changes that occur
without source modificcation (and server restart/refresh), and those
that occue via source code change. Otherwise, we would just call them
patches and be done. :)
On top of this, we are expressing a desire to differentiate between Core
changes and Product changes. I agree withthese two expressions, I would
like to see organization based on a two-part tree.

In the first tree we have core changes; in the latter chnages to
products.

oringinally, I porposed CorePatchHot and CorePatchCold for
differentiating the two in this tree. Since you, Brian, have expressed a
dislike for hot (I can understsand your argument, but do not agree with
the conclusion), I now offer a slight change:

Online CorePatch
Offline CorePatch

along with:
Online ProductPatch
Offline ProductPatch.

All are technically accurate, the Online CorePatch would be one that
altered core objects/behaviour, and did not require a restart of the
server. The Offline CorePatch would be one where a patch to tha actual
sourcecode would be made, and hence a restart of the ZServer required.
In the former, the server stays online for the duration, the latter goes
offline momentarily. Clearly, the resoning is identical for
ProductPatches as well.

For those with a secret librarian bend <0.75 wink>, one could further
categorize these into:

  CorePatch (or ProductPatch)
    Offline/Online
    Enhancement/Addon/Fix

On the zope.org page, these would be a simple matter of metadata with
radio buttons for the product author to select. Likewise for browsers
(the people, not the software ;^).

An Enhancmeent would alter existing behaviour, a fix would fix something
broken, and an Addon would add somehting new, such as a new object or
new method/attribute. This naming scheme is, fairly accurate, and also
has the added beauty of symmettry. IMHO.

Heck, for the truly  anal regarding organized structures, one could even
build a heirarchy of zope components and sections to categorize the
various Core|Product Patches into, and categorize them accoridngly. ;^)=

Cheers,

Bill Anderson


PS. It occurs to me some may not care for the OCP and OPP abbreviations.
;^) It would still be reasonable, I think, to call them CorePatch
Online, and ProductPatch Online, for example, and still retain the
advantages.