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