Patch Integration

Some time ago we received legitimate complaints about occasionally slow responses to patches. So we decided to aim for faster response times. To make it easier to monitor the achievement of objectives we created a statistics page. But this is only the tool to help monitoring the responsiveness (that IMHO meanwhile is quite good!). At the end it's more interesting how fast patches get integrated and how much of them.

I collected some data about patches that where fixed and integrated on the 2.x code line. I collected data only for the 2.x code line as the different development model on the 1.x code line doesn't allow a direct comparison. Most of the patches we received between the release of 1.0 and 2.0 went into the 2.0 “big bang” release, nearly none of them where added to the 1.1.x releases (what might be part of the problem that I described with my introduction).

I created two data series, one of them containing all “code” projects, one without the “tools” and “ porting” projects as they usually are treated by different developers (release engineers, porters) and I wanted to see if it's OK to throw them together. From the diagram you can see that there isn't a big difference between the groups so it's safe to look on the total numbers (red area).

The diagram shows that starting with 2.1 the number of integrated patches per release has grown considerably, especially the 2.3 release is outstanding in this regard.

Some other interesting numbers:

Today we have 2425 submitted patches in the “ code” projects (on all code lines), 1958 of them are fixed and (except 30 of them with target 2.3.1. and 2.4) integrated, 334 have been rejected for various reasons (worksforme, invalid, duplicate) and only 133 are still open.

So there's till some work to do but the improvement is clearly visible.

tags: patch

Comments