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.

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

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

Attic/MicroTinder/ToDo (last edited 2013-11-23 01:31:23 by WilliamJonMcCann)