Pidgin release process

[thanumalayan mad]

Hi All,

I'm a researcher working on improving the reliability of all open
source software, and was hoping to get a question cleared on the
Pidgin software release process. I once used to hack Pidgin's source
code, and wrote a patch for Yahoo! file transfer support in Pidgin
2.4.0; I'm personally interested in Pidgin's release process for that
reason.

In Pidgin, bug-fixing patches usually target the next minor version
release. I believe this is because a version release involves a lot of
work; otherwise, we could release a version immediately for each
bug-fixing patch that has been committed to <im.pidgin.pidgin> (for
example, ticket 14884 could become release version 2.10.1.1 instead of
waiting for 2.10.2 or 3.0.0).

My question is: Assuming no changes to translatable strings, what's
the biggest time-guzzling and effort-involving part of the release
process? Is it the testing (i.e. gaining confidence that the patch is
not buggy)?

Another way to put the question: If I provide a way to automatically
test patches (or monotone revisions) in thousands of real pidgin
deployments, with real users using it, but without the pidgin users
noticing any possible bad effects of the tested patches (such as a
crash due to the patch), is it possible to adopt a rolling-release
strategy for bug-fixing patches?

Thanks for any inputs provided!

---
madthanu

PS: I kinda already asked QuLogic about this in IRC. I'm hoping people
don't consider this as troll-mail, am really attempting to make good
software development easier.