(courtesy of Martin Robinson, who introduced the notion of Garderner in WebKit world of fame)
- Keep the tree green: the gardener on a given day will diagnose all bot redness and try to form a hypothesis for each failure. In my experience there are several types of failures:
- The GTK+ port is lacking some feature or has a bug: In this case the gardener will figure out exactly what the problem is, open a bug with as much information as possible including test diffs and links to relevant bugs. The gardener will CC any people involved in WebKitGTK+ who would might know how to fix the problem.
- A test is missing expectations or needs new expectations: The gardener will generate new expectations after verifying that the tests seem to work when run manually or by looking at the expected results.
- A DRT feature is missing: The gardener will open a bug. The idea is that we will completely avoid skipped tests with no information about the failure.
- If the tree isn't red, the gardener should be able to choose how to spend the day:
- Generating results for tests that do not have results (soon this will include pixel results as well).
- Diagnosing and opening bugs for failures that do not have open bugs (there's a huge list). This also includes unskipping tests that are passing.
- Implementing missing DRT features. There are a ton of these and we need to kill them. Using DRTSupportGtk we can do it without making API decisions.
- At the end of the day the gardener should keep a very simple log for tomorrow's gardener, so he can follow up with any pending investigations. This will also help us keep track of newly skipped tests. This could just be a wiki page.
Check also chrome gardening instructions: http://dev.chromium.org/developers/how-tos/webkit-gardening