Good point, Cedric!
Duplicate contextual information is acceptable, especially because not all contextual information will always be the same, even in your example:
failureModuleName=hackyKernel)
A build can fail due to distinct problems in different modules. The context helps identify interesting information about the specific build failure.
For me, the most important representational issue at this point is not to focus on achieving third normal form or whatever, but rather to figure out what we want to have as 'required' vs. 'optional' fields.
For example, why is "project" a part of "additional information"? Why isn't it a required field? Do we envision any analyses on build data, now or in the future, that don't require identification of the project(s) to which it is attached? Given that Build is one of the few SDTs that requires an explicit Project value to be attached, should we make that more obvious in the representation?
I also don't see the top-level target invoked in this representation. Should that be required or optional?
Before you proceed, perhaps Cedric (Ant), Mike (Make), and Aaron (Harvest) should get together, talk about their needs from their various build perspectives, and come up with a joint proposal for a Build SDT?
Cheers, Philip
