Hi Randell, That sounds like a good proposal. The more help we can clearly get a picture of what bugs are good candidates for automation, the better we'll know what automation to write.
That also makes sense to not block patches right now for required automation. In order to aid in a clearer use of in-testsuite?, what I think we should do based on the above feedback is something like: 1. During review, if the reviewer notices that X bug is a good candidate for a test, immediately flip the in-testsuite? flag and indicate what type of test would be worthwhile to get in as a result of the bug (e.g. XPC Shell, Mochitest, etc). We might want to throw a whiteboard tag in there to indicate what type of test for clarification. 2. During the weekly triage, we include as part of the triage to immediately flag in-testsuite to a value if we know whether it will or won't be a good candidate for automation if we know up-front, along with specifying what type of test in the whiteboard 3. We might want to take a quick skim during a triage session of existing bugs to flag any bugs in the bug list that haven't been triaged for in-testsuite to an appropriate value to help aid in automation definition I think that process aligns with the proposal you have above. Oh and as an extension to this discussion (since it already started in the bugs as a trend) - any time automation is blocked, we can use the whiteboard [automation-blocked]. That'll help raise awareness if automation development is getting stuck (which right now, it kinda is true due to plethora of memory leaks). Sincerely, Jason Smith _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
