We have entered an interesting phase in the development cycle, what I like to roughly call the end-game. It’s a point where sacrifices and unpleasant decisions are made.
In this particular case, it’s in seeing a number of bugs which were marked as blocking the 1.9 release losing that distinction. The blocking1.9+ flags are in several cases being changed to blocking1.9-.
It’s a sad truth: not all bugs are created equal. Indeed, not all blockers are equal in severity or impact, either, and near the end of a project, drivers end up re-evaluating bugs to see what really needs to block a release. Not enough resources (human in particular), and not enough time.
I’ve seen this cycle at work, too: bugs that block a release up until a certain arbitrary point in time. That time being, “it’s time to ship something.” To me, it’s a bittersweet moment: on the one hand, very serious bugs are being taken off the must-fix list. (For a bug to get blocking1.9+ in the first place, it has to meet a high criteria.) On the other hand, it signifies that what we have now is nearly ready for our customers, and developers can either spend time on what gets us to a shippable state, or on bugs that, ultimately, don’t matter as much as others. In the interest of meeting “when it’s ready”, bugs that aren’t critical to that readiness state get dropped.
I haven’t complained about any of the bugs I’ve observed getting knocked off the blocking list, because the drivers are right about one thing: Gecko 1.9, and its primary child, Mozilla Firefox 3, are in a nearly-shippable state already. We’re at the point where it’s time to accept the fantastic work done so far with some bugs unfinished. As I said, it’s a bittersweet moment: we’re at the finish line, we just need to break the tape. We’ll deal with the sore ankle some other time.
Now, I just look forward to hearing what the post-1.9 plans are for 1.9 code. There’s talk at mozdev of using Mercurial instead of Subversion for the next-generation repository. If I had a clear guarantee that 1.9.x releases would have equivalent Mercurial repositories (or at least tags) to go with them, that’d be a big plus.