[development] An alternative to common thinking in 5-> 6migration
mpartap at gmx.net
Wed Mar 11 21:03:34 UTC 2009
> 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.
"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
More information about the development