[development] D7 contrib module development

[Marcel Partap]

> If the community gets collectively pissed off, everything falls apart.
If we as community take the decision to change the process, why would 
that piss us off?

> That some modules get ported anyway makes them
> more obsolescent than obsolete - but unless all the maintainers provide
> rock-solid migration paths (much harder than a port), there's not much
> to do about that.
Well how is that impossible to achieve after having settled on new 
framework designs? It's just a simple matter of converting DB fields 
isn't it.

> Most of our major contributors didn't start off in the Drupal community
> fully formed and descended from heaven, even chx and merlinofchaos. In
> terms of core contributors - I''m credited with a lot of patches against
> Drupal 7, I pretty much learned PHP reviewing and writing patches
> against Drupal 6. If my interest was in contrib rather than core, your
> new rules would've been a major barrier to getting involved.
How does preventing bad code from landing in the repository make it 
harder for you to get involved? Why is it not possible to erect a 
support system that facilitates easier reviewing and testing of code 
not in the repo.

> Fortunately anyone can upload any patch they like to the core issue queue, getting
> beyond that is where it takes a lot of effort.
To make the same apply for non-core modules is what i am proposing. It 
seemingly didn't stop you from becoming a drupal developer, did it? 
Would you rather have seen any code submission from you have been 
committed without those checks? Then why should that be the case for 
non-core modules?

> Have you looked at Drupal 7 yet?
Very sporadically. I've installed it, from time to time looked at 
diffs and the changelog.
> How familiar are you with the core
> development process?
Well i know it sometimes takes years to get stuff in *g

> While I'd love to see some consolidation in
> contrib, I don't see any realistic proposals for handling this, rather
> than mythical hordes of people who'll magically appear to review patches
> for contrib as well as core.
It all stands or falls with accessible support interfaces and good 
operational algorithms (i've made a detailed proposal but noone picked 
it up).

> I'd love to see code quality metrics (both coder and test coverage) for
> modules, and that combined with usage and other metrics. With that, the
> unmaintained modules will naturally get filtered out to the bottom.
The unmaintained modules are not really much of a problem. What my 
proposal is targeting is mainly the situation where duplicate modules 
are seeing continues development with diverting trend, instead of 
merging. That's the hardest issue to solve, and now is the time to 
try. Why now? Because the D7 non-core development cycle just started. 
Anything is possible now. When all modules have migrated from D6 to D7 
we will basically have perpetuated the situation to continue through 
the whole D7 cycle.

Please have a look at the attached graphic which is an excerpt from 
this lecture 'Quality Management - Quality and Economics':
http://www.wzl.rwth-aachen.de/en/ebecb2e7d199a686c125736f00454c10/04_l_eng_quality_and_economics.pdf

..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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: failure-cost.png
Type: image/png
Size: 48864 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20090309/f25a36d6/attachment-0001.png