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) http://simotek.net Emergency Update Team keybase.io/simotek 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org