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

[Bèr Kessels]

Op donderdag 14 december 2006 02:41, schreef Gary Feldman:
> Here's a real beginner's (consulting) question:
>
> How do you handle cases where there's a bug that you need fixed for a
> customer long before any fix will show up in CVS?  Or there's a change
> that can't be done via a hook?

Any project I ran brought me at least two such cases. On average I think I ran 
into four or five each time. 
Biggest problem is the pace of bugs going into Drupal not being the pace we 
(consultants) work.  mean, a deadline is oftne measured in days, sometimes 
weeks, A patch takes weeks if not longer to get in, most often not in the 
form/way you needed it in the first place. 

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. 

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.

> I've been tracking my changes in a
> personal Subversion repository, but it's still not particularly
> efficient.  (Looking at some of the tools layered on top of Subversion
> is on my list of things to do.)

Here is my shot at this:
#1: I give a 25% discount on work that can be re-released as a GPLed module. 
this means: 
  -- the code must be very general and useful for other projects
  -- the licence allows me, others to re-use this
Reason is that this way we can easier agree on 'general' and thus 'reusable' 
solutions. Good for me, good for the client, but often takes more time (hence 
the discount) 

#2: I maintain all my work + notes in an SVN. Good for my history, good for 
note-taking / logging. And good if ever a client wants to get other parties 
involved, because they can read back on all my hacks. No vendor-lock-in in 
the forms of hacks so to say.

#3: Whenever possible and feasible I contact authors of contribs beforehand in 
a personal mail, that I will be useing their module(s) as a base for a new 
project, so if they have new code and or unshared ideas, I will be spending a 
lot of time on the modules. Often I get good response, because it allows me 
to communicate closer between the author, my client, and myself. E.g. I have 
a rather big LDAP project coming up, I am still preparing all work, but once 
the Go is trough, I will get in touch with the LDAP module authors.

#4: Whenever possible, I commit patches for features and bugs in contribs. 
These are often taken up within days. esp, if communication from #3 is good. 
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. 
#4a: I maintain a list of all submitted issues on Drupal.org using simpy 
(delicious alike) and tags drupal,issue,CPC (capitalised project code). Works 
like a charm to keep track of all the issues relevant for a certain project.

#5: In the end I run one last CVS syncronisation, and compare that with the 
last version in my SVN. I do that for each contrib I worked on. This gives me 
a set of patches that describe any local changes that did not go back into 
any of the contribs, e.g. still waiting patches, or patches that were 
refused. 
I maintain these in a local directory, for each project.

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/57121a2d/attachment.pgp