> > 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. I do, immediately, and that's the point. When I see all the composes in the pungi directory, I can immediately see what is the today's latest one, and I see which ones are yesterday ones. In my example above, I said "compare today's and yesterday's compose", not "today's with the previous one". So I can immediately understand that 20160225.0 is the first compose today, and 20160224.0 is the first compose yesterday. By looking into that dir, I can also immediately see that 20160224.3 is the last compose yesterday. All of that quickly and naturally, without querying PDC. I wouldn't be able to do none of this if we had just growing sequential numbers. > 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. Yes, machines should do this, definitely. But as a human tester, I'll hate this, because it wastes my time by forcing me to go to PDC to learn even basic trivial properties like "when was this composed?" or "what release is this related to?", every single time I want to work with this. > 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. Yes, that I completely agree with. > > 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. Yes, definitely. > "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!"? Because not all of us are machines (you can't hide it anymore!:-)) and for basic operations we don't want to go to PDC. We can get some basic semantics from the ID for free. Of course we must not overdo it. Machines, on the other hand, should always go to PDC, and not parse the the ID, yes. But if we offer a good API, I believe that is given. And even if they do parse release and date out of the ID for some very simple use cases, that doesn't seem to be a problem, and once we have some problem with that, we can fix those systems to start using PDC instead. > 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. I understand that and I agree with you in general, but let's not go too far. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
