On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote: > On Sat, 15 Nov 2014, Raphael Hertzog wrote: > > On Fri, 14 Nov 2014, Ian Jackson wrote: > > > > What exactly is your use case you feel this is essential for? > > > > > > I think this discussion is in danger of going round in circles. > > > I'm going to leave it here and let Raphael get on with it. > > > > I understand Ron's logic and there's certainly value in questioning the > > need for something. But this is always a question of cost/value. > > > > Even if we don't have an immediate need for this property, the problem > > is that we can't always envision all the ways people will want to use > > the repositories (isn't that what you were trying to tell me about > > how upstream can use git?) and I'm pretty sure that dropping the epoch > > will be annoying to someone at some point. And the cost of not dropping > > the epoch is not very high.
Yes, absolutely. I think this got kind of derailed through failing to understand (and answer) the very simple question I asked. When I asked "Why include the epoch in tags at all?", that was not some politically correct euphemism for the statement "I object to including them" (which I certainly do not), it was an actual question. If the answer to that is simply "it's relatively harmless, has minimal cost, some things already do it, and it may be a useful visual cue to human users, and that's all", then that's a perfectly good reason. If the answer is instead something like "I want automated tools to be able to assume they can perfectly reverse the mangling and assume some semantic meaning to the text in the tag", then we're into Broken By Design territory and we really need to look more closely at *exactly* what it is that people want to do and/or assume, and we probably need to look at less fragile solutions that really do satisfy that need. But we can't suggest things for that without some clear statements of what exactly are the use cases people have in mind. I'm never a fan of discarding information unless you're certain you won't ever need it back. But information that you can't trust is always a mixed blessing, and epochs themselves bring their own extra caveats too. I was hoping to get people to think about this in a bit more detail than they'd already appeared to and have a sensible discussion to enumerate the pros and cons, and possibly any warnings we ought to explicitly offer about this. Having people dig trenches for a simplistic "for or against" war isn't really going to solve anything, or advance us to anything better than what we already have. > I fully agree. Please, lets just keep the epoch which is the safer design > choice anyway, and get done with it. Henrique, would you care to elaborate on your definition of "safer"? I already pointed out some ways it's not. A well reasoned middle ground might let us offer people some actually useful advice about this in a way that "just bury your head in the sand and pretend everything is ok" would not. > Also, we have a fully reversible, human-friendly mapping to deal with Unless you really do something crazy, like URL encoding (which I don't think we should do, the cost to humans is way higher than the benefit to machines, and tags *are* for the benefit of humans), the manglings to the allowed ref names have never been guaranteed to be reversible, and we have a decade worth of existing practice where they definitely were not. They still aren't guaranteed to be so even with this convention, because there's no hard guarantee that everyone or everything will use them. And even if they did, I still don't think you've covered every combination of things that are illegal in a git refname which might need to be mangled here. The really crazy cases might be rare, but just because you've never hit them doesn't mean they can't or won't ever exist in a way that means someone one day will need to deal with them. Why paint those people into a corner when there are fairly easy ways to not do that? > Whether the upstram version string is compatible or not with the Debian > version namespace and the Debian git-tag version namespace is a non-problem: > the upstream version WILL have been reduced to something compatible to be > usable for the package version in debian/changelog already, anyway. > > Therefore, there is no space for ambiguity here. % and _ are *illegal* in > the Debian version namespace, so they can be freely used to translate from > the Debian version namespace to the Debian version git-tag namespace. > > And anything that compares the upstream version namespace and the Debian > version namespace directly (or via their git-tag namespaces) is Utterly > Broken in the general case anyway, even if it will often just work > (particular case). Anything that assumes you can always determine the exact release version from a tag name is Utterly Broken in the general case too. I don't think conflating these things is helpful here. The question of "should we recommend people include epochs in their tag names" is entirely separate to the question of "how should tools determine the version of a package at a particular ref in the repo". Individually, we can answer those things sensibly. If we try to pretend they are the same question, people are just going to argue things that are fairly self-evident and that we all agree on in a tug over war over which point is more important (to them). Which I think squanders the opportunity we have here to actually really identify a more complete set of best practices from the knowledge people have accumulated. As I said elsewhere, if all you want to do is rubber-stamp "this is how I work with gpb and it Works For Me", that's fine. But it's not what this document is currently claiming to want to do. I'm genuinely interested in the questions of Best Practice. I'm far less interested in arguing which current practice is "near enough" to form a "white lies for children" simplification that's only good for "educating" novices. I really think we can also have the latter, built on an exploration of the hard problems that even lots of existing "veteran" users haven't really thought through to completion before now. That would be the kind of show of Debian Excellence that I remember and love. Cheers, Ron -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116052730.gk10...@hex.shelbyville.oz
