[development] An alternative to common thinking in 5-> 6migration

[Marcel Partap]

> 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