Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

FATE’s Ugly History

February 19th, 2008 by Multimedia Mike

Tonight, I finally implemented and deployed a build history browsing option for the FATE Server. Yeah, FATE just got a little uglier and crowded tonight in the process. But if you visit the main page and see that one of the build boxes is red instead of its recommended green, you can browse the corresponding history to learn approximately which SVN revision broke the build. I say “approximately” because the commits can get stacked, e.g., a build/test cycle is occurring and 3 new changes are committed before the machine has a chance to check out code again and build. In that case, the history browser will at least provide links to each of the 3 commits in the online SVN browser which allows a developer to inspect each change message that went into a build.

I hope to implement a similar history browser for test results so that a developer can analyze which SVN commit broke a particular test.

With these history features, I think I am finally finishing with the most basic useful features. Too bad the website looks so bad with its retro-1995 feel. Unfortunately, I have roughly zero experience in making websites pretty. What I care more about is that the website is functional for the nominal FFmpeg developer. I’m disappointed with how crowded the main page is becoming. However, I have had plans from the beginning about how to distill that data down to a few essential pieces of information. Plus, I have ideas about how to make the front page orders of magnitude faster to load (hello, caching strategy). Though I might be the only person who really cares as I obsessively check the FATE status throughout the day.

Posted in FATE Server | 4 Comments »

4 Responses

  1. Reimar Says:

    I may not check it “obsessively” but I still notice that sometimes the page is truly dog-slow to load :-)
    Personally I do not consider the main page really crowded yet, but I guess that will change if there are a few additional machines.
    Maybe as a first step just adding an optional filter to show only configurations that failed would help out?

  2. Benjamin Larsson Says:

    I’d like to have something liek this:

    http://build.rockbox.org/dev.cgi

  3. Anonymous Says:

    great work mike!
    — pete

  4. Multimedia Mike Says:

    That RockBox summary page seems to have come a long way. I seem to recall that it used to be much more cluttered.

    I am thinking along the lines of a page that has some sort of summary box for each machine type, perhaps just illustrating that everything is okay or that there are problems to be analyzed. However, that will still take a lot of database queries, same as the current front page (which is why it loads so slowly). I have some ideas about how to generate a main index page cache only when new data is submitted.