On 22/06/2019 18:33, Stefan Seyfried wrote:
Am 22.06.19 um 10:46 schrieb Simon Lees:
Yeah if I need to go back in 3 years and work out the lifespan of a patch, its far easier to just search the changelog for all instances of the patch, Its something I have to do on occasion with packages i'm not necessarily the maintainer of and rules like this make it much easier.
Look at the specific case here.
All "custom" patches named something like vdr-${version_introduced}-${purpose_of_patch}.patch
All upstream patches named vdr-${curr_ver}-${%02d,count}-${purpose}.patch
It is quite easy, even years later, to see what "removed integrated upstream patches vdr-${cur_ver}-01..42" is supposed to describe.
A valid criticism would have been to ask "can you distinguish your custom patches better, by renaming them?", something I'll do in the future whenever I have to touch one of these patches.
No my criticism of what you'd like to do is intentional, as someone who spends a lot of time looking at small things across many many packages I appreciate the fact that there are certain rules all packages follow to make them the same, one such rule is if I am dealing with a large changes file I can put a patches filename into the search field of my editor and find when the patch was added / removed, I don't want to have to skim 5000 lines of a changes file manually to find vdr-${cur_ver}-01..42"vdr-${cur_ver}-01..42" even if yes having 40 patches listed in a changes file doesn't look as "pretty" changes files should be about function over prettyness. But I guess we are going to have to agree to disagree, although if as others have said more people agree with you then me the rule could be changed. But don't dismiss the way it is now and not allowing exceptions as completely illogical there is at least a small amount of logic behind it. -- 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