Latest revision as of 12:41, 19 May 2015

[edit] Mer Frequently Asked Questions

[edit] What is Mer, and how can I learn more about it?

Mer is a free software and open source, open governance project focused on creating a core GNU/Linux stack for rapid development of embedded & mobile GNU/Linux based systems. The aim of Mer is to help vendors quickly create a basic GNU/Linux environment, which can then be adapted to their hardware and user interface requirements. There are currently 302 packages that comprise Mer, and they are derived from MeeGo core. You can learn more about the project by asking questions using a web IRC chat interface.

[edit] What does Mer mean for End-Users?

Mer is intended to be used directly by system integrators and hardware developers and only indirectly by normal end-users. Since Mer is derived from MeeGo, Mer is already capable of addressing the end-users that would use MeeGo, but projects dedicated to specific user-interface layers have not yet been formally organized, so the user-interface demonstrations of Mer are currently only demonstrations. Currently, the most active informal user-interface layer and hardware adaptation is the Nemo Mobile for the Nokia N900/N950/N9. Another active hardware adaptation is the Raspberry Pi adaptation.

[edit] What does Mer mean for MeeGo-community developers?

While Tizen offers "membership in most project teams (Release Engineering, QA, Program Management, etc.) ... to people at companies who are building products based on Tizen," Mer aims to be open to participation on a merit basis and to be openly developed and governed as a meritocracy. Mer is currently comprised of 302 packages derived from MeeGo Core, and since Tizen will also derive from MeeGo, Mer aims to remain compatible with Tizen and share as much code with Tizen as possible once the source code for Tizen is released.

[edit] What documentation is available to help me start development on Mer?

Because the Mer project is new, documentation is still being developed, and some questions can only be answered by asking in the Mer IRC channel. At this point, there is a FakeOBS for building a Mer system. For application development, please see the MeeGo Community Edition for the Nokia N900/N950/N9, which is a user-interface layer that is compatible with Mer.

[edit] Will Mer provide GTK or .deb packages or [some other feature]?

In order to be sustainable, Mer needs to focus development effort on adapting MeeGo, which does not provide these features. Even so, other efforts have coalesced around Mer to provide certain features that are possible with Mer but require extra developer time. Cordia Hildon-Desktop is a distribution that uses Mer as an upstream and provides a GTK Hildon desktop in the spirit of Maemo. Please use the Mer IRC channel to discuss development effort towards implementing new features.

[edit] Can I install Mer on device X ?

Instead of Mer core, you probably want to install one the projects that use Mer as base, since in those projects usually target is to provide a complete OS with UI and HW adaptation. See Community Workspace for information about available user experiences and HW adaptations. As explained in #What does Mer mean for End-Users, Mer itself is not targeted for end-users, so installing it makes only sense if you are developing Mer or porting the core itself to a new platform.

[edit] What license(s) is Mer under

Mer itself does not impose any particular license to the packages it is composed of. The packages use various FOSS licenses such as GPL, LGPL, BSD, and MIT. For details you can query lisences on Mer based image with: "rpm -qa --queryformat '%{NAME} has license(s): %{LICENSE}\n'"

[edit] Frequently Asked Questions for Vendors

[edit] Vendor 'Jolla' Frequently Asked Questions

[edit] How does Jolla currently track work required for a release?

An Example Changelog - from a closed-sourced package

An Example Changelog - from an open-sourced package

Currently in Jolla OBS changelog, the commits for non-open-source packages are followed by a bug number which the commit contributes to. Take the attached picture as an example of changelog with bug numbers for the 'ambianced' package. (On the device, the changelogs are reachable via 'rpm -q --changelog package_name' )

