We now have much richer test suite infrastructure than we've ever had
before; do you think it's reasonable to ask that dependent projects,
in cases where they aren't able or willing to fix the core bugs that
affect their apps themselves, contribute test cases that protect the
behaviour they need, which may not be exercised by Firefox as primary
test vehicle?  In post-facto cases we'd probably need to commit them
as TODOs with a bug to track their enabling, though in such post-facto
cases where I have module authority I'd be more tempted to back out
the offending patch and commit the test cases in support of whatever
the subsequent fix is.  It does mean that app owners need to take an
active role in helping make Gecko a better platform for their charges,
and can't rely simply on negotiating for blocking status to get
someone else to carry the costs of fixes, but I don't think the burden
is . And in some cases, as with Cocoa widgets, we would start to get
some badly-needed test coverage -- something I would imagine the
Camino folks would really shine at, given their historical expertise
in blending Gecko with Cocoa.

Is that something that non-Firefox app owners are up for?  Are there
already test cases for the various SM2-blocking bugs to let people
working on the core know when they've fixed them?  Do we have test
cases that will let Gecko folk know when they've fixed whatever is
ailing Camino or Sunbird or Komodo?

I agree with Rob in this narrow way at least: the bug in question is
just a crappy bug, which shouldn't have been "fixed" the way it was,
and I think it's a (happily rare) failing of reviewership and
stewardship that we're in some danger of shipping it in that state.
As someone who's often a reviewer and steward, I feel bad that we got
here as well, and I'll do what I can to make things right.  Hard cases
make strange bedfellows, or something, but I don't think that this
outlier ("what we did works for Firefox[*], module owner doesn't want
to make a better change, we're not yet ready to make it an
ownership-confidence issue") is or should be taken as a trend for
Firefox-driver decisions.

[*] Except where it doesn't, by breaking reasonable cross-platform
assumptions for extension authors.  This thing has enough strikes to
end a few innings by itself, I think.

We shouldn't block Firefox for things that don't affect Firefox, as a
tautology, but Gecko's effect on Firefox is deeper than as a shared
library to which it links, and if we're saying that we can't take
incompatible fixes on the maintenance branch -- sound policy, in
general! -- then we need to look a few moves ahead when locking out
fixes until the next feature release cycle.  Firefox benefits from
Gecko's role as a shared technology, and we should try to avoid taking
unnecessary regressions in sister products.  I don't know how many of
the SM2 bugs are "it would be good if this capability were more
general" rather than regressions in the 1.8->1.9 cycle, but the latter
should be triaged very differently, by my lights.

I'll say again, though: all apps, Firefox included, should be helping
Gecko help them by ladling on the test cases, and we should be
requiring tests for anything of significance that hits our trunk.
We're paying the cost every day for not having tests on key areas of
code, and the price only goes up as we get farther into the release.

I'm out of commas and synthetic em dashes now so I guess I'm done!

Mike