On Thu, Oct 15, 2015 at 11:46:30PM +0000, Finucane, Stephen wrote: > Hey, > > First pull request (request-pull style, that is). Hope I've done > everything correctly :S This PR includes two fixes and the code enable > the check API. It's got positive reviews first time round and I > haven't heard any complaints for this revision so we're good to go.
My main concern is still the split test/testresult. I really think having separate objects in the database is more future proof. For instance what if we want to select sending result emails for specific tests? there are plenty of properties like that that belong to a test object, not a test result object. Another problem in this current model is knowing how many tests there are. If I have 20 patches, 5 tests and want an email with results, I'd rather not have 100 mails back, just one with consolidated results. Your main objection to the table split was that you didn't want a single point of administration for adding tests. It doesn't have to be that way, a policy could be that tests rows can be created dynamically for instance and even keep the same front facing API. We could also empower maintainers of the project to add those tests, not the patchwork admin. In general, not just for this, we need member/maintainer roles in the project. Another thing that is a bit overlooked I believe is access control to posting test results? -- Damien _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
