Re: A modest proposal: Pungi 4 compose process (what we call composes, when we do them, what information we need about them)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux