I recently worked on the following RC bugs:

• #677861 — lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'
  I provided some analysis. By rebuilding lftp’s configure script with recent autotools, this should be fixed.
• #676229 — gnustep-make: should depend on a chosen version of gobjc, not just "gobjc"
  This issue was fixed by an upload, but not marked as closed. I tried to reproduce it and failed (as expected), so I closed the bug.
• #694091 — bcrypt: Tries to load whole file into memory regardless of the size
  I patched bcrypt to use a window of 256K over the input and output file instead of loading it into memory. I also fixed the offset types so that it works with files > 2 GiB on 32-bit platforms.

I have to say that I find the BTS to be very hard to read from the perspective of a newcomer who wants to help squashing RC bugs, both from a technical and a social standpoint.

As an example for the technical side: blocking bugs are very easy to miss, so innocent bugreports which seem actionable turn out to just wait for another bug with lots of discussion. Also, it seems like the best interface to the BTS for RC bugs is UDD, so RichiH’s RC report was quite helpful.

For the social side: Bugreports often are in a state in which it is not clear what the next course of action is, e.g. #634261 (the bug is not considered RC, but still has severity: grave) or #684633 (dropping from testing suggested but not clear whether a removal request has been filed or not).

I’m aware that this is very vague critic. I suppose what I am missing is a way in which we can make the list of RC bugs more actionable. When I am browsing through RC bugs, I often open bugreports and figure out that there’s nothing I can do. Possibly a way to improve this situation is by letting people claim ownership of a bug and then filtering for un-owned bugs and those which have an owner but have not seen any activity for some period of time.