Vivaldi code integration. Our developers tell

Recently, the Norwegian edition of Digi.no published a story about how Vivaldi browser developers work with the Chromium code. In an interview, the three leading specialists of the company for the first time publicly told about this important component of the development process of the Vivaldi browser.

In an interview with the Norwegian edition, three employees of the company participated - Yngve Pettersen, Jarle Antonsen and Andre Schultz. They talked about how work is being done on integrating the Vivaldi browser code and the Chromium core that is used in the browser - the advantages and disadvantages of this approach, as well as the problems that arise and how to deal with them.

Below is a translation into Russian of the most interesting questions and answers.


(Clockwise from left to right) Harald Brombach from Digi.no, Jarle Antonsen, Yngve Pettersen, Andre Schulz.

Is the problem a large volume and a short periodicity of updating the Chromium core code?

Ingwe Pettersen (Lead Engineer) : A new version of Chromium is released every six weeks and we need to integrate our own Vivaldi code with the code for this kernel. I am engaged in this task, being responsible for the code base of the browser. And - yes, this is quite a difficult and time-consuming work, which takes several weeks.

Is there any progress in this work?

Jarle Antonsen (project manager) : Previously, the integration process took three to four weeks, but with the integration of the last two versions of Chromium (68 and 69), the Vivaldi developers managed in less than two weeks. The main problem was regressions - when our code stopped working with the Chromium code, and it was their correction that took most of the time.

How is the Chromium community working?

Andre Schulz (UI Developer) : To our joy, very productive. I constantly send questions to the developers of various modules and get quite detailed answers, sometimes even with suggestions on how to make the module work even better.

Do you contribute to the development of Chromium?

Ingwe Pettersen : Over the past six months, we sent a dozen patches for the Chromium code. These are mainly suggestions for clearing the code, but there have also been bug fixes. Right now we are preparing a few more patches to be sent to the developers of Chromium.


Jarle Antonsen, Yngve Pettersen, Andre Schultz.

How complex and lengthy is the code integration process?

Ingwe Pettersen : After the release of the next Chromium update, I create a new separate branch and start working with it. I extract the Chromium code and sync all the sub-modules that we use while making small changes. This part of the process is quite well automated with us.

Then we copy all our updates over the Chromium codebase. There is a lot of manual work, because we get quite a few regressions and code merge conflicts. Previously, it was very problematic, but over time we cleaned the code well from the elements that caused conflicts, and today everything is much simpler. For example, in the last update we made changes to approximately 900 files, and only 80 files required manual editing of the code. It took me about five to six hours to do this — it used to take at least a week.

After the completion of the code merge, it is required to compile the browser code for various platforms - Windows, Linux, Mac. As a rule, it takes one day or even several hours. In general, the process of merging code takes two or three days today.

How are new problems identified?

Ingwe Pettersen : Actually, in the process of integrating the code, errors are already showing up, in order to correct which, you have to make changes to the code of the Vivaldi modules. This can take quite a long time.

Then Andre, Jarle and other developers are starting to fix the detected problems, as well as new ones that are already being detected during the testing process of the Vivaldi browser.

And how difficult is this process?

Andre Schulz : Yes, the changes at Chromium are the most difficult in our work. A couple of times we turned off the flags for some functions and worked in parallel with the Chromium functions, which were actually removed from the following kernel versions. This created many problems for us. The most difficult case occurred when upgrading to the Chromium 64 core and it took us a lot of time to fix it, which affected the reduction in the rate of release of the new Vivaldi browser assemblies.

Ingwe Pettersen : After fixing the problems that have arisen during the integration of the new kernel, we continue to work on finding and correcting errors until we get a fairly stable version that is suitable for release as a finished product.

How are things with the addition of new features in the browser?

Ingwe Pettersen : Yes, we do not stop working on new functions, so the main code of Vivaldi is constantly changing and being tested. Every time one of the developers adds changes to the code, a new assembly is automatically created. These assemblies are actively tested first inside the company and by third-party testers of Sopranos, and then by users of public browser test assemblies, and in the end it is the QA department that decides whether we are ready to release the final release.

Now about 20 developers work for Vivaldi. I do not know exactly how many developers are involved in the development of Chromium, but there are, of course, much more than us. You can try to compare the number of changes in the code made by both teams recently.

For five years, we have made more than 17,000 changes to our core code. Over the past year we have made more than 2,700 changes. For comparison, between Chromium 67 and 68, approximately 12,000 changes were made to the Chromium code, and between versions 68 and 69, this figure amounted to about 15,000 changes. In other words, the Chromium development team made as many changes in a few days as we made in our code in a year. Therefore, I estimate the number of active Chromium developers at about 600 people.

Jarle antonsenA: As a rule, we have a little time from the idea to the realization of a new function. In a small team it is easier to avoid excessive bureaucracy. At the same time, almost all team members are actively involved in testing new functions, including the director of the company, Jon von Tachner. And, of course, the process of adding new features is very dependent on user requests - their recommendations and feedback are crucial to our work.


(Clockwise from left to right) Jarle Antonsen, Yngve Pettersen, Andre Schulz, Harald Brombach.

Original article