Mailinglist Archive: opensuse-factory (443 mails)

< Previous Next >
[opensuse-factory] Creating better user focused change info for Tumbleweed was please someone help with SR#711379

On 30/06/2019 22:50, Stefan Seyfried wrote:
Am 30.06.19 um 09:30 schrieb Simon Lees:

Maybe for packages I work on all the time, but when i'm not it'd still
be far quicker and easier for me to pull it out of the changelog on the
web ui,

The "Changelog in the web ui" shows the commit message.
I personally would be much less opposed putting lots of patchnames into
the commit message, but commit messages are not enforced *at all*.

Then your workflow would be

git-osc log => /patchname
git-osc show $VERSION_HASH

and you would immediately see where and when the patch was removed by
whom, including all context.

In case of a patch added it would just be

git-osc blame foo.spec => /patchname
git-osc show $VERSION_HASH

This would be the place they belong to: someone doing maintenance work
can look for them, search them (hopefully), and normal users can still
get clean package changelogs (in the .changes file).

Some of this comes back to a question of who should .changes files be aimed at and I guess more broadly if we had a good vcs do we actually need manually generated changelogs, with the right vcs these days we could almost just ship a URL + revision.

In the context of SLE / Leap updates currently the changelog is not the best place for end users to read about changes because the maintenance team takes the changes entry and converts it into a _patchinfo, which partly involves taking the .changes entry and making it more readable for end users, this info is then presented nicely in tools like the yast updater.

I think the big issue here is that since the invention of tumbleweed .changes files have to cater for both users and developers so you trying to write a neat tidy changelog for users to read which minimizes the importants of specific patches which I as a developer maybe interested in. Perhaps instead we should be looking at creating a different system for developers to put the information that's important to users like we currently have for _patchinfo files and generate a .changes / obs history entry from that and other info automatically.

Potentially the hardest thing here is lining up patch filenames with bugzilla / CVE entries, because generally the main reason I'd continue to currently look in a changes file is because generally you can see which patch in a change corresponds to which bug, it's very common to take patches directly from upstream git repo's and as such they won't contain the openSUSE specific bug number, currently the most reliable way to find this info is by looking at the .changes file which should list the patch name and bug number in the same line. This is something that needs to be done by the packager but isn't info that is useful for end users. Sometimes its easy to guess because some packagers put the CVE or bug number in the patch name, or above the PatchX: line in the spec file and sometimes the patch description will contain bsc# or boo# but we have no constant rule here so its hard to automate. Maybe one solution would be for osc to prompt you to enter a bugzilla number when you add a .patch file, then the changes file could be generated from the provided "user info" and other data. Maybe it could even be dropped, but this would require "git-osc" or whatever it became being able to accurately track changes across branches and projects where needed.


Simon Lees (Simotek)

Emergency Update Team
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups