To Marcel: The stifle innovation argument is valid although you've called it invalid several times. You have proposed that 10 (not high profile) developer reviews would be required in order to commit code. Assuming you mean what you say and the overloaded developers (high profile) don't have an increased workload, then that means i need 10 reviews to get my code committed. No that was not exactly what i proposed. The proposal (!) was to have a patch get autocommitted (if style checks run fine and no tests break) by a bot after receiving 10 RTBC vote 'points' and no veto status. The fact that needs to be taken into account here is the level of coding skills and experience of the reviewing person, f.e. by giving people like merlinofchaos chx dries karens etc. (i.e. who have proven to be capable working even on especially complex code) a voting weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital. That'd of course be an arbitrary decision - i'm sure though we could come up with something that worked.
I maintain a non-duplicative module that plays an important role in universities that are doing single sign on with drupal. I have struggled with getting ONE person to review my patches, but my code does get reviewed at my place of work, outside of the drupal commmunity. This project would likely not be viable on drupal.org under the solution you describe. The solution i described means that you'd post your code to a drupal-patches mailing list, which would in turn create a patch queue entry. Now anyone just watching could quickly review the code from their mail reader and if they feel like making a decision, do so on the respective, or leave their comments either by replying to the mailing list post or the tracker item, which would in turn be sent to the respective other channel. Now once that piece of core - or a modified version that gets posted later to the tracker item - receives its 10 RTBC points and passes the mentioned checks, it gets committed automatically. That at least was my basic idea which of course might have plenty space for improvement.
There are several ways for you to get involved in patch reviews:
1. Play Contrib patch Bingo 2. Filter the project issue queue by Feature Requests that are Ready for Review 3. Subscribe to the issue queues of projects you're interested in helping with. I like mailing lists. Wine-patches is just great for watching code that passes by. It'd be really useful as a tool by itself imho, although those other options already exist. You have to agree there is a slight but notable difference in actively subscribing/seeking something or passively get pushed the new code to your inbox.
I would add my voice to the voice of other that suggest that there are more effective ways for us all to spend time improving quality of contrib code, the biggest of which could be joining the developer documentation effort. There already is pretty good documentation and style guides and everything available. However, obviously that does *not* prevent people from ignoring these, which could simply be cured by a different commit policy for the official repository. It might get time for people to get accustomed to it, but i still think it would be beneficial for the whole drupal project in the long term.
regards marcel. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future