[oe] [RFC] review process

[Frans Meulenbroeks]

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