[opensuse-packaging] patch names: maybe include patch numbers?

Wouldn't it be good to have the number of the patch (as specified in the .spec file) in the names of the patches? Something like e.g.: Patch201: p201-fix-foo.patch Patch202: p202-avoid-crash-in-bar.patch Patch203: p203-improve-donald.patch Patch204: p204-add-cool-xyz-feature.patch I guess moving the patches around in the sequence is not that common, so this might help clarifying the order at the first glance. WDYT? The wiki [0] and alike are not that specific about this. [0] https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_naming Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Bernhard Voelker <mail@bernhard-voelker.de> Sun, 11 Jan 2015 15:27:18 +0300:
Wouldn't it be good to have the number of the patch (as specified in the .spec file) in the names of the patches? Something like e.g.:
Patch201: p201-fix-foo.patch Patch202: p202-avoid-crash-in-bar.patch Patch203: p203-improve-donald.patch Patch204: p204-add-cool-xyz-feature.patch
I guess moving the patches around in the sequence is not that common, so this might help clarifying the order at the first glance. WDYT?
The wiki [0] and alike are not that specific about this.
[0] https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_naming
Have a nice day, Berny
+1 for this. It is really hard to work with projects with lots of patches now =( -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sunday 2015-01-11 13:27, Bernhard Voelker wrote:
Wouldn't it be good to have the number of the patch (as specified in the .spec file) in the names of the patches? Something like e.g.:
Patch201: p201-fix-foo.patch Patch202: p202-avoid-crash-in-bar.patch Patch203: p203-improve-donald.patch Patch204: p204-add-cool-xyz-feature.patch
If you have a lot of patches, it might "help", but,...
I guess moving the patches around in the sequence is not that common
It happens (like, when inserting a patch between 1 and 2). And when it does, it will be a mess renaming all the 204 patches. Not to mention the factory-auto/factory-repo-checker bot which will nag you about every "new" and "removed" patch not being mentioned in .changes. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/11/2015 01:41 PM, Jan Engelhardt wrote:
On Sunday 2015-01-11 13:27, Bernhard Voelker wrote:
I guess moving the patches around in the sequence is not that common
It happens (like, when inserting a patch between 1 and 2). And when it does, it will be a mess renaming all the 204 patches.
Hmm, I don't think this would happen too often (here) - usually I'm leaving much space between the numbers, e.g. reserving 1xx and 2xx for upstream patches, 3xx - 4xx for openSUSE-specific adaptions, 5xx.. for downstream bugfixes, etc. There's no strict rule, but just to give you an idea. The {201..204} example was from a series of upstream patches to be included where the order won't change.
Not to mention the factory-auto/factory-repo-checker bot which will nag you about every "new" and "removed" patch not being mentioned in .changes.
When renaming patches - wouldn't one mention this in .changes? I would ... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Sun, 11 Jan 2015 14:00:37 +0100 Bernhard Voelker <mail@bernhard-voelker.de> пишет:
On 01/11/2015 01:41 PM, Jan Engelhardt wrote:
On Sunday 2015-01-11 13:27, Bernhard Voelker wrote:
I guess moving the patches around in the sequence is not that common
It happens (like, when inserting a patch between 1 and 2). And when it does, it will be a mess renaming all the 204 patches.
Hmm, I don't think this would happen too often (here) - usually I'm leaving much space between the numbers, e.g. reserving 1xx and 2xx for upstream patches, 3xx - 4xx for openSUSE-specific adaptions, 5xx.. for downstream bugfixes, etc. There's no strict rule, but just to give you an idea. The {201..204} example was from a series of upstream patches to be included where the order won't change.
Not to mention the factory-auto/factory-repo-checker bot which will nag you about every "new" and "removed" patch not being mentioned in .changes.
When renaming patches - wouldn't one mention this in .changes?
For each of 200+ patches forced to be renamed for pure technical reason? Note that when using GIT to maintain patches you usually get numbering for free when generating patches.
I would ...
Have a nice day, Berny
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/11/2015 02:04 PM, Andrei Borzenkov wrote:
For each of 200+ patches forced to be renamed for pure technical reason?
no, there are just a few, like 1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303, 400, 401, 416, 500, 501, 502, 503
Note that when using GIT to maintain patches you usually get numbering for free when generating patches.
ah, yes, cool - moving to GIT as source service is still on my list .... Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sunday 2015-01-11 14:12, Bernhard Voelker wrote:
On 01/11/2015 02:04 PM, Andrei Borzenkov wrote:
For each of 200+ patches forced to be renamed for pure technical reason?
no, there are just a few, like 1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303, 400, 401, 416, 500, 501, 502, 503
Glad you don't have to work with the openSUSE systemd package. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, On Jan 11 14:17 Jan Engelhardt wrote (excerpt):
On Sunday 2015-01-11 14:12, Bernhard Voelker wrote:
no, there are just a few, like 1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303, 400, 401, 416, 500, 501, 502, 503
Bernhard Voelker, can you explain the reason behind why it would be good to have the number of the patch in its name? I use the same basic idea as you with separated number blocks and I also have only a few small patches in my packages. If a set of patches belongs to each other I would rather prefix them with a meaningful word instead of a technical number like fix-GUI-this.patch fix-GUI-that.patch enhance-documentation-foo.patch enhance-documentation-bar.patch Ideally if several patches belong to each other they should be provided in on single patch file like fix-GUI-this_and_that.patch enhance-documentation-foo_and_bar.patch But this are only my personal suggestions because I think: With only a few small patches it is easy to work in any case. Both "few" plus "small" is essential. (My first package that I mercilessly cleaned up had basically only one single patch that was a huge huddle of anything.)
Glad you don't have to work with the openSUSE systemd package.
Good grief! ------------------------------------------------------------------ $ osc list openSUSE:Factory systemd | grep '\.patch$' | wc -l 533 ------------------------------------------------------------------ I think overcomplicated packages with tons of patches are a nightmare to maintain and I think no volunteer would like do this so that overcomplicated packages could be a main reason why there are not more volunteers who contribute to openSUSE which could be a main handicap for the whole openSUSE project. Cf. https://bugzilla.opensuse.org/show_bug.cgi?id=735824#c36 Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Monday 2015-01-12 10:33, Johannes Meixner wrote:
Glad you don't have to work with the openSUSE systemd package.
Good grief! ------------------------------------------------------------------ $ osc list openSUSE:Factory systemd | grep '\.patch$' | wc -l 533 ------------------------------------------------------------------
I think overcomplicated packages with tons of patches are a nightmare to maintain and I think no volunteer would like do this
No volunteer? Bit the bullet just yesterday. https://plus.google.com/109464953059773945656/posts/H2uTDyVE8Da -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Mon, 12 Jan 2015 10:33, Johannes Meixner <jsmeix@...> wrote:
On Jan 11 14:17 Jan Engelhardt wrote (excerpt):
On Sunday 2015-01-11 14:12, Bernhard Voelker wrote:
no, there are just a few, like 1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303, 400, 401, 416, 500, 501, 502, 503
Bernhard Voelker, can you explain the reason behind why it would be good to have the number of the patch in its name?
I use the same basic idea as you with separated number blocks and I also have only a few small patches in my packages.
If a set of patches belongs to each other I would rather prefix them with a meaningful word instead of a technical number like fix-GUI-this.patch fix-GUI-that.patch enhance-documentation-foo.patch enhance-documentation-bar.patch
Ideally if several patches belong to each other they should be provided in on single patch file like fix-GUI-this_and_that.patch enhance-documentation-foo_and_bar.patch
But this are only my personal suggestions because I think:
With only a few small patches it is easy to work in any case.
Both "few" plus "small" is essential. (My first package that I mercilessly cleaned up had basically only one single patch that was a huge huddle of anything.)
I'm maintaining some 'private' packages for a business, and not all of them are well maintained from upstream. So, the patches pile up until the next offical release, where most, but not all patches are integrated again. In my case that list reads some thing like this: [code] # 'upstream' patches < 1000 0001-4.6.12.001-fix-CVE_xxxx.patch ... 0801-4.6.12.803-fix-config-defaults-TLS.patch # 'os-release' patches 1001-1999 1001-4.6.x-use-libpng16-for-OSS13.patch ... 1801-4.6.x-disable-SSL2-SSL3-for-sure.patch # 'private' patches > 2000 2001-disable-user-config.patch ... 2801-config-aftermatch-of-disable-SSL.patch [/code] For me, the biggest plus of numbering patches, is to make it obvious in which order they have to be applied to work. It makes sense to seperate 'upstream issues' e.g. backported bug-fixes that are upstream in the next version, but we stay on this version, and 'os-release issues' e.g. we want to add a extra plugin-dir, or change a config-default to a other value. It's about makeing like easier for the packager, at just a glance (s)he can see where a new patch/bug-fix has to be put in. And it reduces the chance of misordering patches and getting undesireable results. These are my 2ct. YMMV. - Yamaban. -- "Real life? There is a 'Real life' out there?" -- after a 36 hour bughunt. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Mon, Jan 12, 2015 at 01:55:11PM +0100, Yamaban wrote:
On Mon, 12 Jan 2015 10:33, Johannes Meixner <jsmeix@...> wrote:
On Jan 11 14:17 Jan Engelhardt wrote (excerpt):
On Sunday 2015-01-11 14:12, Bernhard Voelker wrote:
no, there are just a few, like 1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303, 400, 401, 416, 500, 501, 502, 503
Bernhard Voelker, can you explain the reason behind why it would be good to have the number of the patch in its name?
I use the same basic idea as you with separated number blocks and I also have only a few small patches in my packages.
If a set of patches belongs to each other I would rather prefix them with a meaningful word instead of a technical number like fix-GUI-this.patch fix-GUI-that.patch enhance-documentation-foo.patch enhance-documentation-bar.patch
Ideally if several patches belong to each other they should be provided in on single patch file like fix-GUI-this_and_that.patch enhance-documentation-foo_and_bar.patch
But this are only my personal suggestions because I think:
With only a few small patches it is easy to work in any case.
Both "few" plus "small" is essential. (My first package that I mercilessly cleaned up had basically only one single patch that was a huge huddle of anything.)
I'm maintaining some 'private' packages for a business, and not all of them are well maintained from upstream.
So, the patches pile up until the next offical release, where most, but not all patches are integrated again.
In my case that list reads some thing like this: [code] # 'upstream' patches < 1000 0001-4.6.12.001-fix-CVE_xxxx.patch ... 0801-4.6.12.803-fix-config-defaults-TLS.patch
# 'os-release' patches 1001-1999 1001-4.6.x-use-libpng16-for-OSS13.patch ... 1801-4.6.x-disable-SSL2-SSL3-for-sure.patch
# 'private' patches > 2000 2001-disable-user-config.patch ... 2801-config-aftermatch-of-disable-SSL.patch [/code]
For me, the biggest plus of numbering patches, is to make it obvious in which order they have to be applied to work.
It makes sense to seperate 'upstream issues' e.g. backported bug-fixes that are upstream in the next version, but we stay on this version, and 'os-release issues' e.g. we want to add a extra plugin-dir, or change a config-default to a other value.
It's about makeing like easier for the packager, at just a glance (s)he can see where a new patch/bug-fix has to be put in. And it reduces the chance of misordering patches and getting undesireable results.
These are my 2ct. YMMV.
Larger projects use a "series" file though to keep track of the order, like our kernel. Then there is no need for this kind of numbering. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Marcus Meissner <meissner@suse.de> [2015-01-12 14:00]:
On Mon, Jan 12, 2015 at 01:55:11PM +0100, Yamaban wrote:
On Mon, 12 Jan 2015 10:33, Johannes Meixner <jsmeix@...> wrote:
On Jan 11 14:17 Jan Engelhardt wrote (excerpt):
On Sunday 2015-01-11 14:12, Bernhard Voelker wrote:
no, there are just a few, like 1, 3, 4, 5, 8, 16, 100, 111, 112, 113, 300, 301, 303, 400, 401, 416, 500, 501, 502, 503
Bernhard Voelker, can you explain the reason behind why it would be good to have the number of the patch in its name?
I use the same basic idea as you with separated number blocks and I also have only a few small patches in my packages.
If a set of patches belongs to each other I would rather prefix them with a meaningful word instead of a technical number like fix-GUI-this.patch fix-GUI-that.patch enhance-documentation-foo.patch enhance-documentation-bar.patch
Ideally if several patches belong to each other they should be provided in on single patch file like fix-GUI-this_and_that.patch enhance-documentation-foo_and_bar.patch
But this are only my personal suggestions because I think:
With only a few small patches it is easy to work in any case.
Both "few" plus "small" is essential. (My first package that I mercilessly cleaned up had basically only one single patch that was a huge huddle of anything.)
I'm maintaining some 'private' packages for a business, and not all of them are well maintained from upstream.
So, the patches pile up until the next offical release, where most, but not all patches are integrated again.
In my case that list reads some thing like this: [code] # 'upstream' patches < 1000 0001-4.6.12.001-fix-CVE_xxxx.patch ... 0801-4.6.12.803-fix-config-defaults-TLS.patch
# 'os-release' patches 1001-1999 1001-4.6.x-use-libpng16-for-OSS13.patch ... 1801-4.6.x-disable-SSL2-SSL3-for-sure.patch
# 'private' patches > 2000 2001-disable-user-config.patch ... 2801-config-aftermatch-of-disable-SSL.patch [/code]
For me, the biggest plus of numbering patches, is to make it obvious in which order they have to be applied to work.
It makes sense to seperate 'upstream issues' e.g. backported bug-fixes that are upstream in the next version, but we stay on this version, and 'os-release issues' e.g. we want to add a extra plugin-dir, or change a config-default to a other value.
It's about makeing like easier for the packager, at just a glance (s)he can see where a new patch/bug-fix has to be put in. And it reduces the chance of misordering patches and getting undesireable results.
These are my 2ct. YMMV.
Larger projects use a "series" file though to keep track of the order, like our kernel. Then there is no need for this kind of numbering.
And for all other packages one can use quilt: https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Using_quilt -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/12/2015 10:33 AM, Johannes Meixner wrote:
can you explain the reason behind why it would be good to have the number of the patch in its name?
basically it's the same as what Yamabam wrote: to know the order of the patches at first glance, After reading all your comments, I think I maybe just should go with some prefixes like "upstream-" or "downstream-" which also gives a rough idea about the categorization. After all, it was just an idea, and I wanted to know whether others are using something like such patch numbering names. The most useful pointer was maybe to switch to GIT for the patch management. My problem hereby is that it's not a big deal to switch to it right now, but rather how to get the whole history of the revisions from OBS into GIT. How did others do the switch? Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Bernhard Voelker <mail@bernhard-voelker.de> [2015-01-12 17:19]:
On 01/12/2015 10:33 AM, Johannes Meixner wrote:
can you explain the reason behind why it would be good to have the number of the patch in its name?
basically it's the same as what Yamabam wrote: to know the order of the patches at first glance,
After reading all your comments, I think I maybe just should go with some prefixes like "upstream-" or "downstream-" which also gives a rough idea about the categorization.
We already have patch tags for such meta information (although unfortunately not all packages use them) and applying or removing or inserting patches while maintaining the right order can be easily achieved with quilt. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, On Jan 12 17:18 Bernhard Voelker wrote (excerpt):
On 01/12/2015 10:33 AM, Johannes Meixner wrote:
can you explain the reason behind why it would be good to have the number of the patch in its name?
basically it's the same as what Yamabam wrote: to know the order of the patches at first glance,
The "at first glance" is determining here. Because you need it "at first glance", you would have the applying-order also in the patch names. In contrast for me it is sufficient to have the applying-order only in the .spec file in particular because I prefer to be safe against artificial patch renaming when the applying-order needs to be changed - but this is only my personal preference.
After reading all your comments, I think I maybe just should go with some prefixes like "upstream-" or "downstream-" which also gives a rough idea about the categorization.
After all, it was just an idea, and I wanted to know whether others are using something like such patch numbering names.
I think the most important thing is to keep packages in an easy-maintainable state which means having only few small patches and then I think we do not need a strict advice (a.k.a. "policy") how each individual package maintainer must name the patches. What matters is that each individual package maintainer makes it obvious to others what is going on in his packages.
The most useful pointer was maybe to switch to GIT for the patch management.
I think for packages in an easy-maintainable state any kind of "patch management" seems to be overkill and contradicts the KISS principle (cf. U.S. Navy "Project KISS" of 1960). Instead it overcomplicates things according to RFC1925: "It is always possible to add another level of indirection." I mean: When a package really requires patch management it is likely that the package is messed up and then patch management does not solve the real issue (as always there are some justified exceptions). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Andrei Borzenkov
-
Bernhard Voelker
-
Dmitriy Perlow
-
Guido Berhoerster
-
Jan Engelhardt
-
Johannes Meixner
-
Marcus Meissner
-
Yamaban