The Bonsai Project
Bonsai is a really cool idea on how to "see" changes taking place during a development cycle. The original implementation was by Terry Weissman, first done in TCL, then later ported to Perl. It's built to run against CVS using Perl, MySQL, and your favorite webserver to display checkin history, log information, diffs, and other assorted pieces of information in easy to parse HTML.
Bonsai has sort of been the red-headed step child of the Mozilla webtools, especially compared to the much more active and widely installed Bugzilla, but it's finally starting to get some much needed love.
Getting the source:
You check it out from our CVS server by doing
cvs checkout mozilla/webtools/bonsai mozilla/webtools/registry
Please see our CVS page for information on using our CVS server. (The Tinderbox and Bonsai sources are currently only available via CVS.)
Current Focus:
There are a couple of major problems with Bonsai that need to be resolved so that it's less embarassing.
Performance - Bonsai can be, under the right circumstances, egregiously slow. In scenarios like Mozilla.org, which have a lot of checkins and a lot of code, the right conditions can happen a lot. Even worse, the things that make Bonsai go slow will also cause your server load to go sky high and make everything else go slow. This would be a Bad Thing(TM). There has already been screaming. More specifically, some things to look at are:
- showcheckins.cgi - this is sort of weak area for a couple of reasons. One, from a user perspective, it's more or less equivalent functionality to cvsquery with some UI differences. Two, when the batch-N.pl files it reads to generate the checkin table start to get really big (say 700 or more checkins), it can cause addcheckin.pl to get really really really slow.
- dolog.pl/handleCheckinMail.pl/addcheckin.pl - the whole "parse the CVS log, mail formatted log information to a perl script, let that perl script parse it and pass it to another perl script which finally inserts that information into the MySQL database" has just GOT to go. DBI is a wonderful thing.
Security - There's been some attempt at cleanup, but it has not gone through the same
anal-retentive analysis that Bugzilla has. Additionally, Bonsai doesn't have the concept of user
logins the way Bugzilla does, so securing certain pages, such as parameters page, becomes
a bit more challenging. At the very least the database information needs to be put someplace else.
Update: editparams.cgi access tracked as
bug 45579 and now fixed.
Documentation - All of the webtools had READMEs that used to start with "This project isn't particularly well written or documented". For Bonsai, this hasn't changed all that much. If you're trying to install or administer Bonsai currently, you're likely in some amount of pain. Both developer docs and user/admin guides need to be writen.
Administration - Having to manually edit treeconfig.pl to add or update a Bonsai page is lame.
Future Plans
There's a couple of major areas of discussion about what to do next. The two top ones are currently:
Enable more interactive source control
One way is by telling Bonsai to mirror code. Code mirroring is a way to smooth development across multiple projects, by ensuring that code changed in older branches, perhaps representing sustaining engineering efforts, propogates down through subsequent branches, eliminating regressions. This is just one example of where we can Bonsai do useful things beyond basic reporting. Many more discussions to follow. Preliminary work in this area was done by Tom Jones, and the source can be obtained from the cvs-mirror directory in the Bonsai source tree.
Make Bonsai report against SCM systems other than CVS
Right now the top first candidate is Perforce. This is going to be an interesting challenge for a couple of reasons. One, in CVS, history is maintained in RCS log files on a file-by-file basis. Bonsai captures this information and inserts it into a database for subsequent retrieval. In Perforce, the system itself is a database, so all of the manipulation Bonsai currently does around database transactions needs to be abstracted out in some useful way.
Project Participants
| Tara Hernandez | tara@tequilarista.org | project owner, oftime slacker, contributor |
| Josh Soref | timeless@bemail.org | main QA, principle nag, contributor |
| Myk Melez | myk@mozilla.org | contributor |
| Dawn Endico | endico@mozilla.org | contributor |
| Tom Jones | thj@bluemartini.com | contributor |