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

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

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 Mon, 12 Jan 2015 10:33, Johannes Meixner 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

* Marcus Meissner [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 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

* Bernhard Voelker [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