You will be unusually successful in an entertainment career.

(By the way, is it just me, or is this fortune unusually specific, moreso than most which seem to be mere bromides?)

(Image attribution: File:Fig.jpg by Fir0002, used under CC-BY-SA)

(I am aware this is almost hopelessly esoteric. I’ll say as a hint that p.m.o readers stand a far better-than-average chance of understanding this; the subset of those readers who are active web developers have an even better chance yet; and the subset of those who have been active since, oh, 19:13 PST today have the best chance of all. If you don’t get it [and who would blame you? ], I’ll explain fully in the first comment.)

Further details in bug 502369 comment 11.

In Gilchrist v. O’Keefe, 260 F.3d 87 (2001), Sotomayor wrote for the panel, which rejected an inmate’s claim that he was unconstitutionally deprived of his right to counsel during his state sentencing proceeding when the trial judge declined to appoint a new attorney to replace the attorney who withdrew after the inmate punched him in the head.

See the original source, as well as the decision itself.

It is worth highlighting that the fact that the deprivation occurred during “state sentencing” is critical to the opinion, as 28 U.S.C. § 2254(d)(1) (the relevant clause in US code) prevents granting relief in response to a state proceeding, assuming the decision was not “contrary to clearly established Federal law” (which, the decision notes, it was not). As a consequence the decision need not (and does not) reach any question along the most obvious line suggested by the quote, at least not outside of dicta (with which, tangentially, I am not particularly inclined to disagree) — an example of how legal decisions need not be as obvious as they seem, and an example of how common sense may play little to no part in the legal reasoning of a “common-sense ruling”.

Bug 466905 - Fix JSOP_NEWARRAY to be not-buggy and use it when possible. NOT REVIEWED YET

If you read bug 466905 you’ll see in comment 20 that the patch was reviewed by Brendan and was committed with the requested changes. So why is “NOT REVIEWED YET” in there? It’s an artifact of how I manage patches-in-progress; I assign the description when I create the patch, and since I can’t know whose review will eventually grace the patch, I just add a note that I’ll see when I review the change just before commit, and I make sure to fix the description immediately before pushing it into the main repository. What happened here is that I forgot to review the commit message for proper reviewed-ness.

<firebot> Check-in: http://hg.mozilla.org/tracemonkey/rev/6475993319c4 - Jeff Walden - Bug 466905 - Fix JSOP_NEWARRAY to be not-buggy and use it when possible. NOT REVIEWED YET
<Waldo> aargh
<shaver> sounds like someone needs a pre-push local hook!
<Waldo> quite possibly!

There’s a clear flaw in this process: the bad-commit-message check (and remembering to do it!) is done manually and can easily be forgotten. So, at shaver‘s suggestion, I dove into the world of Mercurial hooks. After a little reading from chapter 10 and section 11.3, I present you with ensure-not-unreviewed:

To use, simply drop that somewhere on your system, chmod +x it, and copy the following lines into ~/.hgrc (.hg/hgrc if you want this configurable on a per-repository basis):

[hooks]
preoutgoing.ensure_not_unreviewed = /path/where/you/downloaded/ensure-not-unreviewed

That should take care of the problem of buggy descriptions permanently. Now if only I could write a preoutgoing hook to prevent pushing buggy patches…