Andre Poenitz wrote: > There are no strict rules, but maybe we should set up a few guidelines > when more people get write access.
Maybe we should document these on the wiki (once it's reachable again). > My personal recommendation for 'newcomers' (i.e. people that have been > around for a while and already got some of their stuff committed by > others) are something like the following: I agree on those ... > Depending on the severity: > > Purely cosmetical, small scale changes (correcting spelling mistakes in > comments, whitespace changes or so) should be sent to the list. > Can be committed after a grace period of a few hours. > > If it is 'really obvious', wait a day or two or (preferably) you get an > explicit 'ok', then commit. > > If it is 'easy' and in 'your playground' (which would be RTL in this > case) better wait for explicit consent or resent after a couple of > days and then commit. > > If it is 'business as usual in your playground' try to get affirmation, > even twice. > > Changes to area of the code outside your playground should be discussed. > For thing like changing default settings try to reach consensus. > Then 'business as usual'. > > Severe changes to the core should only happen after reaching consensus > on the list, i.e. usuall four or five people in favour and the rest > not being vocal about their dissent. > > After a while, you may bump all rules by a level, and after a > few decades you'll invent rules by yourself... ... plus: * If we're in a pre-release phase, stick to the rules defined by the maintainer (which is, currently: no commit without explicit o.k. from at least two developers) * In the stable branch: no commit without explicit agreement of the stable branch maintainer Jürgen
