On the Importance of Quarterly Reports : OPNFV and OpenStack as use cases

Public quarterly reports are used for understanding the performance of companies. And so, quarterly reports done by Bitergia fill the gap of understanding the performance of open source communities. This type of analysis focuses on those that are still interested in metrics, but do not have the time to play with the dashboards. This indeed provides a full overview of the current quarter, but adds a comparison with the previous quarters. This allows to have some extra context about where the community is heading.

Continue reading “On the Importance of Quarterly Reports : OPNFV and OpenStack as use cases”

Dashboards for the Eclipse community

We’ve been maintaining a software development dashboard for the Eclipse community for a while. Now that EclipseCon is running, it is a good moment to visit it, to explain some of its peculiarities, and to comment on future directions.

Eclipse software development dashboard
Eclipse software development dashboard

The dashboard shows activity in the four main type of repositories with information about software development (git, Gerrit, Bugzilla and mailing lists) for all the projects in Eclipse. You can browse the specifics of all of them (click on the button right of “Eclipse Foundation” on the top bar), and select between a view of the whole history of the community, or restrict it to the last five years (unfold the option by clicking on “All history”, again in the top bar).

But before commenting some more details, let’s visit the future: a simple PoC of the upcoming GrimoireLab-based dashboards, showing Eclipse data as of two days ago for dashboard for git data and dashboard for Gerrit data.

GrimoireLab-based dashboard for Eclipse git data
GrimoireLab-based dashboard for Eclipse git data

The information in these new dashboards will be much more actionable, with the visitor being able of filtering by just clicking on charts and tables. These dashboards are still early demos, which although show real data, still need a lot of polishing of the user interface. For a more complete (but still proof-of-concept) demo, have a look at the one we presented during FOSDEM.

Continue reading “Dashboards for the Eclipse community”

Analyzing code review in Xen

The Xen project is an open source software project that does pre-commit peer code review. This means that every change to the source code follows a code review process, in which any developer can participate, before being accepted in the code base. During that process, the patch is carefully inspected and improved thanks to the contributions of the reviewers. The process takes place in the xen-devel mailing list.

Code review is a very important process to improve the quality of the final product, but it can also be very time-consuming, and impose too much effort on the reviewers and the developers themselves. Therefore, when a few people in the Xen Project detected an apparent increase in the number of messages devoted to code review, they become concerned. They decided to use the services of Bitergia to determine what was happening, and how it could impact the code review process of the project. And the report “Code review process analysis in the Xen Project” was born.

Time-to-merge in Xen, per semester
Time-to-merge in Xen, per semester

The main objective of the analysis (composed of two stages) was to verify if this apparent increase was really related to the code review process, and to study other parameters to determine if the code review process was deteriorating in some way. The first stage has already been completed, with three key findings:

  • Time-to-merge, probably the most important parameter to express the toll that a project is paying for reviewing code, is under control. Time-to-merge is counted from the moment a change is proposed, to the moment that change is merged, after running its corresponding code review.
  • Time-to-merge increased from 2012 to the first semester of 2014, running from about 15 days (for 75% of the changes), to close to 30 days. But since then, time-to-merge has decreased: 28 days in the second semester of 2014, and 20 in 2015 (again, for 75% of changes).
  • The trend of time-to-merge is similar despite the size of the change. The same trend is observed for changes composed of one, two, three, four or more than four patches (individual components of a change).

Currently, the second stage of the analysis is being performed. It is expected that this stage will produce actionable dashboards with detailed information that will allow to track in detail the main parameters of the Xen code review process.

These findings and more will be shown in our talk at OSCON. Remember that we will be exhibiting there and you can get a discount using BITERGIA25 code… Don’t miss the chance to visit us there!

OSCON 2016

Blog at WordPress.com.

Up ↑