Methodology

Posted Oct 31, 2013 3:39 UTC (Thu) by bnorris (subscriber, #92090)
Parent article: The kernel maintainer gap

Wolfram's data is skewed by those subsystems which make heavy use of rebasing, as this changes the CommitDate. For instance, I have first-hand knowledge of the MTD subsystem (called out by Wolfram), where a submaintainer typically queues up mostly-good patches in an initial git tree. The head maintainer typically passes over this set of commits and fixes anything up that needs it, which includes a rebase for adding his sign-off. (Essentially, MTD treats the initial git tree like patchwork.)

So effectively, most MTD commits have commit dates that are within a week or two of the merge window. Now, suppose MTD has a uniformly-random distribution of patch authorship dates which are committed after a fixed latency, then are all rebased at a given time within the 3 month release cycle. Then this resetting of the CommitDates would add on average an extra 45 days of latency to the measurement, which would account for much of the difference between MTD and the other systems (assuming the other subsystems' CommitDates reflect the true acceptance date).

Now, there is likely some part of the theory above that doesn't match reality. And I'd be the first to admit that MTD often does have periods of unfortunately high latency.

Methodology

Posted Nov 4, 2013 17:45 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]

There are also cases where the subsystem maintainer is pulling rather than applying patches from the mailing list. Then, the measured latency reflects delays in the submitter's organisation. As an extreme example, the changes to the sfc network driver that went into 3.12 will have a measured latency of up to 11 months (developed against simulated hardware but needed testing against the real thing before submission) whereas the real latency of netdev and David Miller is usually under a week.