Nick Kew wrote: > > What do you mean by "override STATUS flow"?
The convention is "propose in status, collect votes, commit when approved". But the policy is not "propose in STATUS", the *policy* is "review, then commit". The devs can work these rules in whatever manner best accomplishes forward progress, so this list is free to suspend these rules in specific cases. An example are platform patches; nobody complains if Guenter just fixes a Netware build flaw, if Bill patches the win32 build files, or if Joe went ahead and fixed the rpm build files. Common sources generally require review-then-commit. STATUS does NOT override the dev@ list for decision making. It's simply a vehicle of convenience. Any review that occurs on dev@ is just as binding, if not more so, than STATUS. Only *this list* gives STATUS binding authority. If some minority vote against patches based on their absence from STATUS, so be it. Seems like bureaucracy to me in certain cases, and entirely the most efficient approach in other cases.
