It is a good rule that important changes (toolchain, infrastructure) are reviewed before being committed. This is e.g. also specified in http://wiki.openembedded.net/index.php/Commit_Policy
However, recently I've seen some issues that our review process does not seem to work or is abused. I see two things happening. - patches are submitted for review but do not gain any feedback in a reasonable time. I have several patches in the queue that did not get any feedback. - people are abusing their powers by rejecting changes without motivation. See e.g [1] and [2]. I feel if you reject a patch you have an obligation to explain why you rejected it. Seems our review process is flawed. I propose to introduce the following rules. 1. If a patch does not get any review feedback in X weeks time; it is ok to apply it. People who need more time to review a patch can mention that in a short reply. In that case they are granted Y more weeks to review. (suggestion: X = Y = 2) 2. If someone NAKs a patch it is obligatory to provide an explanation why the patch is not good. Rationale is that a) people can fix the problem seen by the reviewer b) people learn from it c) if there is a disagreement it can be discussed (and if needed raised to the TSC) 3) NAKs that are not motivated/explained can be ignored as not given. Your feedback, suggestions, additions, amendments, whatever is appreciated. Frans [1] http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/023374.html [2] http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/023270.html _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
