The same trend shows up if we analyze the time needed to commit a patch or to close an issue report.
Under rapid releases, the median times to submit or commit a patch, or to close an issue report, were all reduced.
As expected, taking the time of issue creation as reference, commiting a patch takes longer than submitting a patch for peer review, and closing an issue report takes even longer.
Table 2 shows metrics on the time it takes to propose a patch in multiple contexts: the time to submit a patch to code review, the time to commit a patch to a source code repository, and the time to close an issue report.
For instance, when computing time to commit, we are interested in the time it takes to commit a patch for an issue that was created in a certain period; therefore, for this specific metric, issues are classified according to their creation time.
For instance, the metric time to commit measures the time between the creation of an issue report and the first commit of a patch to that report.
It can also happen after a patch is committed to a central code repository, in which case a supplementary patch should be committed (Park et al. 2012).
After that, the issue may be ASSIGNED to a developer, and then RESOLVED (with resolution FIXED, if a patch was committed to the source code repository).
When computing time to backout, on the other hand, the question is "how long it takes to backout a patch that was commited under rapid/traditional releases"; therefore, the timestamp of the first issue-resolving commit is used.
Since an issue can only be reopened after it is closed, which occurs when a patch is tested and commited, one would expect that reopened issues are often associated with a late backout.
