[gentoo-catalyst] On catalyst's development process

[Matt Turner]

Zero_Chaos and I had a discussion on IRC about catalyst's development
model. Part of the discussion was whether proposed changes should go
to the mailing list for review or if the current IRC+pastebin-based
review was sufficient. As a proponent of a mailing-list-based model, I
thought it best to attempt to continue the discussion on the mailing
list itself.

Since Andrew Gaffney stopped catalyst development in early 2010
catalyst has seen only small developments. Jorge has been mostly
single-handedly keeping catalyst going by supplying patches and bug
fixes.

Without many active developers (catalyst works okay, why change it,
right?) it's been hard to get others to do patch review and easy to
miss a tiny problem in your own code. For instance, I made a mistake
in commit c3db9351 (fix: 793079a0) that would have probably caused
mips/o32 stages to fail to build. Other problems have slipped through
as well: Zero Chaos was forced to revert three commits in order to
release a version of catalyst (2.0.12.1) that actually worked. At
least twice in the last 50 commits, changes have been made that
contained a syntax error that simply would have prevented catalyst
from working. Both times they've been fixed promptly and probably
didn't cause anyone any harm, but:

I think this leads to the question of how well our development model is working.

As it currently is patches are committed ad-hoc, recently with at
least some review in the form of giving a reviewer a pastebin link on
IRC. I find this model tedious and lends itself to rapid-fire question
and answer debate about a proposed change, partly due to the medium,
partly due to pastebin'd patches having a significantly lesser chance
of containing a meaningful commit summary.

I claim that if patches were sent to the mailing list they would
receive better review from a larger reviewer base and the committed
results would contain fewer errors. The process of git
format-patch/send-email forces the author to at least look at the
patch before committing, and reviewers are likely to give a better
review to something they find on a mailing list than in IRC. At least
personally, I find that I'm much more likely to forget about something
asked of me on IRC than via email.

Patch review isn't about a power structure. It's about maintaining
quality and catching mistakes before they could affect anyone.

git is also not a review tool. Once it's in git, it's history, and I
don't like my mistakes being part of historical record. :)

Other projects handle review in different ways. The kernel and X.org
for instance require that a patch have at least one Reviewed-by tag,
stating that a third-party checked over the patch and found it
appropriate. Chrome, I think, and other Google projects use a
web-based review tool called gerrit. Either of these would be large
improvements, with the mailing list system having lower cost and
probably the same effectiveness.

See http://www.x.org/wiki/Development/Documentation/SubmittingPatches
for a description of the process.