[consulting] Patching code on client's site, and general packaging of customizations
ber at webschuur.com
Fri Dec 15 16:50:22 UTC 2006
Op vrijdag 15 december 2006 17:23, schreef Boris Mann:
> > 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
I think it needs a little more explanation. I deliberatly did notget too deep
into this, not to sidetrack the disussio, however:
Submitting a patch is not hard at all. once a patch is made to work for me and
my version, however, it is FAR from ready for core in 99% of the cases.
Think about often heard comments like 'good patch, but foo.module uses
something similar can we not roll it into there too', or 'I like Foo part of
the patch, but don't like Bar', or the one thing you never want tto hear 'Why
is this any good for core, you can do Bar with Foo already'.
After wich new action (be it rerolling the patch, or additional description)
is required; This is a good thing, for it ensures High Quality for core.
However, just look at the issue queue for core. You hardly find any larger
issues that went in in their original form, or without any Real Quality time
by the author.
Small bugfixes, (tiny bugs, small changes to the outputted HTML, or typos)
however are handled very quick and neat, and I try to commit as many as I
Its the bigger cleanups, or big strctural changes, new apis, new theme
functions, improvements to interface and so forth are the patches I am
> > 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.
Off course that is the case.
But as consultant, or developer on a timeframe with a budget you need to
thnink: "Am I developing this to make Drupal better, or to fix issue Foo for
project Bar". When the answer is "Make Drupal Better" then it makes sense to
spend hours, smeared out over weeks. Then it makes sense to halt your project
until you can continue development with the patched and improved Drupal HEAD.
But I doubt any of us have that luxury, because I doubt any of our clients
will say 'well go ahead, delay the project until that patch hits core, I
don't mind when that is". And yes, I am aware of the fact that improvements
to Drupal are best for yourself and your clients in the end. But most of the
times its a Site that needs finished, not a CMS that needs polished in a
project. So in the most projects we cannot afford too much time on polishing
that tool, even if we all know we should, it still gets low priority.
I am/was not saying that anything should be changed, I am saying that I know
many good reasons for not patching core, this being one of them.
Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/consulting/attachments/20061215/8eedf3b5/attachment.pgp
More information about the consulting