RE: [Zope] Ruling from the bench regarding 'Hotfixes' :)
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 ;) Sean -----Original Message----- From: Brian Lloyd [mailto:brian.lloyd@zope.com] Sent: Friday, August 24, 2001 12:04 PM To: marc lindahl; zope@zope.org Subject: RE: [Zope] Ruling from the bench regarding 'Hotfixes' :)
I disagree -- there needs to be a clearer distinction between products that add new functionality and those that change existing behavior.
We need some clearly defined terms for these areas. That much is obvious - already the user (product building) community has interpreted the word 'hotfix' differently than ZC has intended...
Some pithy names would go a long way towards this goal -- HotPatch - very evocative!
My argument is that that is a documentation issue. If people strongly disagree and think that new jargon needs to be invented, that's ok, but the new jargon should not be "Hotxxx" or anything that could be confused with "hotfix", for jargon-backward-compatibility reasons.
I for one would like to be able to do Product searches and have a list for Core Enhancements as separate from Added Functionality...
I don't really understand the distinction as put here. To me, a product just lets me do something that I wouldn't be able to do without it. Core Session Tracking is both a core enhancement and added functionality. I suspect you mean "products that add new objects" and "products that modify existing objects". I suspect that is not a primary criteria most people would use to look for products (though this is separate from the jargon issue - it is really a categorization issue).
From the jargon standpoint, I could see some piece of jargon that equals what we currently call "monkey patch" being useful as a shorthand amongst product developers (but it should not be a word that can be confused with hotfix).
Brian Lloyd brian@zope.com Zope Corporation www.zope.com _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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. _______________________ Ron Bickers Logic Etc, Inc.
From: "Ron Bickers" <rbickers-dated-999285577.224b86@logicetc.com>
1 - No severity (cool vs. hot)
Careful on the quoting... I didn't write that. :-)
I thought 'hot' meant, either no rebooting or no source code updating needed?
I think that's what "hot" was intended to mean; a "patch" that doesn't modify code but modifies at runtime. Still, it gives me a feeling of urgency, perhaps because of the nature in which it has been used for Hotfixes. _______________________ Ron Bickers Logic Etc, Inc.
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). Brian Lloyd brian@zope.com Zope Corporation www.zope.com
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.
From: Bill Anderson <bill@immosys.com>
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. :)
Actually, I'm wondering if there actually is a need to differentiate (via jargon) whether zope needs to be restarted or not...
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
Wait -- I thought (based on the thread) that hot vs. cold was a measure of 'severity' or 'urgency'? You seem to be saying it's 'restart' vs. 'no-restart'?
For those with a secret librarian bend <0.75 wink>, one could further categorize these into:
CorePatch (or ProductPatch) Offline/Online Enhancement/Addon/Fix
So... how do hotfixes or security alerts fit into this scheme?
PS. It occurs to me some may not care for the OCP and OPP abbreviations.
Especially since it's not clear if the 'O' is Offline or Online... Still, CorePatch/ProductPatch seems the right direction, as does the subcategories...
On Fri, 2001-08-24 at 20:58, marc lindahl wrote:
From: Bill Anderson <bill@immosys.com>
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. :)
Actually, I'm wondering if there actually is a need to differentiate (via jargon) whether zope needs to be restarted or not...
As I said, I am merely attempting to summarize what I see happening. there is a clear distinction between the method used by the 'hotfixes' and patching the source code, and restarting the server. It seems to be this distinction that has brought us here. The authors of the Online Patches felt there was a need for the distinction, and one has expressed why; hence why they chose the hotfix term. As I thought about it, I saw theneed is there, and that we should address it early. The reason for the distinction is that few other suites like Zope have the capability to do online changes the way Zope does. As a result,, we *should* express that capability, and doing so by establishing a bit of jargon to differentiate between tthese two mehtods is a subtle, yet powerful tool provided we do it eary in the game, so to speak. I have a gut feeling we will see more of these Online Patches. What better way to showcase this feature than a classification system? PHBs love to hear things can be done online. :)
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
Wait -- I thought (based on the thread) that hot vs. cold was a measure of 'severity' or 'urgency'? You seem to be saying it's 'restart' vs. 'no-restart'?
No, I am merely trying to get away from the association with 'hot'. Personally, I think hot<whatever> would apply to the non-restart issue, in much the same way that raidBoxes have "HotSwap" drives, and servers have "HotSwap" PCI cards. Someone, I believe Brian, feels "Hot" relates to urgency. He and I are only two of the people who have differeing opinions. By dropping Hot/Cold we can get away from both of these perceptions, and in so doing, sidestep that question. There is, however, a need to distinguish restart-required and no restart required. It seems that it comes from using a method that does it "online", ie. without the restart, that we find ourselves in this discussion.
For those with a secret librarian bend <0.75 wink>, one could further categorize these into:
CorePatch (or ProductPatch) Offline/Online Enhancement/Addon/Fix
So... how do hotfixes or security alerts fit into this scheme?
Well, a classical ZC HotFix would classify itself as a CorePatch Online, under the Fix category. Of course, it could be argued that Security Fix may be it' sown category.
PS. It occurs to me some may not care for the OCP and OPP abbreviations.
Especially since it's not clear if the 'O' is Offline or Online...
Yes, the thought had occured to me. It is true, however, that sometimes dropping things down to acronyms is too much 'jargon'. It is likewise true that On/Off line have been used in other places without confusion. I mention that only becuase it touches upon another feeling I get from the list, that of increased jargon. IMO, whenever we can reuse properly existing 'jargon', we should. This would help smooth out the learning curve. After all, nearly any nternet user understands the concepts of being online vs. being offline, so they could make that step easily. Even PHBs could make that one. ;^) One could also abbreviate OfflineCP or OnlinePP.
Still, CorePatch/ProductPatch seems the right direction, as does the subcategories...
Good, glad to hear I am not totally out in left field. :) The more I think about it, the more I like my latest proposal. IMO, it is not hard to wrap one's brain around it, and has a technically accurate menaing, one that is easy to recognize. CorePatchHot had a bit of an viscous feel to it, but these feel much more fluid. Now we shall see what others think. :^)= Cheers, Bill Anderson
participants (6)
-
Bill Anderson -
Brian Lloyd -
marc lindahl -
Ron Bickers -
Ron Bickers -
sean.upton@uniontrib.com