On 07/29/2009 06:30 PM, Kevin Fenzi wrote:
I took warrens script that he posted to fedora-devel and tweaked it up
to work on all the spins (not just desktop) and provide some more
I can get it running daily on spin1, but I have some questions first:
- I assume we want to publish the logs so we can see trends and/or when
things don't compose. How many should we keep? They are pretty small,
so we might want to keep a lot to notice trends on size, etc.
I keep one month worth of logs, so that the trend can be analyzed over a
longer period of time. That just concerns the logs though, although I
also keep the spins around for a longer period of time.
- We have been talking about publishing weekly isos. Is there a
particular day we should try and publish from? Or should that be a
manual task as needed? (ie, before test days, or requests).
I would recommend releasing them in time for a weekend run of testing;
maybe Thursday to Friday night would be most appropriate for the spins
to finish composing, assuming it takes less then 1 day to download?
- Currently the output is a log file for each spin.arch from livecd
creator. Do we want any other output? A FAILS/WORKS of some kind?
Sending out FAIL notifications might help maintainers (including the log
files or link to log files), and sending out SUCCESS notifications might
help triggering maintainers to download the spin (including the link to
- If we setup weekly isos over to alt or someplace, how many should
Two series should suffice, but maybe we want to have the last successful
compose in there? From the Spins SIG point of view though, we would like
to be notified when a spin (still) fails over a period of two weeks, no?
- When should the script run? It should be after rawhide, but is
a way to tell when that has happened?
- Should we also be composing the kde and desktop spins? I would
suppose that would be ok, but are they really part of our SIG? should
we contact them and see if they want this?
Yes we should compose them, because they are a dependency for some of
the other spins; e.g., if kde spin fails, some other spin is going to
fail most likely for exactly the same reason the kde spin failed in the