Project

General

Profile

Actions

action #16062

closed

[tools]Better user information about openQA changes

Added by okurz almost 8 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Organisational
Target version:
-
Start date:
2017-01-31
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)

Description

Raised as an idea during the SUSE QA SLE retrospective

user epic

As a frequent user relying on openQA I want to know what cool new features and fixes are available in a deployed openQA instance so that I know how I can conduct the review efficiently

further details

old content which okurz thinks is a feature we should not invest time on as it is an administration issue: see version of backend from (all) workers to know which backend features are expected to be working already for tests relying on it


Subtasks 2 (0 open2 closed)

action #16374: openQA stable versions with manual changelog/release notesRejectedokurz2017-01-31

Actions
action #16376: Dynamic user information about new openQA featuresResolvedkrauselukas2017-01-31

Actions

Related issues 1 (0 open1 closed)

Related to openQA Project (public) - action #16232: Display openQA version in web UIResolvedEDiGiacinto2017-01-25

Actions
Actions #1

Updated by okurz almost 8 years ago

  • Assignee set to szarate

fancy working on it?

Actions #2

Updated by mkittler almost 8 years ago

Oh, I see there is already a ticket for it and szarate is already working on this.

On package generation a log file is already updated: https://build.opensuse.org/package/view_file/devel:openQA/openQA/openQA.changes

So we just need to make it available to the web UI and then just display it from there.

Actions #3

Updated by coolo almost 8 years ago

you can copy the .changes file into public/Changelog during package build. Then it's available to apache as openqa.opensuse.org/Changelog

Actions #4

Updated by szarate almost 8 years ago

While talking with @mkittler, 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.

@mkittler, the idea proposed by @coolo 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)

Actions #5

Updated by mkittler almost 8 years ago

Ok, so let's package the logs decently then.

Anyways here's a first approach reading the logs just via rpm command: https://github.com/os-autoinst/openQA/pull/1184

Actions #6

Updated by okurz almost 8 years ago

  • Description updated (diff)

problems I see with the proposed approach:

  • changelog from RPM may no be complete, e.g. when OBS fails to build a package for some time
  • It is specific to OBS
  • new menu is too much. You are probably over-estimating the capabilities of users to filter stuff on a webui
  • os-autoinst should be considered "just any backend" and not be relied upon from the webui perspective
  • automatically generated changelog is too verbose for the user to digest directly. changelogs need a manual review process

I suggest the following for anyone who is up to the task to do:

  • on a bi-weekly basis looks for the last git commit of openQA that is not totally broken
  • git log --format=oneline <last_tag>..<the_one_commit_that_should_become_the_new_version> > changelog
  • filter out un-interesting stuff from the changelog, e.g. low-level internal refactoring and fixes for issues that never hit users
  • create tag with message details including the changelog and with an increasing version number, e.g. 4.5, 4.6, …, 4.99, …, 4.165
  • put that as "release" on the github project
  • make OBS package devel:openQA:stable/openQA automatically be triggered by new releases on github with the according version and changelog
  • do the same for os-autoinst
  • 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
Actions #7

Updated by szarate almost 8 years ago

  • Target version set to Milestone 7

@okurz, 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.

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 the further details these are two things again: openQA version and os-autoinst version, Changelog and release notes :)

Actions #8

Updated by coolo almost 8 years ago

If OBS fails to build the package, we won't deploy it. I thought this is about having the changelog of deployment?

Actions #9

Updated by szarate almost 8 years ago

The discussion scaled quickly :), and it was not just deployment... Its a bit more complicated :)

Actions #10

Updated by szarate almost 8 years ago

  • Related to action #16232: Display openQA version in web UI added
Actions #11

Updated by okurz almost 8 years ago

  • Subject changed from Better changelog and/or release notes for openQA releases to Better user information about openQA changes
  • Description updated (diff)
Actions #12

Updated by okurz almost 8 years ago

szarate wrote:

@okurz, 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.

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 the further details these are two things again: openQA version and os-autoinst version, Changelog and release notes :)

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.

Actions #13

Updated by RBrownSUSE almost 8 years ago

  • Subject changed from Better user information about openQA changes to [tools]Better user information about openQA changes
Actions #14

Updated by RBrownSUSE over 7 years ago

  • Target version deleted (Milestone 7)
Actions #15

Updated by coolo almost 7 years ago

  • Status changed from New to Resolved

we have changelog in the webui and announce sprints

Actions

Also available in: Atom PDF