In article <1410d2e2-a6f2-4b6c-a745-6d3e34994...@q16g2000yqq.googlegroups.com>,
>
George Sakkis 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 with
On Feb 9, 3:54 am, George Sakkis 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
On Feb 9, 12:54 am, George Sakkis wrote:
> So I'm wondering if there is a consensus on when it's better to (hard)
> patch, monkey patch or just try to work around a third party package
> that doesn't do exactly what one would like. Does it have mainly to do
> with the reason for the patch (e.g. fi
On Tue, Feb 9, 2010 at 12:54 AM, George Sakkis wrote:
> So I'm wondering if there is a consensus on when it's better to (hard)
> patch, monkey patch or just try to work around a third party package
> that doesn't do exactly what one would like. Does it have mainly to do
> with the reason for the p
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 postin
