Pidgin release process

[Ethan Blanton]

thanumalayan mad spake unto us the following wisdom:
> 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).

This is not precisely true.  Bugfix patches typically target the next
release required by their ABI changes; see the Pidgin FAQ for more
information on Pidgin version numbering.  Simple bug fixes (forgot to
free something or NULL a pointer, typos in strings, etc.) can
typically go in the next micro release, while bug fixes which require
more invasive changes or depend on existing restructurings in
development may have to wait for minor or major releases.

> 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)?

There are several time-guzzling parts of the release process.  In my
experience, they are the following (in no particular order):

* As you mention, determining that a specific patch is suitable for
  inclusion

* The variety of steps which take just enough time and intervention
  that you can't fire them all back to back without sitting around and
  waiting

* The SourceForge file release system

* Checks to ensure that there are no patches which Should Really Go In
  to this release which haven't yet made it[1]

* Checks with other developers and regular users to make sure there
  are no outstanding issues the developer doing the release is unaware
  of[1]

* Chasing down contact information for patches which turn up in the
  above process[2]

* Taking at least a stab at making sure compilation didn't break on OS
  X, Windows, or other bizarre or broken platforms.

[1] This could be fixed by better intra-project communication.  We
    don't have a great system for making sure everyone is On the Same
    Page.  In the past, Luke Schierer always had a very good idea of
    what was outstanding and who was blocking what.  After Luke
    stepped aside to deal with real life concerns which were taking
    more and more of his time, we had a period without any such
    bug-wrangler, and then John Bailey stepped up to that plate.
    Recently, John has been very busy with work and other things, and
    we once again have a vacuum in that department.

[2] We try to keep this to a minimum by gathering all of this
    information in the bug tracker or on the email list when a patch
    shows up, and including it at application time, but for patches
    which are included at the last minute this can be trouble.  It is
    particularly painful when users submit patches via the bug tracker
    and either provide a bogus email address or use an email address
    they seldom check, then don't update the bug when asked for more
    information.

The specific nature of a given patch may or may not make it difficult
to triage.  If it's deep within a protocol plugin, finding a developer
who knows about that plugin, and that developer finding time to
examine it carefully, can take a while.

> 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?

There's another issue at hand here, and that's whether it's
*desirable* to constantly make tiny releases with trivial patches
included.  I am of the opinion that it's probably not.  Unless the
patch fixes a security vulnerability, corrects a bug which affects a
large number of users in a nontrival way, or has some other Big
Impact, I don't think making a release for a small patch is a good
idea.  For one thing, it causes either staying up-to-date to become
painful, or people to stop worrying about staying up-to-date.

I have no doubt that we could integrate patches more quickly and
release more often to the benefit of all, but I would still suggest
bundling fairly large numbers of trivial patches into point releases,
rather than releasing for every individual change.

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.

Testing and testers *would* be valuable, and I'd love to see us have
more testers and patch & bug traigers.  However, the usual offer of
"I'd be happy to run the development version to test for you!" is not
as helpful as it looks on the surface; we really need people who can
both run the development code *and* provide detailed and comprehensive
bug reports and/or bug fixes directly.  Simply saying "I used the
patch on bug #nnnnnn and it crashed" is of very limited utility.  We
have had, at various points in the past, dedicated bug tester and
triagers, and it is indeed quite helpful.  However, it requires a
large investment of time and skills very much related to becoming an
actual developer (in fact, it's a great place for novice developers to
get into open source development).

The biggest single slowdown in Pidgin patch acceptance and Pidgin
releases at the moment is simply that almost all of the primary Pidgin
developers are extremely busy and have very little time for Pidgin
development.  You are correct that streamlining the release process
would help that, and we've made some strides toward that in the past
(like 'make release'), but it's only one piece of the puzzle.

Hope that helps.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20120204/da8d0f29/attachment.sig>