> > 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? I think the logical basis is to encode as little extra information at the ID as possible, while still make it useful for humans. If you needed to *tell* (not text) your colleague to try a specific compose, would you rather tell him to use compose afeg634kga or 20160225.0? And it's not just about telling people, but often you need to keep some identifiers in mind. If you need to compare today and yesterday's compose, is it easier to run your tools on 20160225.0 and 20160224.0, or afeg634kga and eb96xve458, and remember which is which? The date component of the ID is unlikely to get ever obsolete. The same for that day's index. I'm not arguing about the compose type identifier, that one very well can be. But hey, what prevents us from changing the ID format if needed? It's just code. It's more about balance, rather than designing something that won't be necessary to change for the next 1000 years. > > 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. I agree that it would be very helpful to be able to assign some specific names to certain composes. And also that it's much better to be able to decide about the name (i.e. the meaning) of the compose after it is finished, not before it started. (So e.g. we don't need to say "this is Alpha RC1" when starting the compose only to learn that it failed and we'll end up with Alpha RC3 as the first successful Alpha RC compose. It's much better to compose first, and then be able to say "this is Alpha RC1"). I'm sure there are technical difficulties about this, but if it can be done, great. But that does not imply to me that we need to keep the compose ID as meaningless as possible. > > > 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. Random strings do not sort in chronological order. Growing numbers and dates do, so they're easier to work with. Dates are more memorable than numbers, so they're easier to work with. But you can still consider them as "meaningless", if you want, because it's just a specific number increment format. You can basically consider it the same as any other growing sequence with a custom format. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
