On Wed, 2016-02-24 at 06:43 -0500, Kamil Paral wrote: > If you can distill everything above into a 30-seconds explanation how > things work, which is easy to understand and doesn't sound like a > university paper on nuclear physics merged with philosophy, then > maybe :) Because it can be easily done for "20160401.0.c". And often > the KISS principle is much better than higher abstraction, which is > more universal and "cleaner" but much harder to grasp. It's very > possible that I simply did not understand your revised proposal, but > "20160401.0.c" seems to strike the balance between simplicity and > usefulness to me. > > If you mean that we will have a sequentially growing integer number > of any kind of compose, and we'll define everything somewhere else > (PDC), then it's probably cleaner, but it's harder to use by humans > and therefore less useful. But the compose has dozens and dozens of properties. Why decide to specify just a couple of them, not in the metadata with all the others, but in the identifier for the compose? On what logical basis? And especially, conceptual properties that might become obsolete, independent of the process of actually producing a bunch of bits? The problem with the "human use" notion is it's based on a fundamental misconception: that we have to use the compose ID as the compose's name for public consumption. We don't. In fact, the idea that we do is where all the trouble starts. We can take a compose with the ID "2378" or "afeg634kga" and put it in a directory called "Fedora 24" and send out emails calling it "Fedora 24". All the "compose ID" really needs to be is a unique key for a database. Tying some quite arbitrary notion of what the compose "is" to its compose ID, and then enforcing that in the tool that builds the compose and assuming that "ID" == "name", comes with two fundamental problems: i) It ties the - fairly generic - action of "building a compose" unnecessarily to a particular conception of a release process ii) It makes it unnecessarily difficult to separate out the process of deciding what to do with a compose from actually composing it. It makes it unnecessarily difficult to build a compose, see if it works, run some tests on it, *then* decide it's "Alpha 1". You can still *do* it, I guess, just by ignoring the compose ID as hard as possible - but the current tooling is kind of built on the assumption that the compose ID is deeply meaningful as to the compose's nature. > Putting the date into the ID doesn't harm anything (it's just a > particular type of sequentially growing numbers) and helps human > usage a lot. The snapshot type identifier might be more questionable, > but still seems more useful than not. It's useful information, it shouldn't be in the compose ID. I wouldn't really mind using the date, I just like suggesting that the ID should be an incrementing integer (or just a random unique string) simply to emphasize the point that I think it's a bad design for the ID to act as a store of (just some) metadata about the compose. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
