[consulting] Patching code on client's site, and general packaging of customizations
Boris Mann
boris at bryght.com
Fri Dec 15 16:23:30 UTC 2006
On 12/15/06, Bèr Kessels <ber at webschuur.com> wrote:
So yes, I see a big problem here, basically because commercial/consultants
> cannot make their work valuable for Drupal, becuase most of us cannot wait
> for a patch to hit core or the contrib it was made for.
Sure. So you roll the patch, submit it to the queue, and run the patched
version. When the "upstream" code is updated to include the patch, you
update your local version and you're back in sync. If you skip the step of
making a patch, you always have to be maintaining a custom version.
Generally, good discussion with module maintainers doesn't mean weeks for a
patch....
On top of that, I run most of my clients sites of a single multisite
> (sympal.nl) and that makes it impossible to do any core hacks.
No it doesn't. You can override any core modules (yes, not .inc etc. files)
by placing them in the sites/modules directory. You can do this on a per
site basis. And, you can maintain a patched version of your core install as
well, although this takes more effort (but not a lot, since core updates
much more infrequently than contribs).
I hardly ever commit patches for core, for they hardly ever get in, in a)
> the
> way I find them useful, b) a useful timeframe. For me its inacceptible to
> work on one issue for two, three weeks.
That's unfortunate. Usually things will only get into the next version of
course, but then you can know that in the next version, your fixes will be
in and we all have a better product.
--
Boris Mann
Vancouver 778-896-2747
San Francisco 415-367-3595
Skype borismann
http://www.bryght.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20061215/772c75b0/attachment.htm
More information about the consulting
mailing list