<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-forward-container">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<b>Summary:</b> 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.<br>
<br>
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. <br>
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.<br>
<br>
<b>How Jolla tracks the work required for a release</b><br>
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 <b>[1]</b>
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. <b>[2]</b><br>
<br>
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. <br>
Having this bug number in the changelog for the closed-source part
has had several advantages:<br>
<ol>
<li>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.</li>
<li>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.</li>
<li>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. <b>[3]</b>
</li>
</ol>
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. <b>[4]</b><br>
<br>
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 '<u>our</u> words of support since
day one' to you. We have implemented a suitable system to ease the
ways for our dearest community's contribution.<br>
<br>
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'. <b>[5]</b><br>
<br>
The reasons Jolla uses a bot to do the tracking are:<br>
<ul>
<li>Lots of developer's time can be saved to do other important
stuff instead of checking a bug constantly and updating its
status manually.</li>
<li>The CI-bot message makes it clear for everyone to see what
is changed, when it's changed, and who changed it.</li>
</ul>
<p>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.<br>
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:<br>
</p>
<ol>
<li>Mer can provide the same kind of automation and tracking.</li>
<li>Jolla can cut down the manual effort required for tracking
the changes in the open parts. <b>[6]</b></li>
<li>Jolla can move planning of open components to Mer Bugzilla.</li>
</ol>
<p>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.<br>
</p>
<p>Please read our <a
href="https://wiki.merproject.org/wiki/FAQ#Vendor_.27Jolla.27_Frequently_Asked_Questions"
moz-do-not-send="true">FAQ</a> and check <a
moz-do-not-send="true"
href="https://wiki.merproject.org/wiki/Vendor/Release_Structure#Vendor:_Jolla">Mer-wiki</a>
for more detailed info, and don't hesitate to contact us in case
of any questions :-)<br>
</p>
<p>Best regards,<br>
Nazanin (On behalf of the Jolla team)<br>
<br>
</p>
<p>[1] Existing open packages include some on Mer side such as
mer-core, mer-tools, <a moz-do-not-send="true"
href="https://github.com/mer-hybris">hybris-hal</a> common
stuff, essentially HADK; some on <a moz-do-not-send="true"
href="https://github.com/sailfishos">SailfishOS open bits</a>
, and nemo:mw (Nemo Middleware)<br>
</p>
<p>[2] Some of the bug references currently showing up in the
changelog are internal bugs of <u>public</u> things which need
to move to the open.<br>
</p>
<p>[3] These changelogs are available on the Jolla phone by
running 'rpm -q --changelog package_name' in terminal.<br>
</p>
<p>[4] Read about Jolla's Release Process: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://wiki.merproject.org/wiki/Vendor/Release_Structure#Vendor:_Jolla">https://wiki.merproject.org/wiki/Vendor/Release_Structure#Vendor:_Jolla</a><br>
</p>
<p>[5] Read about bug life cycle in Jolla Bugzilla during release
integration:
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://wiki.merproject.org/wiki/Vendor/Release_Structure#The_bug_life_cycle_in_Jolla_bugzilla_during_the_release_process">https://wiki.merproject.org/wiki/Vendor/Release_Structure#The_bug_life_cycle_in_Jolla_bugzilla_during_the_release_process</a><br>
</p>
<p>[6] Read about how Mer bugs get synced on Jolla Bugzilla:
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://wiki.merproject.org/wiki/FAQ#Vendor_.27Jolla.27_Frequently_Asked_Questions">https://wiki.merproject.org/wiki/FAQ#Vendor_.27Jolla.27_Frequently_Asked_Questions</a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
<br>
</body>
</html>