Best way to hold back packages from being updated

   @dman: Hey, thanks for the pointers. Guess I missed those when searching.....
   @Moshe: yeah it's mostly for the sake of convenience/memory, so I can just drush update rather than having to run it, see what's out of date, check that against my own maintained list of patched modules, and then maybe cancel the command and run it with a specific list of modules to be updated. Though as I do more and more module updates I begin to realize that it's often not a good idea to update a module, so probably it's best to do them individually anyway, and maintain a list of modules that shouldn't be updated and why (ie patched, new version introduces critical unfixed bug, etc). But it would be great to have a standard way of letting future maintainers find out which modules are patched. Well, as standard as drush is, anyway — it would be really nice to have something in Drupal core to do this.

   To clarify: The site itself is under separate version control, but some modules, modules that required patches, are also under CVS, meaning that I deleted the module directory and did a CVS checkout of that module to replace it. I keep a journal of notes (that includes output from drush updates) under the same repo as the rest of the site. One of the commits shows the output from a drush update where it updated a module, and also shows that the .info file for that module changed from the CVS format to the tarball format (ie + d.o versioning information). I'm not using cvs_deploy; I have it installed but checking revision history of the DB dump logs shows that it was definitely disabled when this happened.
   Kind of seems like a spacy move on my part, but for some reason I was under the impression that drush wouldn't update those modules, so I was just doing drush update without making sure to exclude them. I'm still not totally sure if I'm understanding people correctly, that drush update actually does update CVS-versioned module code with tarball release code, since it seems counterintuitive — I'm still wondering if maybe I missed a sanity check somewhere. If that is how it works, then I feel this is a bug in drush, since it's ignoring the module's upgrade path and arbitrarily choosing another. I'm also somewhat concerned that some future site maintainer may use drush and be unaware of, or forget about, module patches, and end up wiping them out without realizing it, causing terrible chaos. Probably not worth worrying about.. but in general it's just not quite as structured as I expect. I guess I want everything to be aptitude. It does seem like there should be a standard way to do this though.

   Personally I would vote for people to put time into making a distributed SCM an option for Drupal modules, so that you could share patches with people in some sort of organized way and have a clean update path when new versions were released. Like if d.o was running something like github, and it was (optionally) integrated into Drupal's update system.. that would be awesome. IE the update system could check the commit ancestry for the module version being updated to, and if your module's commit is an ancestor, ie the release was created by merging in the branch containing that patch, then it goes ahead and updates to the new release, otherwise it just lets you know about the new release. It seems impossible to run a site without patching at least a module or two, so this sort of thing would be pretty handy. Also useful for when module maintainers unannouncedly move to Zimbabwe — people could just start using the unofficial de-facto-official release branch. I guess it would require more proficiency on the parts of module maintainers though, and obviously some infrastructure investment on the part of d.o.

   As it is, it's necessary to be very careful when updating to new versions of patched modules. Even if you do actually download, diff and re-merge like you say, @dman (that drush command sounds sweet, by the way), you have to pretty much read the entire diff for the new release to be sure that there are no conflicts with your patched code (depending on the nature of the patch). IE the fact that the diff applies as a patch doesn't prove that there are no logical conflicts with the patched code.
   Exception (fortunately a common one) to this is when the release notes mention the issue # where your patch came from, and it's obviously the patch from that issue # that they meant. It's sort of a hassle to have to do this, and it's sort of vaguely reliable, and it means that you can't cleanly apply the version-to-version patch, because part of it's already been applied, so you have to have chunks fail and deal with that, or just do a clean install of the new version and then re-patch it with any additional patches you've made on that module that weren't rolled into the new release, or something even more complicated.

A lot of my interest in this topic, and this pretty off-topic, stems from a concern for future maintenance of sites I build. EG I patch a module, push the site to production, get paid, then 10 months later there's a security update for that module, which the module maintainer has otherwise not put any time into.
   At that point, somebody needs to

1. know that the module is patched
2. know that there's a security update — which I think Drupal won't advertise for modules that are under CVS source control, unless cvs_deploy is enabled? Is that it? So the site maintainer has to be on the security mailing list and check each notice for modules that the site has CVS versions of — and
3. be technically competent enough (and have enough free time) to "sight-read" source code diffs for a patch and a module update and figure out if there's a (potentially mergeable) code conflict.

   So either that, or I have to make sure that I always have enough free time available to be able to jump in and apply a security update right away to one of the modules I've patched where that patch hasn't been rolled into a subsequent release, then go and push that code to all of the sites where I used it, or at least make it available to the current maintainers of those sites. I guess in this model I become the maintainer of the patched module 'branch'. This means that I can't move to Zimbabwe for potentially a few years after completing work on such a site, depending on how long it takes the patches to get rolled into a new release. I'd like to move to Zimbabwe some day.
   A third option is to just not patch modules, which thus far in my (albeit limited) Drupal experience I haven't found to be viable.

   I guess this is the way that the industry works though, a company with a drupal site ends up with a support contract for handling this sort of issue, unless they're big enough to have an IT group that can do it.

   Okay well if you made it this far thanks for your patience, I didn't really mean to write a book!