On 03/07/2019 04:13, Christian Boltz wrote:
Hello,
Am Dienstag, 2. Juli 2019, 10:34:15 CEST schrieb Richard Brown:
Simon is talking about the fact that in addition to the patch itself, the motivation for the patch (such as the CVE#/BOO#/BSC# etc) needs to be tracked also. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_ma rkup_.28also_called_.22Tagging_patches.22.29
And as smart as any automated tool could be, I'm pretty sure it's not going to be able to read the mind of the contributors to know which bug/security ID was the motivation for adding a patch.
That's not a reason to force packagers to do everything manually ;-)
Nobody said that the changelog should be written completely automatically (would be perfect, but I'm afraid AI didn't go that far yet).
Nevertheless, "osc vc" could pre-populate the changelog with added, removed and changed patches (saving the packager copy&paste from "osc status"), like it already pre-populates the line with the packager's mail address and the timestamp.
"osc vc" could generate something like this:
------------------------------------------------------------------- Tue Jul 2 18:34:03 UTC 2019 - Pack Ager <packager@example.com>
-
- added fix-foo patch - removed whatever.patch - updated another.patch
-------------------------------------------------------------------
The packager can/should then still edit these lines, for example move the patch names to related hand-written comments and/or add bug and CVE references.
(In theory, a packager can also edit the autogenerated line with the mail address and timestamp, for example if nobody should see that you package after midnight ;-)
Its in UTC anyway, its pretty common for me to be editing packages at midnight yesterday according to the changelog :-), I do like this idea as a short term solution (I like the idea in the other thread more as a long term solution and that one actually resolves the issue in the original post)
Automatically handling the removal of the patch should be relatively easier though - assuming the ID is already present the tooling could actually look up the Bug ID and confirm whether or not the bug is closed before allowing the removal of the patch from the specfile - and that could be a nice improvement that'll stop tons of fixed bugs being left open when maintainers forget to close them ;)
I'd hope that _adding_ (not removing) a patch is meant to fix a bug ;-)
Unfortunately your hopes do not always meet with reality -- 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