On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. [...] Here's a small list of flavors that I've come across or used myself.[...] TL;DR: My recommendation would be to (at least loosely) follow pattern 5) versioning.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master. TL;DR: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013 13:22:44 +0200 Sascha Peilicke wrote:

Hi guys,

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file:

Version: 1.2.3

So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand:

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism).

TL;DR =====

My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions.

+1 for 5) as it is reasonable. Hash is important to know what version of code is used. Josef

On 09/10/2013 01:33 PM, Jan Engelhardt wrote:

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. [...] Here's a small list of flavors that I've come across or used myself.[...] TL;DR: My recommendation would be to (at least loosely) follow pattern 5) versioning.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

In these cases I fully agree. But we also have packages that come from different (stable) branches. Once you change those in Factory, you probably want to have the commit hash again. Although you could probably infer the commit from it's checking time (since it's rather unlikely that 2 commits collide), it is much more obvious to have the commit hash available. The point is to use sth. as unique as possible, sth. like "X+git20130101" could still mean 10-20 commits depending on upstream activity. Lastly, "terribly long" is a matter of taste. But if your package ends up on Joliet FS formatted media it may be an issue indeed :-)

TL;DR: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v... .

Awesome, to be honest I didn't knew this paragraph existed. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

Sascha Peilicke writes:

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

For git you can also use the output from git describe, which is also monotonically increasing. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013, Sascha Peilicke wrote:

Hi guys,

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file:

Version: 1.2.3

So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand:

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right?

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;) I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer). Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Richard Biener :

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Or wait for GCC 4.8.2 ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Richard Biener (rguenther@suse.de) wrote:

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Surely you can just wait for 4.8.2? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 14:25, Richard Biener wrote:

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

zypper dup will do it without epochs - and there is a dup coming every 8 months.. or so.

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

"Wait for gcc49" :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013, Jan Engelhardt wrote:

On Tuesday 2013-09-10 14:25, Richard Biener wrote:

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

zypper dup will do it without epochs - and there is a dup coming every 8 months.. or so.

...

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

"Wait for gcc49" :)

Yeah ;) Happens that the time / idea to implement it never is the time of a version bump ... Richard. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 09/10/2013 01:52 PM, Adam Spiers wrote:

Jan Engelhardt (jengelh@inai.de) wrote:

...

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. [...] Here's a small list of flavors that I've come across or used myself.[...] TL;DR: My recommendation would be to (at least loosely) follow pattern 5) versioning.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long

True, that is an *aesthetic* disadvantage. But does it have any significant negative impact in practical situations?

...

hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

I disagree:

1. The aim of this thread is (presumably) to establish a common standard which can be used consistently across many projects. *Plenty* of projects do *not* have linear history, therefore a standard should not make assumptions about whether it is linear or not.

2. hashes are needed even when history is linear, because then you know exactly which source revision the package came from, and in a support situation this is crucial information. In general there is no reliable way of determining this from a timestamp, because the timestamp could refer to when the git commit was made, or when tar_scm was run, or when set_version was run, or even some arbitrary value which the maintainer manually put in the .spec file.

However, like I just mentioned in my other mail to this thread, the hash could potentially be embedded in %description and omitted from %version. But I'm against this, because it makes the output of "rpm -qa" a lot less useful. Even the kernel developers include the hash in both %description and %version.

...

TL;DR: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v...

Clearly those guidelines are flawed, because as Sascha already pointed out, they result in non-chronological ordering which breaks upgrades. I think the main point of this thread is to try to fix that.

Ideally, that would be the result, yes. I'd like to have some (documented) best practices which are good to follow in all cases without much debate. Secondly, I'm a Factory reviewer and I can't recall how often I re-read the RPM version comparison algorithm because someone went creative again :-) Less deviation means faster and less error-prone reviews and thus happier packagers. We achieved setting a global standard for the License: tag (well, who argues with legal :-), having sth. similar for Version: can't hurt. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

Le mardi 10 septembre 2013 à 14:25 +0200, Richard Biener a écrit :

On Tue, 10 Sep 2013, Sascha Peilicke wrote:

...

Hi guys,

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file:

Version: 1.2.3

So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand:

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right?

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ? -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Sascha Peilicke :

Ideally, that would be the result, yes. I'd like to have some (documented) best practices which are good to follow in all cases without much debate. Secondly, I'm a Factory reviewer and I can't recall how often I re-read the RPM version comparison algorithm because someone went creative again :-) Less deviation means faster and less error-prone reviews and thus happier packagers.

Don't read code.. use "zypper vcmp". After all, zypper is our only source to truth when we talk about updates (ok, actually libzypp). Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Sascha Peilicke (speilicke@suse.com) wrote:

On 09/10/2013 02:39 PM, Andreas Schwab wrote:

...

Adam Spiers writes:

...

Please can you define "properly named"?

So they sort properly like the version.

Andreas.

I guess the "if" is important here, I know (and packaged) plenty of projects which never used tags nor heard of semantic versioning or even care about. For instance, that's why all those go packages have 0.0.0+git$BLA :-)

Exactly. Even for a project that strictly follows semver, it still might have a series of tags like this: v0.1.0 v0.1.1 v0.1.2 v0.2.0 v0.2.1 v0.2.2 rel-1.0.0 rel-1.0.1 or worse ;-) IMHO the "if" is too big to rely on. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 03:46:57PM +0200, Michal Kube??ek wrote:

One problem with this is that it makes the way we are constructing KMP version strings rather fragile. As soon as module versions keep the same number of components, e.g.

1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1.0 -> 1.1.1 -> ...

you are safe. But once you try

1 -> 1.1

you are in trouble.

I think that you could (mis-)use the ~ comparison mechanism for this provided by newer rpm versions: $ zypper vcmp 1~1 1~9 1~1 is older than 1~9 $ zypper vcmp 1.1~1 1~9 1.1~1 is newer than 1~9 That doesn't work in SLE11, though. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 15:28, Frederic Crozat wrote:

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ?

Yes, but not applicable in this case. Remember the sort order: 4.8.1~s < 4.8.1 < 4.8.1_s < 4.8.1_2 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 15:56, Michael Schroeder wrote:

On Tue, Sep 10, 2013 at 03:46:57PM +0200, Michal Kube??ek wrote:

...

One problem with this is that it makes the way we are constructing KMP version strings rather fragile. As soon as module versions keep the same number of components, e.g.

1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1.0 -> 1.1.1 -> ...

you are safe. But once you try

1 -> 1.1

you are in trouble.

I think that you could (mis-)use the ~ comparison mechanism for this provided by newer rpm versions:

Which is something I suggested as early as https://bugzilla.novell.com/show_bug.cgi?id=540558 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 04:05:34PM +0200, Frederic Crozat wrote:

Le mardi 10 septembre 2013 à 16:02 +0200, Jan Engelhardt a écrit :

...

On Tuesday 2013-09-10 15:28, Frederic Crozat wrote:

...

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ?

Yes, but not applicable in this case. Remember the sort order:

4.8.1~s < 4.8.1 < 4.8.1_s < 4.8.1_2

Hmm, usually, I tend to use git checkout (or any other vcs checkout) before a particular release is out, so 4.8.1~s is ok.

But now, I understand it doesn't handle all the options :(

You just have to wait until 4.8.2 if you want to introduce a new numbering scheme ;) Cheers, Michael -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

It's just an alternative. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

...

...

...

...

