So, Joey Hess managed to stir up a bit of a discussion on the relative merits of patch management systems used in Debian packages. I guess it's a bit of a change from having this discussion on debian-mentors, at least...
So I was thinking that it's time to really have a head-to-head of all of the methods that people have to manage their patches -- from the purpose-built systems, like dpatch and cdbs, to revision control systems and the scripts layered on top, to whatever personal processes various Developers may have.
To assist in working out what to write, and to make comparisons a little more structured, I've jotted down a few ideas about what areas we might like to compare different systems against.
- Friendliness to a developer experienced in using the system (general usability)
- Friendliness to a developer unused to the system (learning curve)
- Friendliness to sporadic developers such as the security team, NMUers, etc (decentralisation?)
- Friendliness to "observers" -- people who want to take a look at the code (transparency)
- Friendliness to upstream (collaboration)
- Friendliness to downstream (collaboration / derivation)
- Ease of bumping to a new upstream version (inertia?)
- Adaptibility to different working methodologies (flexibility)
So, tell us all your systems and why they work. Feel free to wax lyrical. Describe how your system works (even for the established programs, for people who aren't already familiar with the way they work), and describe how they match the areas above. I'd also be interested in hearing about systems you've tried and decided they weren't up to snuff.
I'll be attempting to at least aggregate, if not summarise and combine, the opinions of everyone who contributes. If your blog is syndicated on Planet Debian, Just Blog It. Otherwise, either e-mail your ideas to me or send me a link to your blog or other page where your brainwaves are saved for posterity, and I'll include them in my "analysis".