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. _______________________________________________ gnome-love mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-love
