Skip to content

Correction

LineageOS's 57 dropped changes were withdrawn from the host, not failed requests

LineageOS 2025-10 dropped 57 changes as comment_error, and a rebuild of that month dropped exactly 57 again with every other count identical, so the drop was not transient. A one-request-per-change probe of the month (stopped at 1,562 of 4,161 changes, to spare a host then returning 502s) found timeouts and 502s, which the client retries five times and which rarely survive that, and 404s, which it does not retry. Two of the 404s were checked by hand: the change itself now answers 404. They were public when the snapshot listed them (fetched 2026-09-29) and were deleted or made private since.

An audit of this log against its artifacts: nine conclusions in force are wrong or unsupported

A reader with no part in writing these entries went through the log oldest to newest, re-deriving figures from the committed artifacts, and checked the current docs and the Stage 1 draft against it. Two findings were re-checked by hand before anything was acted on (the leakage halt and the test size, below). What stands, by consequence:

FDLoRA's implementation, corrected before it ran: what job 183579 would have measured wrong

An independent review of PR #36 found the round-0 average (Algorithm 1, line 7) was computed per source rather than over every client the plan builds, before job 183579 reached its queue slot. The paper's N is every client the server sees; this repository's sources name separate simulated federations for the attack scripts, and the two are not the same population. Fixed by flattening plan into one list before Stage 1 runs and averaging over all of it, so theta_s0 is one value shared across every client regardless of source. Job 183579 was cancelled as invalid before it produced a result; nothing from it is quoted anywhere.

Correction: every successor is a rework, and corpus v2 is refrozen under the corrected rules

Retracted: the rebase-only-successor finding in the two entries above (0.34% of OpenStack's kept examples and 1.65% of Qt's in the audit, 20 and 189 in the v2 table). It was an artifact of the audit's own lookup, which keyed a change's revisions on its Change-Id. A cherry-pick carries the Change-Id to another branch, so a stable-branch copy that was only rebased lent its kind to the original. Resolved per change (by number, else by Change-Id, project and creation time together), every OpenStack successor and 11,444 of Qt's 11,448 are reworks; the other 4 are changes that cannot be told apart and are kept and counted. The rule stays as a guard, and now removes nothing. A review of the v2 branch caught it. Rebase edits carried inside a reworked successor remain the open question the audit entry names.

The privacy LoRA provides by design is the wrong privacy for an organization

Malekmohammadi and Farnadi, "LoRA Provides Differential Privacy by Design via Random Sketching" (arXiv:2409.17538, revised 2026-02-10), prove that low-rank adaptation is equivalent to training with noisy batch gradients, the noise decreasing in the rank, and derive an inherent differential privacy guarantee when the adaptation matrices A are frozen, with the level set by rank and batch size. They offer it as the reason LoRA-tuned models resist privacy attacks.

The censoring confound, after two bugs in the inputs

scripts/censoring.py, datasets/results/censoring.json. Snapshots select changes by last update; windows assign them by creation. A change created inside a window whose last update falls after the final collected month is absent entirely, and what disappears is the slow reviews. The loss cannot be counted, because a truncated change leaves no record; the lag from creation to last update can be, for changes whose lag was short enough to be seen. That is right truncation, and Lynden-Bell (1971) gives its nonparametric MLE.

Two API facts the code was wrong about, both found by fetching

  • The change payload carries no file content. o=ALL_FILES returns only metadata (lines_deleted, old_sha, size_delta). Hunks now come from Gerrit's own diff endpoint, which also keeps hunk boundaries identical to what the reviewer saw.
  • after: filters on last update, not creation. after:2024-10-01 before:2024-10-03 returned a change created 2024-08-26. The post-cutoff contamination argument rests on creation date, so created_on_or_after enforces it client-side.