Vendor/Release Structure

Vendors that are building against Mer have usually multiple repositories, this document is an example how these repositories are formed and could be published.

Repository names

live

A repository where the real time development happens.

next

A repository that is snapshot of the next upcoming release from the vendor.

latest

Points to the latest static release.

Content of repositories

Each repository needs to define the Mer release it was build against, HOW? File? Content of file? URL? Copied Mer release?

Example repository structure

<VendorProject>/
    releases/
        <releaseId>/
            builds/
                <repository>/
                    <arch>
            <mer-release?>
            images/
        next
        latest
        live

Example Vendors

Vendor: Jolla

Jolla as one of the vendors building against Mer, is using some of the Mer packages (such as mer-core, mer-tools, hybris-hal common stuff, essentially HADK (https://github.com/mer-hybris ) ) in their source code.

Jolla's Release Cycle

Release Cycle

The release process in Jolla consists of various automated and manual parts. They have Git, Webhooks, OBS , Jolla Bugzilla, CI-bot, and last but not least, sailors + community contributers to make the OS release land sanely on the devices. You're going to read in the following lines how the whole release process works, from different release levels and QA workflow to bugzilla integration and the CI process.

The current release process in Jolla consists of three levels: devel, testing, and release

During all these levels, Jolla needs packages from two main sources:

1. Jolla's internal developers who deploy on git internally, and push to webhook.
2. Mer developers who deploy on git in the open. Each repository has the Mer webhook, which then also sends to the jolla one.

Development Level

As explained above, the packages are picked from two sources:

1. Internal Jolla developers deploy via git and push the changes to webhook. The changes will then go through Jolla's OBS to be built. At this stage, for all the commits with bug numbers, there will be a comment from CI-bot automatically put to the bug, so the bug will be committed. Therefore the bugzilla status will be resolved/committed
2. Jolla picks the needed changes from Mer developers who also push commits to Jolla webhook. These will again go through OBS. However, there are no bug numbers for the commits made from Mer side (Some of the bug references currently showing up in the changelog are internal bugs of public things which need to move to the open.)

After changes from Autodoc and translation servers also go through build, OBS submits a request for package testing. Packages go through VM tests, and finally if all pass, image will be built.

Testing Level

Continuing from the previous level, all the accepted packages go to the testing level, along with a submit request which includes fixes from both Jolla and Mer developers. On Jolla side, for the commits including a bug number, CI-bot will post a comment to the related bug, and change the status of the bug to Resolved/Fixed. Everything will go through Jolla testing repository and ready for tests. The QA here is partially done automatically. If needed, there will be some manual testing done on this image by testers.

Release Level

Continuing from the previous level, all accepted changes will go to the release level. The process is the same as two other levels: Changes from Mer and Jolla developers will go through Jolla release repository after the submit request is done, and image will be ready for release testing. In this stage, for commits which contribute to bugs, CI-bot will post a comment and change the status to Resolved/Released The QA team do mostly manual testing in this level to make sure image is ready to be released to public.

The bug life cycle in Jolla bugzilla during the release process

Bugzilla Integration to CI Process

After a new bug is filed and assigned to a developer, he starts developing a fix for it on Git. What he does is to add the bug number like 'JB#number' at the end of the commit for the commits he pushes. This will help CI-bot to trigger which commit contributes to which bug, and then comments automatically to the bug whenever needed.

After developers deploys a fix for a bug, they can do two things: Either they manually put a PR link to the bug and ask fellow sailors to review it, and then push the commit, or if no review is needed, the fix will be committed In both cases, the fix will be 'committed' and CI-bot changes the status of the bug to Resolved/Committed. This happens in devel and the fix goes to be tested in 'devel' level of the release process. It also makes an automatic comment to the bug which includes info of the SailfishOS version+flavor, who did the change and when, and it also add the commit message to the comment.

After being tested and approved through 'devel', the fix goes to be tested in the 'testing' level. So CI-bot changes the bug status to Resolved/Fixed. It also makes an automatic comment to the bug which includes info of the SailfishOS version+flavor, who did the change and when, and it also shows the commit message. A QA report will also be created from the results of the test, and the release manager will accept the changes in order to let it go through the release level

After being tested and approved through 'testing', the fix goes to be tested in 'release' level. So CI-bot changes the bug status to Resolved/Released. It also makes an automatic comment to the bug which includes info of SailfishOS version+flavor, who did the change and when along with the commit message. There is also a QA report made out of the result of the tests. If later someone realizes the fix does not work after the release, he/she can re-open the bug.

The reasons to use CI-bot are:

• Lots of developer's time can be saved to do other important stuff instead of checking a bug constantly and updating its status manually.
• The CI-bot message makes it very clear for everyone to see what has changed, when it changed, who changed it and lots of other info mentioned above.

How Jolla tracks work required for a release

Check FAQ for frequently asked questions about the tracking process