[consulting] Patching code on client's site, and general packaging of customizations

[Bèr Kessels]

Hello,

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
> patch....

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 
find. 
Its the bigger cleanups, or big strctural changes, new apis, new theme 
functions, improvements to interface and so forth are the patches I am 
talking about. 

> > 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.

Bèr
-- 

Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: 
sympal.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/consulting/attachments/20061215/8eedf3b5/attachment.pgp