[SailfishDevel] A request to Mer Package Maintainers to support vendor tracking of changes in Mer

Nazanin Mirarab nazanin.mirarab at jollamobile.com
Tue Jan 27 13:00:09 UTC 2015


*Summary:* This is a request to Mer package maintainers and the Mer 
community to please adopt a policy of requiring bug# in some commits to 
Mer packages for supporting vendor tracking of changes in Mer.

Jolla started with the emphasis of having community-the heart of any 
open source project- involved in the long run ahead of it. We caught the 
ribbon with the motto of 'doing it together', and tried our best to 
stick to it since day one.
Today we are proposing and requesting a change which will help us all to 
be one step closer in achieving more togetherness, by opening up our 
development to anyone interested in getting a closer view of the code, 
and going further in contribution. We would like to ask our community to 
take part and collaborate in Jolla's release project.

*How Jolla tracks the work required for a release*
As you may know Jolla obtains its source code from both open-source and 
closed-source codes. The closed-source part is maintained by our 
internal developers, and the open part *[1]* by both internal and 
external developers. For each software release, this source code is 
taken from both places and shapes the release image. As expected, with 
each release candidate there is a changelog containing the information 
about what has been changed from the previous release to the current 
one. In this changelog there are both internal and external changes, 
with just one difference: For the internal changes, there is at least 
one bug number which shows what the git commit is contributing to. *[2]*

Up until now it's been that for changes in the closed-source packages 
(=the internal part), developers need to include at least one bug number 
in their commit messages which addresses to that change. However, for 
the packages on the open side there has never been such a tracking 
procedure. Therefore, tracking changes in the open has always been 
difficult, whether for the release manager, testers, or anyone else 
interested in following the changes.
Having this bug number in the changelog for the closed-source part has 
had several advantages:

 1.  From the release manager's point of view, it can make tracking the
    changes easier and more efficient; so that during each release
    cycle, there is some kind of documentation for him about what has
    been changed and in what level.
 2.  From the testers' point of view, it is beneficial because they can
    test those bugs and make sure the commits have really fixed the issues.
 3. And last but not least, everyone else who is interested can follow
    the changes from one release to another; getting a clear insight on
    the releases content and changelogs. *[3]*

However, for the open-source parts, the commits in the changelog are not 
followed by any bug numbers. this means for the release manager,testers, 
or anyone else interested to track the changes on the open, there are 
not any specific documentation (i.e. bug numbers) addressing them. 
Therefore, in order to track the changes in the open, one needs to do it 
manually, which is both time consuming and not beneficial. On the other 
hand, not offering a proper system to our community has also made it 
harder for you to contribute to Jolla's software development process. *[4]*

Jolla is always seeking the support and contribution from its community. 
We've already had 10 software releases, and had your words of support 
through all the ups and downs since day one. Having our community's 
continuous trust gave us the courage to be able to row in this stormy 
sea, and deliver a part of what we'd promised. Although Jolla couldn't 
make all the infrastructures ready for a better contribution from the 
beginning, we continued to back each other up; It has never been Jolla's 
sailors alone, but Jolla's sailors with its community. These all moved 
us forward, and now that we've put our feet on the ground, we are ready 
to deliver a new part of '_our_ words of support since day one' to you. 
We have implemented a suitable system to ease the ways for our dearest 
community's contribution.

As we talked about changelogs, Jolla's internal developers provide at 
least one bug number (the bug is created on Jolla Bugzilla) in their 
commit messages. This bug number helps our bot to link what issue each 
commit contributes to. Then the bot will update the bug automatically in 
each level of the release cycle; from the development level, to testing 
and release levels. These automatic updates show detailed information 
about 'who changed what'. *[5]*

The reasons Jolla uses a bot to do the tracking 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 clear for everyone to see what is
    changed, when it's changed, and who changed it.

So, as the intro mentioned, as one of Mer's vendors, Jolla would like to 
ask the Mer package maintainers and the Mer community to please adopt a 
policy of requiring bug numbers in some commits to Mer packages for 
supporting 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 
provide that bug number (e.g. MER#12345) in the commit message they push 
to git. This will benefit both sides, as:

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

To keep a community successful, unified and going, participants need to 
have shared goals, and respect the cultural values. In Jolla, as one of 
our main values, we respect communication, advancements, challenge and 
invention. We want to move forward by having the transparency in what we 
do, and showing our passion in what you do. We would like to work with 
you as openly as possible. With your ideas, passion and creativity 
combined, we believe we can take another big step in our journey. The 
infrastructure is alive and kicking; you contribute, and we take care of 
the rest.

Please read our FAQ 
<https://wiki.merproject.org/wiki/FAQ#Vendor_.27Jolla.27_Frequently_Asked_Questions> 
and check Mer-wiki 
<https://wiki.merproject.org/wiki/Vendor/Release_Structure#Vendor:_Jolla> for 
more detailed info, and don't hesitate to contact us in case of any 
questions :-)

Best regards,
Nazanin (On behalf of the Jolla team)

[1] Existing open packages include some on Mer side such as mer-core, 
mer-tools, hybris-hal <https://github.com/mer-hybris> common stuff, 
essentially HADK; some on SailfishOS open bits 
<https://github.com/sailfishos> , and nemo:mw (Nemo Middleware)

[2] Some of the bug references currently showing up in the changelog are 
internal bugs of _public_ things which need to move to the open.

[3] These changelogs are available on the Jolla phone by running 'rpm -q 
--changelog package_name' in terminal.

[4] Read about Jolla's Release Process: 
https://wiki.merproject.org/wiki/Vendor/Release_Structure#Vendor:_Jolla

[5] Read about bug life cycle in Jolla Bugzilla during release 
integration: 
https://wiki.merproject.org/wiki/Vendor/Release_Structure#The_bug_life_cycle_in_Jolla_bugzilla_during_the_release_process

[6] Read about how Mer bugs get synced on Jolla Bugzilla: 
https://wiki.merproject.org/wiki/FAQ#Vendor_.27Jolla.27_Frequently_Asked_Questions































-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20150127/a58bed8f/attachment.html>


More information about the Devel mailing list