From 16ca077d4a65eb17b58aa755842d6ba112db6359 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Jos=C3=A9=20Fonseca?= Date: Tue, 18 Jun 2013 16:29:24 +0100 Subject: [PATCH] Document the need to keep tracing robust. For future reference. --- DEVELOPMENT.markdown | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/DEVELOPMENT.markdown b/DEVELOPMENT.markdown index 8990e7b..4a494c2 100644 --- a/DEVELOPMENT.markdown +++ b/DEVELOPMENT.markdown @@ -126,12 +126,24 @@ Commit policy Feature development: * Existing features in master branch should not degrade at any time, for any - platform. (Unless it is not widely used and there is agreement.) + platform. (Unless they are seldom used or redundant and there is agreement.) -* It's fine to add new features for only some platforms. + * In particular, new features / changes must not introduce any sort of + instability when tracing. -* Non-trivial changes should be staged in a branch, to enable peer-review and - regression testing. Branch should be deleted once code has been merged. + While application developers and driver developers may be able to + workaround quirks in apitrace, we want to be able to obtain traces from + non-technical end-users with minimal intervention. + + This implies that tracing should not make any non-standard assumptions, and + care must be taken to ensure the tracing code is robust against invalid + parameters, multiple threads, etc. + +* It's fine to add new features for only some platforms or APIs. + +* Non-trivial changes should be staged in a branch, to allow review and + regression testing. Feature branches should be deleted once they have been + merged. * Releases are tagged commits from master. There are no stable branches. -- 2.43.0