On Tue, 10 Sep 2013 14:39:35 +0100, Adam Spiers said:

Sascha Peilicke (speilicke@suse.com) wrote:

...

On 09/10/2013 02:39 PM, Andreas Schwab wrote:

...

Adam Spiers writes:

...

Please can you define "properly named"?

So they sort properly like the version.

Andreas.

I guess the "if" is important here, I know (and packaged) plenty of projects which never used tags nor heard of semantic versioning or even care about. For instance, that's why all those go packages have 0.0.0+git$BLA :-)

Exactly. Even for a project that strictly follows semver, it still might have a series of tags like this:

v0.1.0 v0.1.1 v0.1.2 v0.2.0 v0.2.1 v0.2.2 rel-1.0.0 rel-1.0.1

yes but if the upstream follows some kind of standardization in their scm then it is workable For example I maintain nightly builds for darktable for a long time and this is what I use dt_ver=$(git describe --tags HEAD | sed 's,^release-,,;s,-,_,;s,-,_,;') which results 1.3_929_g6202a15 and the respective field in the spec is Version: %{dt_ver}_git

or worse ;-) IMHO the "if" is too big to rely on.

That I agree so that depends on the upstream unfortunately Togan -- Life is endless possibilities -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 15:58, Marguerite Su wrote:

...

2. "+" mostly of times means "combination"

I question that it does. It certainly does not for me.

Note we are talking version numbers here, where there is more math than prose involved; therefore, '+' meaning addition/increase is more topical than agglomeration.

Agreed (IIUC).

...

