I don't know who wrote that comment, but actually the one-line comment in the spec is much better. The comment in the patch file means that you have to open each file to check the state. The comment in the spec shows on first view what to do with the patch (i.e. UPSTREAM patches should be checked for removal on updates, SUSE patches need to be adapted instead). The comment in the patch allows a more detailed description thought (i.e. some patches contain the upstream submission mail text). In such cases I'd make a short one-liner and the longer comment in the patch.
Also the one-liners make web-based review much easier.
As for supersede: You're the maintainer - it's your decision.
P.S. If possibly also add a patch tagging for the other patches ;-)
Patches should be tagged #PATCH-FIS-UPSTREAM , #PATCH-fiX-OPENSUSE with a comment. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Type_1:_minimal_single-line_comment_in_spec_file
Thanks for the comment.
My understanding of
https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Type_2:_Complete_Information_provided_in_patch
is, that providing the info in the patch file is prefered.
Should i revoke/supersede this request?
I don't know who wrote that comment, but actually the one-line comment in the spec is much better. The comment in the patch file means that you have to open each file to check the state. The comment in the spec shows on first view what to do with the patch (i.e. UPSTREAM patches should be checked for removal on updates, SUSE patches need to be adapted instead). The comment in the patch allows a more detailed description thought (i.e. some patches contain the upstream submission mail text). In such cases I'd make a short one-liner and the longer comment in the patch.
Also the one-liners make web-based review much easier.
As for supersede: You're the maintainer - it's your decision.
P.S. If possibly also add a patch tagging for the other patches ;-)
Changed the Wiki a bit ;-)
Was nicht passt, wir passend gemacht ;)
Thanks for the explanation!
I'll add one-liners to the spec with next submit request. But for this time, if it is me to decide about the accept, i'll take this as is.