Re: [gnome-love] Tinderbox (automatic daily build) for GNOME



Luis Villa wrote:

Up in the wiki:
http://live.gnome.org/MicroTinder/RequirementsDoc

Feel free to edit/annotate. For discussion on the list:

Nice document. I'd like to make a few comments about the document and
the tinderbox/jhbuild mixed approach we made.

Hard Requirements For a New Tinderbox Tool/Setup

    * Supports Big List O'Modules
    * Many build types/sources: 
    * Reporting: 
IMHO these requirements fit well with a jhbuild running inside a
tinderbox loop. And, talking about reporting, it's nice to have both
full reports and summaries of the builds (you can see an example here
http://tinderbox.fisterra.org/all_trees.express.html)

    * Tests:
Adding tests, both unit tests (with check for example) and functional
ones (LDTP/Dogtail), to a tinderbox build loop it's as easy as adding
new phases to a build loop. Furthermore, there's no need to modify the
jhbuild for adding another phases in the build loop, for example, a
phase for linting the code.

I think it's nice to have a separation between the continuous
integration tool (tinderbox) that manages the builds and the tool that
performs the build (jhbuild). What do you think?

    * Documented: How the tool was made to work with GNOME must be
written down so that others can maintain it and use it. We've had too
many tools like this that were made to run once by a mad genius who
then left the project, or lost interest, and so when it broke we just
had to discontinue the service.

IMHO tinderbox lacks documentation. We found not a lot of docs about it,
too much code surfing for configuring :). BTW it could be a good
opportunity for documenting it.

Bonus

These bits aren't necessary, but it is really, really nice if they work.

    * Dependencies:
I agree it's a very nice feature of jhbuild. That's why we used it

    * Notification: 
Tinderbox just executes commands, so if a command can do it, tinderbox
also can.

    * Minimal Duplication of Build Information: Does not add Yet
Another location that must be updated when modules are added/removed-
i.e., must draw build information in some reasonably low-cost way from
the canonical jhbuild moduleset. If this requirement isn't met, better
have someone damn dedicated to keeping it up to date.
    * Distributed:
It seems a tinderbox-made requirement. I think a good sample is any of
the Mozilla tinderboxes (for example the Firefox build
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox)

    * Easy to set up/maintain: 
It's not difficult if you know where are the things you have to change
;). As I said in my previous mail, I think it could be a good idea to
distribute debian/tarball/any_other_kind_of_package with a preconfigured
setup for clients. Anyway I think this point is very connected with the
documentation one.

    * Builds Ekiga:
Neither can I :).

    * Active Development Community:
I fully agree with you.

Regards.



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