On Fri, 2016-02-26 at 04:20 -0500, Kamil Paral wrote: > > > > > > > > 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. Oh, but you referred to running tools. If you want to order the contents of a directory by their creation date, well, that was a problem we solved a long time ago, which is why I don't have to call all my files 20160224-filesize-name , just in case I want to sort them by date and then by file size. ;) > 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. But with Pungi 4 we keep failed composes around, so you don't really know which of yesterday's composes you want to compare against. The concept of "yesterday's compose" is pretty arbitrary, really - it relies on an assumption that we want there to be one "compose" per day. Even though Pungi 4 calls snapshot builds "nightlies", this is not necessarily true. We want to do distribution CI, remember? We want to be firing off composes more or less every ten minutes, in the ideal case. > 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. Here you're making another assumption, though: composes will be stored in directories named after their CID. Why? It's not even true, as it happens, I don't think. It's true for nightlies, but 'production' builds are output into directories based on their *label*, IIUC, not their cid. -- 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