[consulting] Patching code on client's site, and general packaging of customizations
ber at webschuur.com
Fri Dec 15 11:31:30 UTC 2006
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.
-- 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
#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
I maintain these in a local directory, for each project.
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/57121a2d/attachment.pgp
More information about the consulting