All layout test bugs already have the LayoutTests label. A lot of these bugs were created automatically and have a generic "X Failing Layout Tests" title. Some were created as a result of a merge. Some have been looked at, some were even started on. You may even notice that some bugs are marked as WontFix, because they don't have any meaning beyond reflecting a group of failing tests.
This is why we created another label -- LTTF, to distinguish the LayoutTests bugs that we've already identified as potential causes of problems. These bugs typically have a good, meaningful title and comments about the specifics of problem. The status of the bug is marked accordingly (see status descriptions in bug tracker).
You can participate in the following roles: - Finder -- looks for the root causes of layout test failures, narrowing the problem to be as specific as possible. For instance, taking from "Canvas gradient-related tests are failing" to "Implement focal point for radial gradients". Finder's output is high-quality, nicely chunked bugs that have good description of the problem, cause, and a possible solution.
- Fixer -- takes bugs, produced by a Finder, and actually fixes them
Of course, you can mix and match -- we try to stay flexible. Monotonous work is prone to burn-out, and we certainly don't want our spirits broken (well, maybe a couple of times).
A basic workflow for the Finder is:
- Take at a line in test_expectations that corresponds to a bug not yet with LTTF label. Make sure the test is not flaky. At this point, we are limiting the scope to only non-flaky tests. We will tackle the flakes later.
- Figure out what the cause of the failure is.
- Look at existing LTTF bugs and if the cause is already identified, change bug number in expectations. Add comment in bug with the expected failure.
- Otherwise:
- change the bug title and add description to explain the cause,
- set the bug status to "Unconfirmed",
- add the LTTF label,
- ping another finder to review the bug.
- Once the finder reviews the bug and agrees on the cause, we can set the bug status to "Available".
For a Fixer, the workflow is: - Pick a bug that has "Available" status.
- Change it to "Started" and set yourself as owner. If you're not yet ready to start work on it, but really, really want to own this bug, use "Assigned" status.
- Fix the problem.
- Once fixed, remove corresponding expectations from test_expectations, and close the bug (set status to "Fixed").
Occasionally, we may stumble upon a missing feature implementation of which may seem outside of the task force's scope. Please bring those up on chromium-dev mailing list and we'll determine what to do on case-by-case basis. |
|
