The "Latest" pill is decided by a timestamp an upstream force-push restamps on every pull request at once #281

The Latest pill on a ticket's pull request list is meant to point a contributor at the freshest fix, so they can try that one first without reading every row. On a ticket with two open pull requests it pointed at the wrong one, and sent the contributor into an apply that could not succeed.

What happened

Trac #62064 carries two open pull requests, both fixing the same overflowing password on the application-passwords screen. The app marked the older one Latest. Applying it failed — the file it touches has moved on in trunk since the pull request was written, and correctly nothing was applied. The other pull request, three rows below and unmarked, applies cleanly.

So the pill did not merely fail to help. It actively chose the dead end over the working patch.

Why

Pull requests are ranked by the last-updated timestamp GitHub reports for them. On these two:

Nineteen seconds apart — and neither stamp has anything to do with either pull request. Both are the moment a force-push of trunk upstream touched them. That single push restamped roughly 2,580 open pull requests across the repository within the same window. Which of two entries in that sweep happened to be processed first is, today, the entire basis on which the app crowns one patch over another.

This is not an edge case that needs a tie-break rule. Any ticket with more than one open pull request currently has its Latest pill decided by the internal ordering of an unrelated bulk event upstream, and that ordering has no relationship to which patch is newer, better, or applicable.

The caveat was already written down when the ranking was built: the timestamp also moves when someone comments, so Latest has always meant "most recently touched" rather than "newest code". That was accepted because an actively discussed pull request is usually also the fresh one, which is a fair trade for a comment. It does not survive an event that touches every pull request at once, because that does not nudge the ordering — it erases it and replaces it with noise.

Direction

Rank by the newest code rather than the newest touch: the date of the pull request's most recent commit. Comments, label changes, bot sweeps and base force-pushes stop reordering the list, and the pill starts answering the question a contributor is actually asking.

The cost, stated plainly

The pull request list is deliberately one request. The whole feature is careful with a shared quota that is not generous, and paginating or fanning out was rejected when it was built for exactly that reason. The search results that feed the list do not carry a commit date, so getting one means a request per pull request on the ticket.

That is a real cost and it should not be waved away. Worth considering: the pill only needs the commit date for the candidates that could plausibly win, not for every row — resolving the top few and leaving the rest unranked would keep the common case to one or two extra requests. The shape is open.

Also worth deciding

When the signal is unavailable, or when the margin between the top two is small enough that the answer is a coin flip, the pill is claiming more than the data supports. Showing nothing and letting the contributor read the dates is more honest than guessing, and costs them very little.

Related

• "No longer applies" hides a patch that is already in the tree — sometimes in the same file as one that is not #226 — the failure this steered into, and what the app should say about it
• Work on a ticket: associate a site with a Trac ticket and show its patches #109 — where the pill and the pull request list came from