However, for changes coming from open source packages, the commits do not follow any bug numbers. Existing open packages include some on Mer side such as mer-core, mer-tools, hybris-hal common stuff, essentially HADK (https://github.com/mer-hybris ); some on Sailfish open bits ( https://github.com/sailfishos ), and nemo:mw

In Mer projects, looking at the changelog only shows the commit messages without any bug numbers, so nothing is traceable from Jolla side by bug numbers. When releases are made, it's important to be able to track the changes from bugzilla. Internal developers need to provide the release manager at least one bug which addresses to the changes they've made for the new update. As also mentioned earlier in Jolla's porposal, as one of Mer's vendors, Jolla would like to ask the Mer package maintainers and the Mer community to please adopt a policy to require bug numbers in some commits to Mer packages to support vendor tracking of changes in Mer.

To have this tracking mechanism also on the open side, developers can file a bug on Mer Bugzilla explaining the issue they have a fix for, and then provide the bug number (e.g. MER#12345) in the commit message they push to git. This will benefit both sides, as:

1. Mer can provide same kind of automation and tracking.
2. Jolla can cut down the manual effort required for tracking the changes in the open parts.
3. Jolla can move planning of open components to mer bugzilla

[edit] How can providing a bug number reduce the manual work in tracking?

Before having the bug numbers for commits from the Mer community, changes on the Mer side was tracked manually. The reason to have this bug number is to be able to track Mer bugs on Jolla bugzilla and automate as much of the process as possible. Basically there are three steps:

1. A bug gets created on Mer side
2. Either a developer creates a tracking bug on Jolla side, or our CI-bot creates it automatically when it encounter a Mer bug reference in the package changes.
3. Jolla CI-bot reports the progress through the different integration levels to the tracking bug in Jolla bugzilla

Our goals here are:

• To work on open components, in the open, using the external bugzilla
• To have an internal interface for tracking the changes in both open and closed components, because:
  • There are dependencies between the open and closed components
  • There are dependencies to tasks in other areas like business development, marketing, etc., that need to be tracked internally
  • Collecting and updating information manually in several places is difficult and time consuming
• Minimize the amount of manual work required in development, testing and releasing to make this tracking possible

[edit] How is the tracking bug updated in the Jolla bugzilla?

The information from bugs in Mer bugzilla are visible in Jolla bugzilla for tracking and planning during the integration (=release) process.The linking works in the way that there is an external bug linked to a Jolla bug and this will make the Jolla bug to be the 'tracking' bug. This can be done while creating the external bug or any time later. Jolla bugzilla will receive notifications about Mer bug changes and update any tracking bugs accordingly:

• When there is a new comment in the external bug, the tracking bug will also have the comment added as a reflection of the external bug followed by an email notification in Jolla bugzilla.
• When there is a status change in the external bug, there will be an email notification triggered for the tracking bug about this status change. On Jolla side, they have the freedom to change the bug status accordingly if needed, and this does not trigger any notifications on Mer side. As mentioned earlier, the integration workflows in Mer and Jolla are different, so the bug statuses are also independent from each other.

This way the tracking bugs will provide access to the relevant information of the external bugs, easily from a single interface for our developers

[edit] Is it a must to include a bug number in our commit message in order to be able to contribute?

Yes. However, we will not reject commits if they don't have a reference (fixes MER#12345). This new service is offered to enhance the ways of working and get comprehensive overview of the fixes and features that are shipped.

[edit] I am not a Mer maintainer, but I want to contribute to Jolla's release project. Where can I start from?

Start by reading about Mer and how contribution works in there. After getting an overview of things, take a look at the Mer Vendors,and learn about Jolla's release cycle and open-source codes

[edit] What are the requirements for contribution?

Read Contribution in detail

[edit] What is the format of the bug included in the commit message?

The bot will recognize it as MER#12345 (the 12345 will be replaced with the accurate bug number). The MER#xxx can be anywhere in the git message, or part of an annotated tag.

[edit] What happens exactly when I include this bug number in my commit message?

The bot notices the bug number and creates a clone for it on the Jolla bugzilla.

[edit] Do the changes related to Nemo side go to Nemo Bugzilla?

It will happen for all nemo:mw projects that are being merged into mer (i.e. you will have something like MER#12345). But hardware adaptation part of nemo bz (for hadk devices) is not being merged, because mer is HA-independent

[edit] Are these changes going to disrupt other Mer vendors' schedule?

No. Any vendor can choose to follow this process. Ultimately this is a policy which maintainers need to be satisfied with.