Camptocamp attended the 14th QGIS Developer Meeting which took place at the University of Las Palmas, Canary Islands, from the 5th to the 8th of November 2015.
Two topics of discussion caught particularly our attention: the future version of QGIS 3 and in most specifically its extensions and the project management and contributions. These two subjects are now two important issues that the project must solve. Here is a short explanation and the possible mentioned resolutions.
These two issues (i.e. of “how to manage major versions of a project” and “how to manage the many contributions”) are classic in a large Open Source project like QGIlarS. Indeed, on the one hand, it receives a large amount of contributions from a wide variety of developers and, secondly, we need to predict the evolution of the project for the coming years.
CONTRIBUTION process improvement
For some time, if you follow the QGIS project, you already probably noticed the growing number of contributors. Therefore, the number of modifications to the code increase in the same proportion. The project has a release system that can have an impact on the period of availability of features developed for the next version.
Every three months, the code enters a period of features “freeze” for five weeks during which no new features can be added. This period is intended to correct problems from the previous period, focusing on adding features. The period of “freeze” also allows to translate the software. These five weeks are then a time just as active for developers. However, it is critical because it must provide a quality version as stable as possible. Ideally, developers complete the development of features before this period of “freeze”.
However, a contribution is not only to write code. It is a much more complex and longer process. There is a real preparatory work to meet an initial application that may require also some additional changes. Then the project is launched with one or more phases of development, validation by the customer and then the final integration code in the QGIS project. The customer generally expects to see the targeted feature available quickly but, depending on the importance of development, two cases may occur:
- the importance of feature requires writing a document named QEP (QGIS Enhancement Proposal). Developers will anticipate the version in development, then it will be voted and accepted by the PSC. However this is not mandatory and may be required during the development.
- most major projects have a code review process so that other developers can read the contribution and leave a comment. This process may delay the final integration of the code as it is based on volunteer work. QGIS uses this kind of replay process.
Let’s go back to the release process as a whole. The frequency of four months is a fast pace but it allows a funder to see its functionality quickly available in an official version. A first problem arises: it is quite possible to see its contribution delayed and therefore be four months behind. These delays are mainly due to a bottleneck at the code review level, or the need to draft a QEP and wait for a feedback from the community.
The discussions at the Hackfest were therefore intended to improve this situation. It shows the following (note that these are only ideas of the moment):
- force developers (core and contributor) to go through Pull Requests (system to propose code changes and to visualize the proposed changes);
- give time for reviewers (other developers) to write comments;
- allow developers to integrate their contribution after a certain time or after corrections were made following the reviews of other developers;
- ask contributors to fund the time required for proof reading since it provides an additional quality to the code proposals.
A QEP is, of course, being drafted to clarify it all.
- Explanation of the current process;
- QEP on unit testing (this QEP is a little outside of the above presentation, but it shows the interest in the quality of releases): QEP 17 and QEP 24 ;
- QEP on commit rules.
At Camptocamp, our internal or major community projects to achieve these code proofreading are organized this way. This is the case, for example, for the OpenLayers or GeoMapFish projects. However, depending on the size of the community projects is not always easy to put this in place. And you, how do you manage your projects?
In a future article, we develop on the future version of QGIS 3 and its extensions.