NOTE: this article is of interest to historians, as it was originally written in 2011

Introduction

The purpose of this analysis is to estimate the usefulness of the ACK/NACK system as used in OpenVPN project's development. This study goes back two years, and the data is obtained from Git logs on a Git clone taken on 5th April 2012:

$ git log --since="2 years ago"

This data is cross-referenced with the emails stored in the openvpn-devel mailing list archive. As reviewing all patches and ACKs is not possible, a random sample is taken.

The hypothesis is that the ACK/NACK process is most suitable for reviewing individual patches or small patchsets sent to the openvpn-devel mailing list by developers not intimately familiar with OpenVPN. A less bureaucratic process might be more suitable for core developers, especially when less security-sensitive parts are being modified.

Current ACK/NACK code review system =

Scope

Most patches have required an ACK before going into Git "master". There are a only few exceptions:

• Patches from James Yonan's Subversion repository are merged without review
• Anything else?

Evolution

The original ACK system required an ACK from one developer for the code to enter the Git repository. This process was later (add date?) split into two logical parts:

• Feature-ACK: this should be the primary consideration when reviewing patches. Merging useless patches makes no sense whatsoever.
• Code-ACK: if the feature makes sense, the next step would be to review that the code itself makes sense (e.g. has no obvious errors and follows established conventions)

Still later (add date?) a move towards lazy consensus was taken. So, as it stands now (Mar 2012), code can go to the Git repository without an ACK, but with a considerable delay.

Pros

The formal ACK/NACK system was imposed to increase OpenVPN code quality by decreasing the chances of bad code getting into the tree. The mandatory ACK forces peer review. In software engineering jargon, it fulfills the roles of

• Rationale management (feature-ACKs)
• Static testing (code-ACKs)

The review process obviously helps most when less-knowledgeable people send in patches which often have obvious errors and omissions.

Limitations

There are limits to what the ACK process can do. For example:

• Runtime errors may be very difficult to notice
• Seeing the "big picture" may be difficult, especially with big patchsets
• Whether a particular problems is noticed depends highly on the reviewer's skills

Cons

The ACK/NACK process has it's cons:

• Requiring an ACK slows down flow of code from contributors to the "master" development tree. This problem gets worse as the patchset size increases.
• Due to the above, it takes longer to get the code into wide circulation. This means bugs are reported later than if the code had been merged as soon as it's ready.

Raw data

This raw data is based on Git clone done on 5th Apr 2012:

Generic statistics

• Commit count: 635
• ACK number: 458
• Average ACK count: .72

ACKs by person

• Adriaan de Jong 20
• Alon Bar-Lev 3
• Davide Guerri 1
• David Sommerseth 155
• Eric F Crist 1
• Gert Doering 107
• Gilles Espinasse 1
• Heiko Hund 3
• James Yonan 116
• Jan Just Keijser 2
• Kazuyoshi Aizawa 2
• krzee 3

Effects of the ACK system on patches

The following Git command was used to generate a list of all patches in Trac format:

$ git log --date=short --since="2 years ago" --pretty=format:"|%ci|%ad|%h|%s|-|%an|-|-|-|"

A random sample of 64 patches (out of 634) was then taken using shuf -n 64. A few notes:

• Delay is calculated as "day when applied to git" - "day when sent to the ml". For example, 26th Mar - 24th Mar = 2 days. When calculating large (i.e. 1+ month) delays each month is counted as 30 days.
• Patchset refers to a major patchset; in practice it's either Buildsystem or PolarSSL.
• Author date is the date the patch was introduced (e.g. sent to the mailing list)
• Commit date is the date when the patch was commited to current Git master repository. Note that changes to Git repository's structure (e.g. "allmerged -> master") seem to have messed up Git's commit dates. This means that some patches introduced before 2010-07-27 seem to have been "floating around" for months, whereas in reality they were merged to Git fairly quickly. Attempts to find out real dates often failed, so the faulty numbers were left as-is.
• For many patches it was impossible to locate the ACK - see "?" in "Delay (after ACK)" column. These may represent ACKs given in the IRC outside IRC meetings. ACKs given in the official IRC meetings should pop up when searching the mailing list archives.
• In some cases it was impossible to determine where a patch was originally sent to. In these cases figuring out whether it was modified in the process was also impossible.

The delays shown in these patches are probably faulty (i.e. too big):

Big patchsets

For comparison, let's look at two big patchsets:

• PolarSSL support (~115 patches)

  • total of 8 changes were asked for
  • 3 of these seem trivial stylistic issues/typos

• Buildsystem revolution (52 patches)

  • a couple of changes were asked for (e.g. to enable lzo by default)

Conclusions

Although this review was fairly limited in scope (~10% of 634 patches), some interesting things surfaced:

• A patch was modified during review only on two occasions (0,32% of all patches). That said, it was often difficult to know whether a patch was modified before being introduced. This could have had happened with patches that did not go through the usual mailing list scrutiny, see "?" in "Delay (after ACK)" column.
• The larger the patchset, the longer it takes to get merged (e.g. ~110 days for PolarSSL patches). Although this is a no-brainer, there's probably lots of room for improvement.
• Quite a few patches already go into Git without review, see "-" (i.e. "not applicable") in "Delay (after ACK)" column.
• The majority of ACKs were given by only 3 persons.
• It's often very difficult to find discussion about patches: see "?" in "Delay (after ACK)" column.