On Thu, 2011-04-14 at 11:45 -0400, James Laska wrote:
On Thu, 2011-04-14 at 06:44 -0400, Kamil Paral wrote:
Hello,
I have been spoken to by Marcela Mašláňová about "The Future of FTBFS". See this thread:
http://lists.fedoraproject.org/pipermail/devel/2011-April/150310.html
IIUC (Is there an abbreviation for "I'm not a developer"?) the problem is as follows:
Matt Domsch from Dell used to rebuild *all* packages from Rawhide periodically (so-called "mass rebuild"). When some package failed to build, he reported errors against that package.
This testing ensured we often find build problems early in the release process. Without it there is a chance that we discover the build failures only when a new build of that package is required, which may be shortly before final release or even after that. That's a problem.
Mass-rebuilds in Koji are not done frequently (maybe once a year), so they can't cover this issue.
Matt can't do this testing anymore. Marcela asked me whether AutoQA could be used for that. Matt's tools (scripts, etc) should be available.
I asked Marcela to inquire more about some details. I have attached the discussion below (read from bottom up).
What are your thoughts? Is that something AutoQA can and should handle? Do we (will we) have enough hardware to be able to do that? According to our current priorities, is that even something we are able to implement in some reasonable time (under a year)?
As for the last question, I think it clearly fits our current effort to provide generic Fedora-related tests. OTOH we still have many generic tests to finish (either un-started or semi-finished) and before that we need to concentrate on architecture first (ResultDB etc.). I'm afraid to have complex tests running without solid architecture basis beneath it. In that respect unless we all agree this is a top-priority next-to-work-on test (and provided that we have enough hardware for it) I don't think we're able to run it soon.
Do we need some more information I should ask Matt for?
I can't see a ton of technical limitations on why AutoQA couldn't manage this workflow. The big issue that jumps out to me are resources (homand and hardware). I don't believe we have hardware capacity to run this workflow now, can the current hardware be loaned to Fedora? Additionally, running, maintaining and reviewing the scripts/results appears to be a significant effort. Is there anyone (rel-eng or devel) volunteering to maintain the scripts needed for rebuilds?
I think I can help with that (although I am afraid that my overcommit rate is high right now :)) I'd be happy to do that for Fedora, but I'd like to see the scripts and evaluate the effort before I commit on doing it.
Thanks, James _______________________________________________ autoqa-devel mailing list autoqa-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/autoqa-devel