[development] D7 contrib module development
mpartap at gmx.net
Mon Mar 9 17:11:52 UTC 2009
> 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
> 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
> 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
> 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':
"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...
Size: 48864 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20090309/f25a36d6/attachment-0001.png
More information about the development