immediate needs

• fix the atom patch to be valid atom by generating 'id'
• make the planet have a micro-status box in the upper right hand corner, showing only build fail/success, last three for each 'category' of tinder

potential cleanups

• make jhbuild install somewhere other than ~/bin/, and make the tinder script look for jhbuild in that location
• figure out how to not build mozilla every time, and build gnomemeeting (currently disabled because I couldn't get the right deps on my original build box)
• maybe put everything tarball based into the pre-populated area? (audiofile, hicolor-icon-theme, etc.)

near-term wishlist

• make web output handling more flexible- teach the script about scp or other methods for posting (besides just dumping straight to a directory.)
• consider regularly deleting logs older than the last successful build- just have a SUCCESSFUL symlink, maybe?
• record when a module last successfully built, so that we can link to bonsai and/or fall back to a last known good build with -D.
• put binaries somewhere
• open vnc after build, hook in vnc2swf, run ldtp test stuff
• multiple branches (stable/unstable)(gcc3, gcc4)(64, 32 bit)
• add non-core modules, dasher and gnumeric have specifically requested this
• if build fails, find last committer to module and email them
  • {{{cvs history -D $DATE_OF_LAST_SUCCESSFUL_BUILD -a -c $MODULE/

cvs log -b -N -S -d"2004-12-01<="}}}

• alternately, just mail $MODULE-maint@gnome.org, which works for all modules where the MAINTAINERS file follows the specified MAINTAINERS file format.

• Test packages against special tests - see KDE Test Report as an example

more stuff, still unorganized

jhbuild/frontends/tinderbox.py:

• in init we want to create an fp that will hold the top-level index, probably open it then? [This would be to allow us to create/edit a top-level index.html, instead of doing the current big directory with no useful data.

  • The alternative here is to output the information in index.html in a machine readable format. This would make it easy to do a scan of all the builds and produce whatever type of indices/summaries would be useful (possibly even combining results of multiple tinderbox architectures?). Perhaps even per-module summaries would be useful. This would also handle the case of removing data for logs that have been deleted. -- JamesHenstridge 2005-03-08 03:51:46

• in end_build, if failures: write failure information to the top-level index

if a build fails:

• get time of last successful build

• do 'cvs history -D $DATE_OF_LAST_SUCCESSFUL_BUILD -a -c $MODULE/', write output to module log

• link to log
• currently we just do crappy pointing at gnome cvsview- which isn't always right.

provided there is a bonsai or viewcvs available, this could be a link like the following:

1. http://cvs.gnome.org/bonsai/cvsquery.cgi?dir=$MODULE&branch=$BRANCH&date=explicit&mindate=$LASTBUILD_DATE&maxdate=$NOW

2. http://cvs.gnome.org/viewcvs/$MODULE?view=query&branch=$BRANCH&date=explicit&mindate=$LASTBUILD_DATE&maxdate=$NOW

This should be much better than a straight ChangeLog (which currently only gives you HEAD, rather than the branch actually being used) -- JamesHenstridge 2005-03-08 03:51:46

* multiple people seem to want output put somewhere. .po files for jdub/ubuntu (he emailed about this), doc stuff for shaunm

other related projects

• samba build farm - http://build.samba.org/

• postgres build farm - http://www.onlamp.com/pub/a/onlamp/2005/02/24/pg_buildfarm.html

bluesky wishlist

• [this one probably belongs in jhbuild proper] could build a pattern matching database of 'if error foo, then install package bar' and just autodetect presence of yum or rug or apt then install package name- for most things, should work fine (some packages will have different names, part. on debian) see patch support in tarball.py. Note that this could build off the collection of errors/solutions already being built in the wiki.
• need to support patches! can screw complicated pattern matching; just assume that it sanely applies in the top-level directory. If it doesn't, rebuild the patch and distribute it some other way.
• if this built packages from spec files in the cvs dirs on a daily basis, could that resurrect gpp?
• would be nice to have a qemu setup to run solaris x86 + tinderbox. Would get us some solaris testing without having to have someone admin a solaris box.

CategoryJhbuild