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

[Boris Mann]

On 12/13/06, Larry Garfield <larry at garfieldtech.com> wrote:
>
>
> My company is not a Drupal shop primarily (this is our first Drupal site),
> and
> we don't have CVS at work (just SVN), so what I've been doing for patches
> is
> making an issue with some notes in it on the appropriate project, then
> when I
> get home (or a day or three later) rolling the patch at home myself and
> submitting that.  Then I just tell the client "here's this issue, be
> careful".  So far it hasn't caused any major catastrophes, but then
> they've
> all been fairly minor changes.  I'm rather curious how more active
> consultant/developers handle it.
>

That's pretty much good best practices. We use Trac on top of SVN and file
tickets that point to Drupal issues and follow up with them to make sure
that the patch (or a version of it) gets in, and then synching the deployed
code with the patch included.

There are some other issues around branching/tagging that you have to figure
out a process for in terms of rolling out updates, as well as scheduling
"upstream syncing" with contrib modules you are using, but, as I said, this
is mostly process and procedure. I want to do some more thinking and perhaps
a writeup on the SVN / CVS combo and approaches to branching for different
kinds of projects.

All of this is classic change management stuff. With Drupal and open source
in general, you "pay" in doing this kind of change management rather than
official vendor fixes (or not being able to do ANY fixes until you scream at
a vendor enough).

-- 
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/20061214/cf1f779f/attachment.htm