gecko-dev/webtools/tinderbox3/tinderbox-todo.txt
john%johnkeiser.com 9eb1d71925 Add license
2004-05-19 15:49:34 +00:00

70 lines
3.8 KiB
Plaintext
Executable File

New Tinderbox Features:
- easy to install both client and server
- web administration of everything in the server
- database-backed
- kick clients during builds
- upload patches for clients to try out
- incremental logs / status
- clients can throttle (not send build_starts more than a minute)
- allows tinderboxen to build at a particular cvs co date and branch
- can configure tinderboxen .mozconfig
- security (logins / passwords)
- clients upgrade themselves if there is a new version of themselves on the server
- builds can be uploaded and linked to for testing purposes
- can clobber a tinderbox
- client setup works without anything but build tools installed (ed: need to ensure environment is set up properly)
- uses fast-update (every 6 hours it re-syncs with checkout)
- does not bother building if there were no changes (build can be forced with build command)--minimum cycle time
- uploaded binaries are intelligently deleted to keep a hard quota but still have a useful range of binaries around
- a nice log viewer that lets you look at the log page by page and see a summary of progress
- client can be a switching tinderbox (lets you have multiple builds with different configurations / branches / etc., cycles through them one at a time)
Todo:
- tests
- graphs
- xml interfaces for botbot and such
- sidebar
- require build administrator email
- add hostname into the machine_name automatically
- have client report versions of files it updates so a correct "C" letter can happen
- allow clients to send status via email
- allow server to receive status via email
Bugs:
- add proper constraints into the DB
- make tree_id, make most tables link to it (inputs to cgi scripts still use tree name)
- round times to nearest minute, ensure nothing goes beyond bottom of shown tree
- 1-minute cycles sometimes don't show up (possibly related to above)
- .mozconfig can run arbitrary commands, maybe make it only possible to do ac_add_options from server-specified .mozconfig
- popups should show up closer to where they do in current tbox--it looks nicer
- popups don't work in IE
Would be nice:
- * midcheckin detection
- log brief-izing script (makes logs brief so you don't have to *remove* them)
- targeted log quota script (same as build deleting script)
- allow machine to move from tree to tree
- auto-reload feature
- "C" checkin list on a build
- allow Netscape to build as well as Mozilla, based on server you connect to (server specifies that Netscape should build, maybe cvsroot too) - close, needs testing
- make Kinderbox possible (build on one machine and test on another)
- upload installer builds
- page showing a list of all builds for a particular time range or even forever (possibly using ShowBuilds)
- don't upload a build unless it is binary-different from the last one you uploaded
- allow creation of a machine without a machine connecting (this allows
pre-configuration of branch and .mozconfig)
- show status as text, not number ("upgraded client" instead of 302, for example)
- allow builds to be ftp'd up
- * allow tree to be rsync'd instead of cvs'd
- normalize patch roots so that a patch made in content/html/content will still apply
- * allow people to register for notification when a build (or builds) fail
- * "auto-checkin hook" when someone checks in, they are added to the hook and notified when a build they checked in to fails
- support horizontal as well as vertical layout
- ensure output prints OK
- make sure non-Mozilla/IE browsers can read all the information it need and add comments (i.e. make links for them)
- tbox3 on Solaris should print stack traces of codedumps using /usr/proc/bin/pstack, dbx or gdb if mozilla or any test tool created a coredump.
Test:
- --notrust and friends
- changing cvs co date around (esp. having one and then not having one--do we need to unstick the tree?)