To (monkey)patch or not to (monkey)patch, that is the question

[sjdevnull at yahoo.com]

On Feb 9, 3:54 am, George Sakkis <george.sak... at gmail.com> wrote:
> I was talking to a colleague about one rather unexpected/undesired
> (though not buggy) behavior of some package we use. Although there is
> an easy fix (or at least workaround) on our end without any apparent
> side effect, he strongly suggested extending the relevant code by hard
> patching it and posting the patch upstream, hopefully to be accepted
> at some point in the future. In fact we maintain patches against
> specific versions of several packages that are applied automatically
> on each new build. The main argument is that this is the right thing
> to do, as opposed to an "ugly" workaround or a fragile monkey patch.
> On the other hand, I favor practicality over purity and my general
> rule of thumb is that "no patch" > "monkey patch" > "hard patch", at
> least for anything less than a (critical) bug fix.

I'd monkey patch for the meantime, but send a hard patch in the hopes
of shifting the maintenance burden to someone else.  (Plus maybe help
out the upstream project and other people, I guess)