On Thu, 2016-02-25 at 06:00 -0500, Kamil Paral wrote: > > > > > > > > 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? That's reasonable, but then an integer isn't that hard to say either. But as I said, I wouldn't really mind using something date-y too much. It's the other bits I really don't like. > 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? Except this doesn't work, because the compose before 20160225.0 is not necessarily 20160224.0, it might be 20160224.3. You just don't know. The proper way to do this is to go ask PDC for the previous completed compose from the same series, and if you're going to do that, it doesn't matter what the format of the identifier is. (Believe me, this is something I'm literally in the middle of writing :>) > 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. Well, it's kinda the entire workflow design I don't like. This is *already* causing a bit of friction because RHEL and Fedora don't necessarily have the same notion of "compose types". We have the same problem with the label, because RHEL and Fedora don't necessarily have the same notion of "milestones" and "respins" and so on. Sure, we'd still have the conceptual mismatch if these things were metadata properties - but at least we'd just be dealing with handling simple, discrete properties, not different ways to parse concepts out of smooshed-together strings. It's hard to explain my thoughts about the whole thing without writing another essay, and I don't want to do that, but it's basically about the whole flow from defining what the inputs of a compose are through to deciding what 'labels' to apply to it and where to sync it to. Too many of the things about that process are built into compose tools and awkwardly expressed, when they should be properly separated out into code and configuration and consistently expressed as discrete properties. > It's more about balance, rather than designing something that won't > be necessary to change for the next 1000 years. What I'd like to happen is to make it so that when we *do* change, change can be easily and minimally accomplished. That's really what I'm thinking about here: how hard is to to say, hey, from now on we're going to build a candidate compose every day and have a tool whose job it is to decide whether to call it an "RC" and sync it to the mirrors? How hard is it to say, from now on we're not going to have a "final release" but we're gonna build these four sets of outputs on different schedules and ship each one after some testing? Right now my belief is that making those kind of changes is unnecessarily difficult because of all the excessive bundling of concepts and processes into the code of pungi, and I don't like that. > > 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. That's not really my main *goal* here, it's not like my starting point is "make the compose ID meaningless!" and all the other stuff is just a justification for that. My hope is that the compose process can be more flexible and modular and smarter. The compose ID is really just kind of an avatar for all the features of the current design which make that hard. > > > 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. Sure, like I said, it's more that I'm making a rhetorical point. But really, I believe that if we're going to all the trouble of designing a metadata format and providing compose metadata and an entire webapp for letting you *query* compose metadata, the way to sort composes is to get whatever property you want from the metadata and do a sort on that property. "Date of compose" is *already* a metadata property. Why does it makes sense that if I want to sort by any other means I go look in the compose metadata, but if I want to sort by date I say "oh hey I can do that by sorting by compose ID!"? The job of the compose ID is to uniquely identify the compose. It's not the compose ID to sort composes. That's the job of the compose metadata. I'm just trying to promote that way of thinking. -- 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
