QA (public) » openQA Project (public)

user story¶

As a conservative user I want stable versions of openQA so that I am not scared away of using openQA by occasional critical issues in the "devel:openQA" version

acceptance criteria¶

• AC1: A documented workflow exists, e.g. wiki, e.g. based on "suggested workflow" below
• AC2: Maintainer have been found
• AC3: An OBS project exists with stable versions with openQA documentation references

tasks¶

• ask openQA team if we really need this
• talk to aaannz and coolo how it has been done previously with 'devel:openQA:stable' and adopt
• optional: helper scripts for the workflow
• optional: Also adopt the workflow for submissions to openSUSE:Factory and maybe Leap and SLE, too

further details¶

Suggested workflow¶

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

interesting references¶

• http://keepachangelog.com/
• https://github.com/skywinder/Github-Changelog-Generator