> > 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.
Yes, but I meant manually running them. Diffing two trees of files. Or pointing virt-manager to the first compose of yesterday. This kind of manual usage. > > 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. ;) Yes, if you have them locally and all the file properties were kept. If you see the list in a web browser, then it depends on the webpage whether it shows you and allows you these operations. > > 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. That's why I would check STATUS file first, if I needed it. If there were 3 composes yesterday I need to find the first successful one, it's much easier for me to see each compose's STATUS file than write a query for PDC. > 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. Not one per day, but a small number. If we do 144 composes per day, I admit that the benefit of having friendly compose IDs begins to vanish. The date part is still very useful, but with so many composes every day, it will get harder to perform any kind of manual inspection/comparison/testing and we'll need to rely more on tooling. > > > 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. You got me here. The whole time I expected the compose ID be the same as the directory where it is stored (except for cases when we decide to give it human friendly labels, like Alpha RC2, which is even better). So I was not arguing that much for friendly compose IDs, but rather for friendly directory names. That is more important to me. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
