<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>