Pidgin release process
madthanu at gmail.com
Sat Feb 4 14:42:06 EST 2012
Ethan (and everyone else),
Helps a lot, thanks for the reply. No need to read the rest of the
email unless you are curious why I'm concerned about all this.
I now understand that there is more, logistically, to the release
process, than just testing; like Ethan says, a rolling updates/release
process (which I was imagining) has many philosophical differences,
compared to the major-minor-micro versioning release process. And of
course, for a patch, you can't even commit it without making an expert
developer examine it in detail.
So, I guess the solution I'm thinking of can't be directly applied
in Pidgin for even simple bug fixes (like NULL pointer checks and
memory frees), even after they are are examined by an expert
developer, unless a very philosophically different release process is
> I would also point out here that it's going to be impossible to
> prevent users of untested patches for noticing any possible bad
> effects. You may be able to mitigate effects.
 Just in case it seems interesting, however, I believe there's a
way to prevent users from noticing any bad effects (other than
imperceptible performance overhead) while testing patches, including
compilation errors. The testing process would be totally transparent
to the user; he/she will perceive it as running a stable version of
the application. The testing process, in case the patch is buggy,
would also report exactly how the run of the patched version was
different from the stable version (it's not just a stack trace, it'll
be useful, I'm just worried about privacy concerns for now, EFF would
probably not like it). The method would not, however, provide
automatic fixes for buggy patches: that'd be like magic. Assuming
significant usage, you could use this method to practically gain 100%
confidence in any simple, committed patch.
Again, this would take a lot of time to move from a research idea to a
practical solution, and would even then not help Pidgin because of the
philosophical differences. Still, if someone has any views on this, do
mail me privately.
More information about the Devel