*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
