https://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842017-01-18T07:06:53ZopenSUSE Project Management ToolopenQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=365582017-01-18T07:06:53Zokurzokurz@suse.com
<ul><li><strong>Assignee</strong> set to <i>szarate</i></li></ul><p>fancy working on it?</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=366522017-01-18T11:30:21Zmkittlermarius.kittler@suse.com
<ul></ul><p>Oh, I see there is already a ticket for it and szarate is already working on this.</p>
<p>On package generation a log file is already updated: <a href="https://build.opensuse.org/package/view_file/devel:openQA/openQA/openQA.changes" class="external">https://build.opensuse.org/package/view_file/devel:openQA/openQA/openQA.changes</a></p>
<p>So we just need to make it available to the web UI and then just display it from there.</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=366562017-01-18T11:35:13Zcoolocoolo@suse.com
<ul></ul><p>you can copy the .changes file into public/Changelog during package build. Then it's available to apache as openqa.opensuse.org/Changelog</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=366702017-01-18T11:52:38Zszarate
<ul></ul><p>While talking with <a class="user active user-mention" href="https://progress.opensuse.org/users/22072">@mkittler</a>, there's the idea to have the changelog as part of a new "Info" menu for the web UI (And there we can link the API documentation, openQA documentation itself and other stuff). Also the worker (os-autoinst) changelog needs to be added too.</p>
<p><a class="user active user-mention" href="https://progress.opensuse.org/users/22072">@mkittler</a>, the idea proposed by <a class="user active user-mention" href="https://progress.opensuse.org/users/15">@coolo</a> actually will remove the branding problem, we can use the same approach for both, the webui and os-autoinst (placing the file in say /usr/doc/os-autoinst/Changelog)</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=366722017-01-18T12:18:39Zmkittlermarius.kittler@suse.com
<ul></ul><p>Ok, so let's package the logs decently then.</p>
<p>Anyways here's a first approach reading the logs just via <code>rpm</code> command: <a href="https://github.com/os-autoinst/openQA/pull/1184" class="external">https://github.com/os-autoinst/openQA/pull/1184</a></p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=366922017-01-18T16:05:08Zokurzokurz@suse.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/36692/diff?detail_id=36858">diff</a>)</li></ul><p>problems I see with the proposed approach:</p>
<ul>
<li>changelog from RPM may no be complete, e.g. when OBS fails to build a package for some time</li>
<li>It is specific to OBS</li>
<li>new menu is too much. You are probably over-estimating the capabilities of users to filter stuff on a webui</li>
<li>os-autoinst should be considered "just any backend" and not be relied upon from the webui perspective</li>
<li>automatically generated changelog is too verbose for the user to digest directly. changelogs need a manual review process</li>
</ul>
<p>I suggest the following for anyone who is up to the task to do:</p>
<ul>
<li>on a bi-weekly basis looks for the last git commit of openQA that is not totally broken</li>
<li><code>git log --format=oneline <last_tag>..<the_one_commit_that_should_become_the_new_version> > changelog</code></li>
<li>filter out un-interesting stuff from the changelog, e.g. low-level internal refactoring and fixes for issues that never hit users</li>
<li>create tag with message details including the changelog and with an increasing version number, e.g. 4.5, 4.6, …, 4.99, …, 4.165</li>
<li>put that as "release" on the github project</li>
<li>make OBS package <code>devel:openQA:stable/openQA</code> automatically be triggered by new releases on github with the according version and changelog</li>
<li>do the same for os-autoinst</li>
<li>every 6w (that would be for each "milestone", covering three releases) collect changelog from all 6 releases (3 openQA + 3 os-autoinst) the interesting parts on an even higher level, blog about it and brag about it</li>
</ul>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=367022017-01-18T16:47:46Zszarate
<ul><li><strong>Target version</strong> set to <i>Milestone 7</i></li></ul><p><a class="user active user-mention" href="https://progress.opensuse.org/users/17668">@okurz</a>, can you please update the description on what's expected from the Test Developer (And other perspectives) regarding this feature?. As we clearly got to a point with different opinions regarding what a Changelog and a Release note is, and what to have where. </p>
<p>What you are suggesting in your last comment, is to have a proper release process for openQA (and as you mention os-autoinst, is a different project, that would need it's own release process), but IMHO differs a lot with the the user story itself and <u>the further details</u> these are two things again: openQA version and os-autoinst version, Changelog and release notes :)</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=367082017-01-18T18:56:20Zcoolocoolo@suse.com
<ul></ul><p>If OBS fails to build the package, we won't deploy it. I thought this is about having the changelog of deployment?</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=367402017-01-19T08:41:01Zszarate
<ul></ul><p>The discussion scaled quickly :), and it was not just deployment... Its a bit more complicated :) </p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=372682017-01-25T10:09:39Zszarate
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-3 priority-3 priority-lowest closed" href="/issues/16232">action #16232</a>: Display openQA version in web UI</i> added</li></ul> openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=377782017-01-31T22:50:32Zokurzokurz@suse.com
<ul><li><strong>Subject</strong> changed from <i>Better changelog and/or release notes for openQA releases</i> to <i>Better user information about openQA changes</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/37778/diff?detail_id=37796">diff</a>)</li></ul> openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=377802017-01-31T23:02:29Zokurzokurz@suse.com
<ul></ul><p>szarate wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://progress.opensuse.org/users/17668">@okurz</a>, can you please update the description on what's expected from the Test Developer (And other perspectives) regarding this feature?. As we clearly got to a point with different opinions regarding what a Changelog and a Release note is, and what to have where. </p>
<p>What you are suggesting in your last comment, is to have a proper release process for openQA (and as you mention os-autoinst, is a different project, that would need it's own release process), but IMHO differs a lot with the the user story itself and <u>the further details</u> these are two things again: openQA version and os-autoinst version, Changelog and release notes :)</p>
</blockquote>
<p>I split this ticket which I now consider a user epic into three parts, this epic and two user stories as subtickets. Please take a look if this is better now.</p>
openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=437942017-03-14T11:05:51ZRBrownSUSErbrown@suse.com
<ul><li><strong>Subject</strong> changed from <i>Better user information about openQA changes</i> to <i>[tools]Better user information about openQA changes</i></li></ul> openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=479382017-04-19T15:38:09ZRBrownSUSErbrown@suse.com
<ul><li><strong>Target version</strong> deleted (<del><i>Milestone 7</i></del>)</li></ul> openQA Project - action #16062: [tools]Better user information about openQA changeshttps://progress.opensuse.org/issues/16062?journal_id=1049292018-03-23T10:18:59Zcoolocoolo@suse.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li></ul><p>we have changelog in the webui and announce sprints</p>