Last week, I ran into a small speedbump with my development process. I normally write my patches and commit them to git with initial lines that look like:
fix IPDL thinko for never-inline method declarations; r=bent
Then, when I use git-bz to push my patches to bugzilla, it autofills the r?
flag for the patch to :bent
, according to the r=
bit specified in the commit message. Quite convenient.
Except last week, something broke when trying to use that feature. Bugzilla would complain that :bent
was an invalid user. “OK, fine,” I initially thought, “maybe :bent is unavailable.” (People often change their Bugzilla name to not include :NAME
when they won’t be reachable for a period of time.) Inspection showed this to not be the case. Although the initial evaluation was that git-bz
was old and crusty (it screen-scrapes Bugzilla, rather than using Bugzilla’s REST API), it turned out that Bugzilla was indeed at fault.
OK, but what to do until Bugzilla actually gets updated with the fix? Options:
- Cope with a little extra work: use
git-bz
as normal, but manually set ther?
flags from Bugzilla’s web UI. - Paralysis: any extra work is unacceptable, so do nothing (at least in terms of writing patches).
I admit option 2 is a bit silly, but that’s exactly what the situation felt like: there had been this unexpected obstacle in my normally smooth development process and it was simply Not Worth going back and doing things the old way.
I then realized that this situation, in reverse, is exactly the “barriers to entry” that people like Gregory Szorc talk about: every extra step that you have to do in Firefox development (or development generally) is one more place for somebody to run into trouble and decide contributing to your project isn’t worth the hassle. Make the extra steps go away! (And then don’t bring them back via bugs. *wink*)
Tags: development, mozilla, psychology, roadblocks