I think git20130910 might be good idea. you know it's from git, you know it's state, if you wanna search, github has a timestamp (although some heavy contributors may commit many times a day, but actually it's not a good habit)

Strongly disagree that it's not a good habit. There are plenty of good reasons for rapid iteration (included automated package building).

The timestamp is useless as mentioned previously

Mentioned by who? It's certainly not useless - it's *required* for correct chronological ordering, as I already mentioned.

as multiple commits may have the same (1s-resolution) timestamp.

True (although it should be very rare) - that's why you need both the timestamp and the hash.

An offset (with or without hash, depending on what's needed) is both short and precise.

Sorry, I don't understand this. Can you explain in more detail? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Tue, 10 Sep 2013, Adam Spiers wrote:

...

The timestamp is useless as mentioned previously

Mentioned by who? It's certainly not useless - it's *required* for correct chronological ordering, as I already mentioned.

You're too fixated on git. Correct chronological ordering is not depending on timestamps. It depends on some number that monotonically increases with commit time. svn revision numbers do for instance. And as timestamps indeed have the mentioned problem it's actually a bad way to ensure chronological ordering. Better than nothing I suppose, but not very good.

...

An offset (with or without hash, depending on what's needed) is both short and precise.

Sorry, I don't understand this. Can you explain in more detail?

Offset == number of commits on top of some base (where base in git describe parlance is e.g. a tag). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab (schwab@suse.de) wrote:

Follow the thread.

I did shortly after replying, but it's standard netiquette to quote some context in your reply. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers writes:

In fact, there cannot ever be a silver bullet, because if you have multiple branches being developed in tandem (e.g. stable and development) then there is no strictly defined ordering.

If they are not totally insane then the branches will have different versions. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 16:24, Togan Muftuoglu wrote:

For example I maintain nightly builds for darktable for a long time and this is what I use

dt_ver=$(git describe --tags HEAD | sed 's,^release-,,;s,-,_,;s,-,_,;') which results

1.3_929_g6202a15 and the respective field in the spec is Version: %{dt_ver}_git

Interesting case - that can blow up when darktable releases a hypothetical "1.3.1". That is because 1.3.1_1024 < 1.3_929 Like http://en.opensuse.org/openSUSE:Package_naming_guidelines suggests, the SCM identifier ("git") should be *before* the SCM ids. IOW, Version: 1.3_git929_g6202a15 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 17:12, Adam Spiers wrote:

...

you, as the packager, should have been smart enough to recognize this and _NOT_ transplant the v*/rel-* into the RPM Version: field, just like it is done for the Linux kernel (has tag like "v3.11" but our RPM packages have 3.11 naturally). In fact, blindly transplanting whatever `git describe` tells you into Version: is almost

... almost what?

almost stupid :) Tags may be used for things other than releases (though thankfully that's rare). Think git://git.gitorious.org/opensuse/kernel-source which not only has "rpm-3.7.10-1.1" tags, but also "SLES11_RC2" and whatnot. If you don't watch out, it may happen that `git describe` outputs SLES11_RC2-1-g1234567 instead of the rpm-3.7.10-1.1-8-g9abcdef that you sought.

But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering.

It is, if you pay attention or trusting the tags.

The timestamp + SHA combination is deterministic and unique, sorts chronologically

Deterministic and unique, yes, but %ct is not strictly guaranteed to be strictly monotonically increasing. That is to say, you can construct a case where %ct is useless. Simiarly, one can construct cases where a tag offset becomes useless. But excluding the cases where {either %ct or tag offset is uselees}, a tag offset is shorter than %ct. The longer this discussion goes on, the more I think hashes in Version: should be abolished completely. They do not sort well, and trying to work around it with either %ct or tag offsets is just a bandaid. If the hash is gone from Version, so is the need for the sorting bandaid. Just call the f'ng Version: 1.5+git and spell out everything else in the %description. The Release: will automatically increase everytime you commit and ensure that people get the latest version your hands produced, even if there was branch-hopping or shipping an older git snapshot (a revert in essence). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 17:12, Adam Spiers wrote:

...

...

you, as the packager, should have been smart enough to recognize this and _NOT_ transplant the v*/rel-* into the RPM Version: field, just like it is done for the Linux kernel (has tag like "v3.11" but our RPM packages have 3.11 naturally). In fact, blindly transplanting whatever `git describe` tells you into Version: is almost

... almost what?

almost stupid :)

Tags may be used for things other than releases (though thankfully that's rare).

It's certainly not rare in my usage, and I don't think I'm unusual. There are plenty of good reasons for using tags other than releases.

Think git://git.gitorious.org/opensuse/kernel-source which not only has "rpm-3.7.10-1.1" tags, but also "SLES11_RC2" and whatnot. If you don't watch out, it may happen that `git describe` outputs SLES11_RC2-1-g1234567 instead of the rpm-3.7.10-1.1-8-g9abcdef that you sought.

Exactly.

...

But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering.

It is, if you pay attention or trusting the tags.

?

...

The timestamp + SHA combination is deterministic and unique, sorts chronologically

Deterministic and unique, yes, but %ct is not strictly guaranteed to be strictly monotonically increasing. That is to say, you can construct a case where %ct is useless.

Interesting - please can you provide an example?

Simiarly, one can construct cases where a tag offset becomes useless. But excluding the cases where {either %ct or tag offset is uselees}, a tag offset is shorter than %ct.

What about the cases where tag offsets cannot be generated at all, due to the lack of any tags? I'm open to ideas involving tag offsets. But I'd need to see the details of a real implementation. For example, what would the _service file look like?

The longer this discussion goes on, the more I think hashes in Version: should be abolished completely. They do not sort well,

If you mean chronologically, they don't sort at all. But that's not a good reason to remove them from Version. They are needed in order to provide crucial information about which version of the source they came from. My team currently relies on this when debugging issues, and I expect the kernel team does too.

and trying to work around it with either %ct or tag offsets is just a bandaid. If the hash is gone from Version, so is the need for the sorting bandaid.

Huh?? The hash is not there to help with sorting. It's there for a completely different reason as explained above and in previous emails. So why are you saying that %ct is a workaround or bandaid for it?

Just call the f'ng Version: 1.5+git and spell out everything else in the %description. The Release: will automatically increase everytime you commit and ensure that people get the latest version your hands produced, even if there was branch-hopping or shipping an older git snapshot (a revert in essence).

Hiding important metadata in %description is going to cause problems. For example, a decent bugreport will contain version numbers of all relevant rpms involved in the bug, but it will not contain a copy'n'paste of running rpm -qi on all those rpms. So your proposed change would require a lot of developers to have to say "thanks but please can you run rpm -qai and send me the output" every time they receive a bug report. Not a good idea. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 19:05, Adam Spiers wrote:

It's certainly not rare in my usage, and I don't think I'm unusual.

Maybe that is prominent in the projects you look over (GNOME or something?), but it certainly is not the case for what I have on my lookouts. systemd, kmod, "those things", they generally only have release tags in their repos.

There are plenty of good reasons for using tags other than releases.

...

...

But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering.

It is, if you pay attention or trusting the tags.

If there will never be tags for anything but marking tarballs, then trusting the tags is ok and `git describe` will always output something useful. In case of suse-kernel, one may try `git describe --match="rpm-*" to limit what tags can actually be used for bases.

...

...

The timestamp + SHA combination is deterministic and unique, sorts chronologically

Deterministic and unique, yes, but %ct is not strictly guaranteed to be strictly monotonically increasing. That is to say, you can construct a case where %ct is useless.

Interesting - please can you provide an example?

$ GIT_COMMITTER_DATE="1970-01-01 00:00:00" git ci -m \ "Initial commit for Unix :)" [master 7db0cff] Initial commit for Unix :) 1 file changed, 1 insertion(+) Note I how said "constructed case". You won't see it everyday, but it is possible. Tag offsets are resistant to this (though there are other constructible cases where they become useless).

...

Simiarly, one can construct cases where a tag offset becomes useless. But excluding the cases where {either %ct or tag offset is uselees}, a tag offset is shorter than %ct.

What about the cases where tag offsets cannot be generated at all, due to the lack of any tags?

I'll just quote the thing I recently placed into the wiki and already used in a number of (upstream-)nascent packages: """an alternative monotonically increasing identifier can be obtained by using the history root as a base (`git rev-list 9265358 | wc -l`), useful for when a project is in such an early stage that there have not been any releases yet (Version: 0~git123)."""

...

and trying to work around it with either %ct or tag offsets is just a bandaid. If the hash is gone from Version, so is the need for the sorting bandaid.

Huh?? The hash is not there to help with sorting.

The hash does not contribute to sortability. %ct is a bandaid for ensuring sorting order. Tag offset is a bandaid for ensuring sorting order. Move the hash from Version to Description, and you will no longer need the bandaid. But I do accept your argument that telling users in a second step to re-run `rpm -qi` may be asking too much of them. So it seems we are to live with sorting bandaids :p -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 20:20, Claudio Freire wrote:

Since you have the hash, you don't even need more than day precision

Since you have the hash, you don't need *anything else* per se except so as to please the package manager. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Claudio Freire (klaussfreire@gmail.com) wrote:

On Tue, Sep 10, 2013 at 8:22 AM, Sascha Peilicke wrote:

...

5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

Is that a unix timestamp?

IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

Since you have the hash, you don't even need more than day precision,

Incorrect - it's there for sorting to ensure libzypp knows which package is newer.

Being able to tell the release date from the version number without aid from a python console would be good, IMHO.

I agree, but that would make it even longer, and people are already complaining about the length. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 20:37, Claudio Freire wrote:

On Tue, Sep 10, 2013 at 3:24 PM, Jan Engelhardt wrote:

...

On Tuesday 2013-09-10 20:20, Claudio Freire wrote:

...

Since you have the hash, you don't even need more than day precision

Since you have the hash, you don't need *anything else* per se except so as to please the package manager.

So, if it's there to please a human, then it's all the more important to have it human-readable right?

I guess. From what I hear from Adam Spiers however, the part behind the real version is there for the developer.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 20:43, Adam Spiers wrote:

...

Is that a unix timestamp? IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

YYYYMMDD is a permitted hyphenless format of ISO 8601, (says Wikipedia). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013 20:43, Adam Spiers wrote:

Claudio Freire (klaussfreire@gmail.com) wrote:

...

On Tue, Sep 10, 2013 at 8:22 AM, Sascha Peilicke wrote:

...

5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

Is that a unix timestamp?

IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

I'd prefer something a little different than 5.), let's call it 6. 6.) X+{date}.{scm}{commit} with: {date} as %Y%m%d = YYYYmmdd followed by (dot), {scm} as one of {git,svn,bzr,hg,cvs,...}, and {commit} as scm-specific commit tag / hash / whatever Pro: readability, sortability (at least days work for sure), uniqueness Contra: can be long Please, discuss. - Yamaban -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 20:43, Adam Spiers wrote:

...

...

Is that a unix timestamp? IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

YYYYMMDD is a permitted hyphenless format of ISO 8601, (says Wikipedia).

Cool, I didn't know that. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, guys, You are diving too deep that I can't quite follow even by reading the whole thread... I just need some clearance: Will this be (possibly) a RFC that appears on wiki and limits all packagers? Or you were just talking about OBS coding/automatic packaging eg tar_scm backend (if so, I was wrong, I think you were talking about giving a name by hand) so that I can just skip the whole thread and go to sleep (not ironic, it's 03:06am in China and I just wake up from deep sleep :D) Because I see you talked too much about the inner mechinism of svn/git... If it's a RFC, do our packagers need attending a codeschool tutorial before fetching from svn/git? You know, many of us just learned `svn co` and `git clone`... And I see you talked the importance of "hashes", now I know by using it everything else is not needed. But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance. Or we just want users get the idea "wow it's from svn/git. wow it's a dev version" and leave the math for zypper to calculate which version is newer? If so, everything is fine...we can even add upstream code name to the version scheme :P Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 4:19 PM, Marguerite Su wrote:

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

And the very second and the very third. TBH, hashes don't mean anything except to the developers of the package. And, TBH, only when debugging, and only with the aid of developer tools. Because I'm a developer and I can't stand hashes in any other context (ie: reverting to a hash, or reading a git log with hashes instead of releases, confuses the hell out of me). But to *them*, **when debugging**, it means something very specific and very useful. So I can put up with them being on the version string, since it entails tangible benefits during bug hunting. And it's not the timestamp that makes the version string long. It's the hashes. Typical git hashes are 160-bits long. That's 40 hex digits. That's a lot more than is shown on that example on the OP. Unless the proposal is to put the last N digits of the hash? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Claudio Freire (klaussfreire@gmail.com) wrote:

On Tue, Sep 10, 2013 at 4:19 PM, Marguerite Su wrote:

...

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

And the very second and the very third.

TBH, hashes don't mean anything except to the developers of the package. And, TBH, only when debugging, and only with the aid of developer tools. Because I'm a developer and I can't stand hashes in any other context (ie: reverting to a hash, or reading a git log with hashes instead of releases, confuses the hell out of me).

But to *them*, **when debugging**, it means something very specific and very useful.

So I can put up with them being on the version string, since it entails tangible benefits during bug hunting.

Exactly.

And it's not the timestamp that makes the version string long. It's the hashes. Typical git hashes are 160-bits long. That's 40 hex digits. That's a lot more than is shown on that example on the OP. Unless the proposal is to put the last N digits of the hash?

Of course! 40 bytes would be idiotic. Sascha's original post proposed using the abbreviated commit hash ("%h" in git log) which is only 7 bytes - are you *sure* you read the whole thread? ;-P http://lists.opensuse.org/opensuse-packaging/2013-09/msg00035.html -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Sep 11, 2013 at 3:39 AM, Adam Spiers wrote:

...

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

Why is that a problem, and where? You mentioned before that it is shown in UIs, but the UI could easily hide the hash if it wanted to.

Yes...sorry, I think the situation that user-experience-concern guys and tech-detail-concern guys talking together loudly just make we misunderstand each other. My original idea was that version number will be shown to users in YaST. So users seeing a random string will not get a clear view of what we just want to ship. They can just judge by the svn/git prefix to get an idea that this version is a dev version. Because a "random string" is meaningless if they don't know the tech details behind it.

...

Or we just want users get the idea "wow it's from svn/git. wow it's a dev version"

Most users except power users don't usually care much about the version number. A UI can choose how much or little of the $VERSION-$RELEASE string to expose. But usually it will make sense to expose either all of it, or none of it.

Yes...but they still want to know if they're installing a newer version or older version, unless YaST can tell them by color diff. eg, if you install fcitx-4.2.8.git20130911, you know it is newer than fcitx-4.2.8.git20130910 But if it is fcitx-4.2.8.git.aldjfad and fcitx-4.2.8.git.wueouqp, they just don't know what you are trying to telling them. My theory just comes from the fact that Arch linux changed all its network interfaces to random strings, eg: wlan0 is not wlan0, is wlanjlajl. So now users just know it's a wlan, they can't even search an answer through by Google because everyone's interface is now different. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 6:06 PM, Adam Spiers wrote:

$ git log -n1 --date=short --pretty=format:%ci 2013-09-02 14:00:14 +0100

So in fact that --date=short probably doesn't have any effect and maybe it could be removed.

Um... that timezone part also looks like it would be troublesome -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013 23:08, Claudio Freire wrote:

On Tue, Sep 10, 2013 at 6:06 PM, Adam Spiers wrote:

...

$ git log -n1 --date=short --pretty=format:%ci 2013-09-02 14:00:14 +0100

So in fact that --date=short probably doesn't have any effect and maybe it could be removed.

Um... that timezone part also looks like it would be troublesome

Yep! Enforcing UTC is a MUST have, anything else is plain stupid. - Yamaban. -- Sign near EmergenyMedicalCenter door: Please, do not feed stupid, there is already to much of it, just look around you. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 21:39, Adam Spiers wrote:

...

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

Why is that a problem, and where? You mentioned before that it is shown in UIs, but the UI could easily hide the hash if it wanted to.

There is no way for an UI to reliably tell whether a given part of %version is a hash or not as long as %version is a plaintext non-markup string. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 22:30, Marguerite Su wrote:

They can just judge by the svn/git prefix to get an idea that this version is a dev version.

The prefix does not necessarily indicate that something is dev or unstable, although many people want to paint a picture that everything that has not been made available as a tarball is broken.

My theory just comes from the fact that Arch linux changed all its network interfaces to random strings, eg: wlan0 is not wlan0, is wlanjlajl. So now users just know it's a wlan, they can't even search an answer through by Google because everyone's interface is now different.

Everyone's interface was different before already. Some have eth0, others eth1, eth2, and so on. The interface name is a bad search keyword in any case. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013, Michael Schroeder wrote:

On Tue, Sep 10, 2013 at 04:05:34PM +0200, Frederic Crozat wrote:

...

Le mardi 10 septembre 2013 ? 16:02 +0200, Jan Engelhardt a ?crit :

...

On Tuesday 2013-09-10 15:28, Frederic Crozat wrote:

...

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ?

Yes, but not applicable in this case. Remember the sort order:

4.8.1~s < 4.8.1 < 4.8.1_s < 4.8.1_2

Hmm, usually, I tend to use git checkout (or any other vcs checkout) before a particular release is out, so 4.8.1~s is ok.

But now, I understand it doesn't handle all the options :(

You just have to wait until 4.8.2 if you want to introduce a new numbering scheme ;)

Or completely alternative to this whole scheme just package a diff alongside a released tarball. Bonus: you get the possibility of being able to verify its contents with an available signature. Bonus 2: less load on the source server(?) Bonus 3: easier to see what the changes since a release are. Oh, and then provide incremental diffs whenever you update the package rather than exchanging the diff. Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 21:39, Adam Spiers wrote:

...

...

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

Why is that a problem, and where? You mentioned before that it is shown in UIs, but the UI could easily hide the hash if it wanted to.

There is no way for an UI to reliably tell whether a given part of %version is a hash or not as long as %version is a plaintext non-markup string.

Well, that's a good argument for standardising, isn't it? But it's still easily possible to reduce a non-parseable %version-%release string to something less scary looking: $ sed 's/\([0-9]\+\(\.[0-9]\+\)*\).*/\1/' 1.6+git.1377888079.761bc8b-0.63.4 1.6 0.17.3~g29a8b0f-1.2 0.17.3 2.0.1.4svn475-7.4 2.0.1.4 Although personally I think that's a bad idea. As I already said, IMHO a UI should either expose the whole %name-%version-%release, or just %name. Anything in between is misleading. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 09/10/2013 01:40 PM, Adam Spiers wrote:

Sascha Peilicke (speilicke@suse.com) wrote:

...

Hi guys,

I'd like to gather some input on versioning schemes used for packaging SCM snapshots.

[snipped]

...

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism).

TL;DR =====

My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions.

+1 for number 5), although I'm somewhat biased, because IIRC it was me that originally proposed that scheme for OpenStack packages ;-) It seems to have worked well for us over the last 18 months.

;-)

At the time I think there was also some discussion of also embedding git metadata within the rpm %description. It's interesting to see what the kernel guys are currently doing, e.g.:

$ rpm -qi kernel-desktop-3.7.10-45.1.gff50a00 | tail -n4 Source Timestamp: 2013-07-26 15:39:00 +0200 GIT Revision: ff50a00e96dbde96e962b6cd9f871bb710efa9c3 GIT Branch: openSUSE-12.3 Distribution: Kernel:openSUSE-12.3

For the Kernel it's definitely useful since users that check this package probably know what they're doing. For leaf-packages where knowledge of git (or $SCM) can't be taken for granted, I'm not sure if this only adds confusion. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

On 09/10/2013 04:59 PM, Michael Matz wrote:

Hi,

On Tue, 10 Sep 2013, Adam Spiers wrote:

...

...

The timestamp is useless as mentioned previously

Mentioned by who? It's certainly not useless - it's *required* for correct chronological ordering, as I already mentioned.

You're too fixated on git. Correct chronological ordering is not depending on timestamps. It depends on some number that monotonically increases with commit time. svn revision numbers do for instance.

And as timestamps indeed have the mentioned problem it's actually a bad way to ensure chronological ordering. Better than nothing I suppose, but not very good.

True for svn (and similar ones). Since branches are only directories here and the history is always global, revision numbers should be sufficient. However, commit timestamps should equally comply. So using both could be viewed as overkill / redundancy, but at least it wouldn't hurt in some general packaging recommendation. If possible, I'd want to avoid documenting many special cases since that would somewhat defeat the purpose of this thread. Being aware of things is certainly useful, so thanks for broadening the discussion.

...

...

An offset (with or without hash, depending on what's needed) is both short and precise.

Sorry, I don't understand this. Can you explain in more detail?

Offset == number of commits on top of some base (where base in git describe parlance is e.g. a tag).

Ciao, Michael.

-- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

On 09/10/2013 04:05 PM, Frederic Crozat wrote:

Le mardi 10 septembre 2013 à 16:02 +0200, Jan Engelhardt a écrit :

...

On Tuesday 2013-09-10 15:28, Frederic Crozat wrote:

...

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ?

Yes, but not applicable in this case. Remember the sort order:

4.8.1~s < 4.8.1 < 4.8.1_s < 4.8.1_2

Hmm, usually, I tend to use git checkout (or any other vcs checkout) before a particular release is out, so 4.8.1~s is ok.

But now, I understand it doesn't handle all the options :(

I guess it depends on how you view it. It can either be $CURRENT_RELEASE+$FANCY_STUFF_FROM_SCM or $UPCOMMING_RELEASE~$WHATS_REALLY_IN_SCM -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

Richard Biener (rguenther@suse.de) wrote:

On Wed, 11 Sep 2013, Adam Spiers wrote:

...

Richard Biener (rguenther@suse.de) wrote:

...

Or completely alternative to this whole scheme just package a diff alongside a released tarball.

Nice thinking outside the box :-)

...

Bonus: you get the possibility of being able to verify its contents with an available signature.

I don't understand this point. You mean verify the contents of the released tarball? But if the diff is not also verified then isn't that rather pointless? Also, a git hash is equivalent to an integrity check (albeit an unsigned one).

Yes, verify the contents of the released tarball. SCMs other than git don't have that hash as integrity check.

IIRC mercurial and monotone do, at least. And probably bzr too.

...

...

Bonus 2: less load on the source server(?)

tar_scm caches, so I'm not sure that argument's too compelling.

I mean the source server stores each and every file that ever was in any source package.

Sounds like you're more familiar with the OBS server-side implementation than me. Are you saying that for every single tarball uploaded, OBS keeps an unpacked version server-side? That surprises me, because I know that it keeps the *packed* version, and keeping both seems very wasteful (except if the unpacked version was part of a cache).

So if you update the tarball many times the source server ends up storing each tarball forever. Just adding (or updating) a patch should be cheaper.

I think that would probably depend on the size of the tarballs, the size of the patches, and the frequency of updates. Uncompressed patches can be quite wasteful too.

It may be that with source services the tarballs are not stored permanently(?) but only cached (and the cache is garbage collected). Of course that would have issues with digging up old revisions of packages if the source used in the source service vanishes.

Don't forget that source services can be client-side-only, via disabledrun mode.

...

...

Bonus 3: easier to see what the changes since a release are.

Easier for who? Only for packagers, and excluding the one who packaged the diff (since they already had to have a clone of the repo in order to make the diff in the first place). So again, not hugely compelling IMHO.

Well, for GCC for example you at the moment get changes like

Mon Sep 9 11:56:02 UTC 2013 - rguenther@suse.com

- Update to gcc-4_8-branch head (r202388). - Backports regression fixes for all architectures. * includes changes in aarch64-pthread-option.patch

and simply the source tarball exchanged. If I'd have packed a diff from the last update (r201525) you can easily browse that for malicious changes (given the source tarball would be digitally signed and verified).

Of course one reason that I wouldn't accept outside submitrequests that update the source tarball ;) Don't trust anybody but myself.

Well, that's another good reason to avoid using an SCM which doesn't have integrity built into the design :-)

...

...

Oh, and then provide incremental diffs whenever you update the package rather than exchanging the diff.

In the absence of a source service to do this (which I suspect would be quite hard to write), I think it will create a lot more work for the packager :-/

Not sure - I have a script to update the GCC package to a SVN revision and I never used source services. A source service to provide a diff between a previous revision and head (or between two revisions) shouldn't be terribly hard to write though (no, I'm not volunteering ;)).

;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dominique Leuenberger a.k.a. Dimstar (dimstar@opensuse.org) wrote:

Quoting Sascha Peilicke :

...

On 09/10/2013 01:50 PM, Dominique Leuenberger a.k.a. Dimstar wrote:

...

They have their merits and disadvantages of course. I'd not go as far as making the format a requirement for Factory checkins.

Sure, as mentioned somewhere I for now look at some generic recommendations / best practices.

...

There are short-living packages and longer-living ones; a package 'always' depending on git snapshots probably wants to express this in the version number; a package doing this 'temporarily' to overcome an obstacle might be fine with any other, shorter, for and only specify the exact commit / branch in the .changes file.

But even then, correctness won't hurt. Even if the git snapshot is temporarily, people want to know which commit was picked. Format 1) doesn't seem to provide this info.

We both know you were triggered by my PA submission for this; so let's just use it as an example. There is no added value stating which 'hash' it is in the version number.

Actually in general there is; as I already mentioned, it can debugging bug reports easier.

The specific branch / commit used for checkout is mentioned in the .spec file as well as in .changes (even with an explanation why not using HEAD of that branch).

But the .spec and .changes files are not usually available in bug reports. Of course, the value of the hash becomes diminished if the .spec uses an SCM snapshot *and* applies patches on top. Sometimes it makes sense to mix the approaches, other times it doesn't. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia wtorek, 10 września 2013 18:05:42 Adam Spiers pisze:

Jan Engelhardt (jengelh@inai.de) wrote:

...

Just call the f'ng Version: 1.5+git and spell out everything else in the %description. The Release: will automatically increase everytime you commit and ensure that people get the latest version your hands produced, even if there was branch-hopping or shipping an older git snapshot (a revert in essence).

Hiding important metadata in %description is going to cause problems. For example, a decent bugreport will contain version numbers of all relevant rpms involved in the bug, but it will not contain a copy'n'paste of running rpm -qi on all those rpms. So your proposed change would require a lot of developers to have to say "thanks but please can you run rpm -qai and send me the output" every time they receive a bug report. Not a good idea.

The bug report will contain version numbers and release numbers. Developers can recover the exact source from the release number, can't they? Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

10.09.2013 15:33, Jan Engelhardt пишет:

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. [...] Here's a small list of flavors that I've come across or used myself.[...] TL;DR: My recommendation would be to (at least loosely) follow pattern 5) versioning.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

TL;DR: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v...

Should I assume that guidelines at the link have been fixed according the decision token after this terrible long discussion? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 2014-01-10 20:44, Matwey V. Kornilov wrote:

10.09.2013 15:33, Jan Engelhardt пишет:

...

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v...

Should I assume that guidelines at the link have been fixed according the decision token after this terrible long discussion?

The last significant changes were made the same day I pointed at the URL. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Friday 2014-01-10 21:06, Adam Spiers wrote:

...

...

10.09.2013 15:33, Jan Engelhardt пишет:

...

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations

Should I assume that guidelines at the link have been fixed

They haven't.

They were not broken, so they did not need fixing.

Broken is probably too strong a word, but they could be improved ;-p

...

Well, I spammed the thread with my opinions, and IMHO I *believe* that I successfully countered any objections to the scheme which my team favours ... but I'm not sure whether the fact that there were no more *publically stated* objections counts as a consensus

Didn't you read the fineprint - "period for appeal is 8 weeks, starting with the reception of [last mail in discussion]"? :)

;-) Well, a few of my points went unanswered, as I'll note below.

Let's recap for "1363873583.8dfab15" (TS.HASH):

* The version ought to be monotonically increasing somehow. The timestamp does that, sure, but so does the tag-offset (for a given branch that is being continuously packaged) while at the same time, the latter is much shorter.

Please can you explain exactly how you would programmatically obtain the "tag-offset", and explain why it is reliably monotonically increasing? For example, if a non-release tag is introduced into the repository, how would you ensure that the tag-offset doesn't suddenly drop back to zero? I already pointed out this flaw in September: http://lists.opensuse.org/opensuse-packaging/2013-09/msg00099.html but still noone has explained how it could be circumvented. And then there's still the case where there are no tags, and I don't agree with the point of view that every repository should have tags. It's up to each maintainer whether they wish to issue releases or operate according to a continuous development model. Package versioning guidelines should not be opinionated about development models.

* If people ship different branches, they do so in different BSprjs (cf. network:samba:), or with different package names (cf. squid/squid3/squid-beta) rather than (a) implanting that into %version or even (b) implying it through the hash.

Nope, branches very often correspond to releases, therefore the branch is often indicated by *both* the BS project *and* the first part of %version. For example, Cloud:OpenStack:Grizzly has a bunch of openstack-* packages whose %versions begin with "2013.1", whereas Cloud:OpenStack:Havana %versions begin with "2013.2". That's obviously useful, because you can instantly tell from rpm -qa which version of OpenStack is installed.

* Adam Spiers says: "hashes are needed even when history is linear, because then you know exactly which source revision the package came from". This is a Microsoft Balloon[1] argument;

Error: aborting due to dangling footnote reference at line 16 ;-)

it _might_ be usable in _some obscure_ way

Sorry, this is plain wrong. There is no debate whatsoever about whether it's usable, because I use it on a regular basis when debugging errors reported by users. And there's nothing remotely obscure about the way I use it; I simply git checkout the hash, or eyeball the corresponding revision in gitk or similar. It seems that you are in favour of embedding the hash in %description instead. How is that any more usable or less obscure?

you can have your hash. But that does not change the fact that it is still very much a niche-indicator.

On what evidence are you basing this assertion, and what's your point?

The kernel people (samba too?) recognized that and placed it into %description instead - with complete branch info by the way.

I have no objections with including extra meta-data in %description; in fact I would encourage it. But that still does not solve the problem regarding bug reports: http://lists.opensuse.org/opensuse-packaging/2013-10/msg00008.html

In summary: objections have been objectioned, leaving the arguments for TS.HASH with what it seems to be of no to little weight.

Sorry, but that's a wholly inaccurate summary. As highlighted above, I have two strong objections to the git-oriented aspects of the SCM snapshots section of the existing guidelines[1], neither of which have had solutions provided yet: 1. Tag offsets are not reliably monotonically increasing 2. Bug reports often provide little more than an rpm version number and an error message (or stack trace, if you're lucky). So if the %version doesn't point to an exact source revision then life gets harder. There's the other point about repositories with no tags, but I suspect we'll have to agree to disagree on that.

You can still use TS.HASH, but you won't find a majority (in terms of mass) to back it.

Of course you're entitled to your personal opinions about likely adoption. But that's putting the cart before the horse, because a guidelines document which just describes what the majority believe is about as useful as a web page which advises people to "use Windows or MacOS X". Anyway, I'm not interested in finding a majority (let's face it, not many people care about this stuff to this level of detail anyway); I'm interested in finding the optimal solution. [1] https://en.opensuse.org/openSUSE:Package_naming_guidelines#SCM_snapshots -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 00:40, Adam Spiers wrote:

...

Please can you explain exactly how you would programmatically obtain the "tag-offset"

It's described in text form in the wiki article.

#!/usr/bin/perl use IPC::Open3; use strict;

[Orthogonal to this discussion, but if you must use Perl, please: never, EVER omit "use warnings;"]

sub grab { local(*CIN, *COUT, *CERR); my $pid = open3(\*CIN, \*COUT, \*CERR, @_); chomp(my $line = <COUT>); close(CIN); close(COUT); close(CERR); waitpid($pid, 0); return ($line, $? >> 8); # need something better than "$?"? }

sub result { print "Version: $_[0]\n"; exit(0); } my $commit = shift(@ARGV) || "HEAD"; my $pattern = shift(@ARGV) || "*"; my @args = ("git", "describe", "--match=$pattern", "--abbrev=0", $commit); my($base, $err) = &grab(@args); if ($err != 0) { chomp(my $len = `git rev-list "$commit" | wc -l`); &result("0~git$len"); } splice(@args, 3, 1); # remove --abbrev=0 my($offset) = &grab(@args); &result($base) if ($base eq $offset); &result("$base~git$offset") if ($offset =~ s{^\Q$base\E-(\d+)-g\w+$}{$1}); print STDERR "This should not happen.\n"; exit(1);

No need to grab the base separately, just use --long: sub offset { my $commit = shift || "HEAD"; my $pattern = @_ ? shift : "*"; my ($tag, $offset, $hash) = `git describe --long --tags --match=$pattern "$commit" 2>&1` =~ /^(.+)-(\d+)-g([0-9a-f]+)$/; return $offset unless $?; $offset = `git rev-list "$commit" | wc -l`; $? ? die "failed to get offset" : $offset; }

...

...

The version ought to be monotonically increasing somehow. The timestamp does that, sure, but so does the tag-offset (for a given branch that is being continuously packaged)

and explain why it is reliably monotonically increasing?

If you stay on a given branch, if you make a commit, you add +1 to the distance. If you make a merge commit, you add some +n (n>0) to the reported distance.

Yes, I already understand the basic concept :-) I was specifically asking for an explanation which deals with problems such as this:

...

For example, if a non-release tag is introduced into the repository, how would you ensure that the tag-offset doesn't suddenly drop back to zero?

git describe --match=

One would at least hope you name your release tags reasonably unique that they are programmatically distinguishable from nonrel tags (that would also be worthwhile from a human perspective).

So to be clear, you are suggesting a generally applicable technical solution based on hope?

...

And then there's still the case where there are no tags, and I don't agree with the point of view that every repository should have tags.

And the wiki page (and the perl above) has a solution for that as well, which would tell me you did not visit the wiki page again ever since last September's discussion.

Your inference is mistaken. Regardless, that is not a valid solution, because it breaks instantly when the first tag is introduced to the repository. Don't get me wrong - *aesthetically* I prefer the idea of being able to use tag offsets: a single monotonic integer metric is a bit more elegant than a timestamp. But unfortunately I don't think they offer a workable solution. The discussion about whether %version should also be suffixed with a hash is orthogonal to the "timestamp vs. tag offset" debate, and I have already explained elsewhere the value of including the hash. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 12:56, Adam Spiers wrote:

...

No need to grab the base separately, just use --long:

Grabbing the base separately is necessary to catch the (braindead) case that you have a tag called "v3.4-5-g1234567". If you just run git describe, you therefore could not determine whether your current HEAD is (v3.4-5-g1234567)-0-g9876543 or (v3.4)-5-g1234567.

Like I said, --long solves that case, because it *always* outputs the long format, so there is no ambiguity.

...

...

...

For example, if a non-release tag is introduced into the repository, how would you ensure that the tag-offset doesn't suddenly drop back to zero?

git describe --match=

One would at least hope you name your release tags reasonably unique that they are programmatically distinguishable from nonrel tags (that would also be worthwhile from a human perspective).

So to be clear, you are suggesting a generally applicable technical solution based on hope?

I am suggesting that people not turn off their brains.

You don't just make a non-release tag and give it a name like a release tag.

OK, so let's assume I have a bunch of tags like: v1.0.1 v1.0.2 etc. We are looking for a programmatic solution which can be automated by tools such as tar_scm. You are presumably suggesting to use something like git describe --match='v[0-9]*.[0-9]' right? But there is no pattern which for release tags, and non-release tags, therefore you are introducing the requirement for a custom glob per project. And this glob is necessarily brittle, because very often the person maintaining the upstream repository containing the tags is different to the person maintaining the downstream package, and will have zero awareness that someone else is hoping they will ensure that a) all their release tags match this glob, and b) none of their non-release tags match this glob. Furthermore, this would mean that the tar_scm source service would require an extra parameter (which only applies in the git case). It also would require a patch to tar_scm to add support for your tag offset mechanism. I believe in freedom of choice, so I would gladly accept a pull request from you which supports that scheme, in order that people like yourself can use it. However, in contrast, the timestamp approach already works out of the box with tar_scm, and has none of the brittleness described above. So IMHO it's a better scheme to recommend in the guidelines wiki page.

...

Regardless, that is not a valid solution, because it breaks instantly when the first tag is introduced to the repository.

And why would that be?

Because the tag offset will reset to zero, violating the requirement that it increases strictly monotonically. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Sat, 11 Jan 2014 08:47:18 +0100 (CET) Jan Engelhardt пишет:

my @args = ("git", "describe", "--match=$pattern", "--abbrev=0", $commit);

Should not it use --first-parent? Otherwise there is risk to pick up wrong tag from merged branch.

chomp(my $len = `git rev-list "$commit" | wc -l`);

Why not "git rev-list --count $commit"? (Same comment about --first-parent) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 14:53, Adam Spiers wrote:

...

OK, so let's assume I have a bunch of tags like: v1.0.1 v1.0.2 etc. We are looking for a programmatic solution which can be automated by tools such as tar_scm. You are presumably suggesting to use something like git describe --match='v[0-9]*.[0-9]'

right?

With the match pattern be an argument to whatever script calls that, because that is invariably user-specific, which is also why the match pattern was an argument in the perl script I had posted.

Right, so I understood you correctly.

Hence, all I really asked of the user is to name his tags such and such that he himself can give a reasonable short algorithm to distinguish them.

You're asking that of the *maintainer*, not the packager.

...

And this glob is necessarily brittle, because very often the person maintaining the upstream repository containing the tags is different to the person maintaining the downstream package,

An upstream can always screw up downstream -- heck, they do all the time with something as banal as release tarballs' filenames, which affects our URIs in Source: lines in .spec files, and /debian/watch.

True, but that's out of scope for this discussion about versioning of snapshots directly from an SCM repository.

So, 'lo and behold, git tags are no different.

... which is why I have repeatedly argued that it is not a good idea to rely on them. OTOH, a timestamp is a timestamp, and *can* be relied on, short of the branch being changed or the history rewritten, in which case all bets are off anyway. We don't need to get too concerned about stuff we can't defend against, but we *can* defend against the unreliability of tags.

...

...

...

Regardless, that is not a valid solution, because it breaks instantly when the first tag is introduced to the repository.

And why would that be?

Because the tag offset will reset to zero, violating the requirement that it increases strictly monotonically.

The offset may move to zero, but in the same go, the tag is increased by "one". Making %version go from 2013.1-1500-gxxxx (2013.1~git1500) to 2013.2-1-gxxxx (2013.2~git1) is perfectly fine.

The tag name is not automatically transplanted into %version. You yourself already described doing that as "almost stupid": http://lists.opensuse.org/opensuse-packaging/2013-09/msg00086.html Therefore this requires the packager to be constantly on the lookout for a tag offset suddenly decreasing, which again is brittle for multiple reasons: - The packager is very often not the upstream maintainer (in fact I'd guess this is true in the majority of cases). - It's not enough to look for a tag offset which drops to zero, because the source service might not run until after several commits since the creation of the new (or first) tag. So it's possible that the offset could drop from (say) 5 to 4, which would be very easy to miss. Worse, if the source service is configured to run automatically server-side, breakage is almost guaranteed after the new tag has been created upstream. It's not at all clear to me why you are so strongly against using timestamping instead, which suffers from none of these problems. Yes, I agree that aesthetically it's maybe not quite as nice, but that's a triviality when compared to the goal of building a robust solution. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andrey Borzenkov (arvidjaar@gmail.com) wrote:

В Sat, 11 Jan 2014 08:47:18 +0100 (CET) Jan Engelhardt пишет:

...

my @args = ("git", "describe", "--match=$pattern", "--abbrev=0", $commit);

Should not it use --first-parent? Otherwise there is risk to pick up wrong tag from merged branch.

That sounds like a good point, but Jan has since proposed a new design which uses a fixed base tag rather than --match, and hence eliminates any risk of picking up the wrong tag.

...

chomp(my $len = `git rev-list "$commit" | wc -l`);

Why not "git rev-list --count $commit"? (Same comment about --first-parent)

+1 :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 17:32, Adam Spiers wrote:

...

...

are available in the git repository at: git://git.inai.de/obs-service-tar_scm master for you to fetch changes up to 3c38cd32941dfc51ac1245c9de91fd63e29969fe: tar_scm: support retrieving the git tag offset (2014-01-11 16:26:46 +0100)

However, please can you submit this to a fork on github,

I don't use github, sorry.

This is not a personal choice, it's how the project operates. github and Travis are an integral part of the development workflow for tar_scm (and many other openSUSE projects). I can't imagine why you wouldn't use github, but if you don't then you'll find it a lot harder to contribute in general. Personally I will not merge a branch for which I cannot conduct a code review in public, and I would encourage all the other maintainers to adopt the same stance, because transparent peer review is a Very Good Thing. Suitable vehicles for public review include github and gerrit (where available), and git format-patch for an email-based workflow. However in the tar_scm case, it has to be github because we already have it tied to Travis for automated test runs.

...

- It's missing a corresponding addition to the test suite. That's a show-stopper ;-)

Surely you can address that, because I don't write python a lot either.

I could but I don't have time. Besides, the person who writes the code should also write the tests. It's called Test-Driven Development.

...

- I don't think "@REVISION@" is the best choice of placeholder name; it's too misleading. Something like @TAG_OFFSET@ would be better.

I would have picked %r because that already gets you a number with svn/hg, but %r is prone to clash with git itself in the future, so *throws up hands in the air*.

Like I said, @TAG_OFFSET@ or similar is a big improvement.

...

- In general I agree that shell variables could be quoted during expansion. But quoting variables like $? and $# is overkill, since they will never be the empty string. Furthermore, in bash the quotes are redundant when you are using the double [[ ]] parentheses:

Alas, the original programmer did not think of using [[ ]] everywhere. So, safest option: [[ and ".

No, the logical conclusion is to use either a) [ ] and "", or b) [[ ]] and no "". Using "" with [[ ]] is redundant and unnecessarily noisy. I agree that consistent use of either [ ] or [[ ]] rather than a mixture of both would be nice, but that's totally orthogonal to the discussion of quoting.

...

...

Specifying the basetag also has the advantage that @REVISION@ does not go back to 0 without the bspkg maintainer noticing, which is also a property that %ct seemed to hold in case a new git tag (e.g. v0.3.3) was created while _service was left at versionformat=0.3.2.something.

Ah OK, you've changed your design! Yes, this is *much* better than some fluffy git describe --match=GLOB logic; finally it addresses the main flaw in your scheme.

I would not call it a flaw.

It was a flaw for the reasons which I have already stated several times - in short, it was too brittle due to the possibility of new tags being added to the upstream project. However, your new idea of fixing the tag string completely addresses that, which I'm very happy about :)

...

There's still a small risk that upstream repositions the tag in question,

That is (even more) haphazard than repositioning a branch head, because tags - unlike branch heads - don't get force-updated when a client runs git-fetch.

Agreed! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Monday 2014-01-13 15:38, Adam Spiers wrote:

...

...

However, please can you submit this to a fork on github,

I don't use github, sorry.

This is not a personal choice, it's how the project operates. github and Travis are an integral part of the development workflow for tar_scm (and many other openSUSE projects). I can't imagine why you wouldn't use github,

Because I don't have to. Git is reasonably distributed that I can host the repository itself. By forcing people to use a specific service, you throw the git effect overboard, and add an entry barrier instead. Just like non-git is said to be.

to contribute in general. Personally I will not merge a branch for which I cannot conduct a code review in public,

I shall gladly post the patchez as mail. (I think I indeed might have only sent the pull cover mail.)

Like I said, @TAG_OFFSET@ or similar is a big improvement.

Then again, if there is no tag, we compute the distance to the history root instead. So @TAG_OFFSET@ isn't totally accurate either. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 14.01.2014 15:51, Adam Spiers wrote:

...

Then again, if there is no tag, we compute the distance to the history root instead. So @TAG_OFFSET@ isn't totally accurate either.

Good point; any better suggestions are very welcome.

I would call it the distance or the metrics. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Stefan Seyfried (stefan.seyfried@googlemail.com) wrote:

Am 14.01.2014 12:51, schrieb Adam Spiers:

...

...

Just like non-git is said to be.

Apples and oranges. Structured development processes are *nothing* like being forced to use an antiquated SCM.

I don't think Jan is opposed to using git (he offered to push his clone somewhere IIRC)

No, he actually did push it - not just offer.

he is opposed to using github. Which are two different subjects.

Yes, I was fully aware of that. But he was claiming a similarity between requesting submissions via github, and using a non-git solution, and that is an apples and oranges comparison (or even apples and telescopes). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2014-01-14 14:18, Adam Spiers wrote:

...

I don't think Jan is opposed to using git (he offered to push his clone somewhere IIRC)

No, he actually did push it - not just offer.

.oO(But putting it up and talking about it on a public mailing list, I at least fulfill "offering" in a legal sense.) ~random thought~

...

he is opposed to using github. Which are two different subjects.

Yes, I was fully aware of that. But he was claiming a similarity between requesting submissions via github and using a non-git solution

The intent was to say: Requestion a github submission would seem to require registering at Github, which _poses_ an entry barrier. A non-git solution would also pose an entry barrier. In both cases significant enough to just walk away. http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-... says "Submit patches in the way upstream wants to receive them" Yes, but tread lightly. A good maintainer should be prepared to accept nonperfect submissions massage the code to his needs, doctrines or development environment. Rejecting a patch that fails to apply with TortoiseSVN even though it is totally compliant to the unified diff specification is something not within my maintainer ideals. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2014-01-14 16:36, Adam Spiers wrote:

...

In both cases significant enough to just walk away.

I really cannot understand this. I have already given two very clear benefits of adhering to a github-oriented workflow, namely transparent peer code review, and automated testing via Travis. Despite this you have stated, without any explanation why, that you are not prepared to spend the 60 seconds required to create a github account

Because it's another account that wants to be managed. It's more than 60 seconds in the long run. I could make it a trash account, but I'd forget those even faster and would have to recreate one everytime. It's all the reason (I would envision) why the kernel is still developed on a mailing list and nothing else - even their bugzilla is optional.

The success of this feedback loop depends on the willingness of both parties to iterate until there is consensus. It will *not* succeed if the contributor simply throws a bunch of patches over the wall and then walks off expecting the maintainer to do the rest of the work.

Well for one, you _called_ for patches. Don't complain if you get some ;)

...

Rejecting a patch that fails to apply with TortoiseSVN even though it is totally compliant to the unified diff specification is something not within my maintainer ideals.

Please can you explain how that is relevant here?

It's one of my experiences where "Submit it in a format the maintainer wants" was driven too far. If the thing is on review on github, good. If not, screw it. I don't care. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Matwey V. Kornilov (matwey.kornilov@gmail.com) wrote:

14.01.2014 17:21, Adam Spiers пишет:

...

Hmm... I think "distance" implies a continuous amount (i.e. float) rather than a discrete number (integer),

The distance implies that

Distance(A,B) == Distance(B,A), Distance(A,A) = 0, Distance(A,C) <= Distance(A,B) + Distance(B,C).

Thank you, that helps illustrate my point. Distance(A,C) <= Distance(A,B) + Distance(B,C) implies the possibility of a "shortcut" from A to C. And in this context, that's precisely what we are trying to avoid. Consider this commit graph, with time going from left to right: .-A--B--C--M / / I----------D I is the base commit, M is a merge commit, and there is a shortcut from I to M if you go via D instead of A/B/C: Distance(I,C) == 3 Distance(C,M) == 1 Distance(I,M) == 2 We are looking for a metric which does *not* have the possibility of shortcuts, because we need our metric to be strictly monotonic increasing, as mentioned many times earlier in this thread. It's actually a one-dimensional metric, whereas most people immediately think of a two- or three-dimensional metric when considering distance. It's also a directional metric, being measured always from a tag at some revision in the past, to the current revision - and never the other way around. So the axiom Distance(A,B) == Distance(B,A), doesn't apply here either.

No matter continuous or discrete.

When I said "a continuous amount (i.e. float) rather than a discrete number (integer)", I meant "as well as", because integers are of course a subset of irrational numbers. So we agree that the term "distance" implies the possibility of a non-integer amount, which again is something we need to avoid in this context. A fourth reason for avoiding the term "distance" is that it's simply too generic. My proposed alternative "revision offset" has obvious connotations of representing a discrete number of hops from a given point in the commit graph, whereas there are a number of ways in which the distance between two commits could be defined (e.g. Levenshtein distance). There's simply no good reason to accommodate such ambiguity when we can avoid it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/23/2014 04:49 AM, Adam Spiers wrote:

Matwey V. Kornilov (matwey.kornilov@gmail.com) wrote:

...

14.01.2014 17:21, Adam Spiers пишет: When I said "a continuous amount (i.e. float) rather than a discrete number (integer)", I meant "as well as", because integers are of course a subset of irrational numbers. So we agree that the term "distance" implies the possibility of a non-integer amount, which again is something we need to avoid in this context.

Adding nothing to the actual discourse other than a nit-picky correction: I suppose you mean to say either "rational" or "real" numbers here as integers are not a subset of irrational numbers. ;) --Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org