[development] Getting rid of core hacks for drupal upgrade tohappen. Need tips on the process.

[Yuval Hager]

> 
> I'm answering on the dev. list because others might indeed be currently in
> the same predicament and we could probably all benefit from pooling our
> ideas on such problems, which are likely to become more frequent overall,

I am afraid that the nature of these hacks is different every time, which 
makes each of us fight his own dragon. However, I might be wrong. feel free to 
contact me off list to try and share insights and patches that might be 
helpful to you guys.

> since D5 was the first version which saw significant for-hire developments,
> most of them likely to have much the same kind of issues.

Yes, that is probably very true. D5 was a Gold release at the time, and a lot 
of folks who did not really understand opensource jumped on the wagon. D5 
looked like it is enterprise ready, but it had a lot of problems with scaling, 
which created the need for hacks. Some hacks were made to save time, some were 
rightful patches that entered later versions of Drupal (user_load caching, 
blocks caching, locking API...).

> And going out of
> support when D7 is released, real soon now :-)
> 

Yes, that is a really good argument with clients. Wave the EOL at them and 
they will do anything you say :)

--y