[development] D7 contrib module development

[Marcel Partap]

...
> However, in the end, you get what you pay for! Well, Drupal is free
> and you don't pay for it. :)
What i meant was of course the effort to install a code bottlenecking
process, not the cost of drupal but guess you understand that ;)

> To be honest, I think this is an absolutely terrible idea.  It's
> just not scalable.  We've got thousands of contributed modules and
> themes, which makes for millions of lines of code. To ask that we
> can have a core team of developers managing contrib patches,
Quite frankly that's not what i'm proposing, out of the reasons you
just stated.
BTW although according to
wget -qO - http://ftp.drupal.org/files/projects/|html2text -width 130 
-nobs|'grep' "\-6.x\-"|sed 's/\[\[   \]\]//;s/-6.*//'|sort -u|wc -l
there currently are 2227 D6 contrib projects (compared to 2827 for D5) 
- do you really think all of those provide a useful benefit to the 
community? how many of those are deprecated, unmaintained or plain 
useless? Even then we can prevent that from happening on D7 *without* 
destroying what's already there. D6 will live on for perhaps up to a 
decade anyways... There are still D4 sites out there!

> means that they need to get familiar with all those projects and
> how they work, the various potentially complex code and features in
> each.  It's just not realistic.  It's also not realistic to expect
> those same developers to review _all_ of the patches that need to
> get committed.

What i am proposing is that all code *not* coming from the most active
(in-know) drupal developers (which includes core just aswell as f.e.
cck, views and coder devs) passes through a ML/refined patch tracker,
is reviewed by the drupal-patches subscribers - and only enters the
repository after *either* one of the high-profile devs voted RTBC (1 *
weight 10) *or* ten 'normal' reviewers voted RTBC, at which point the
code is also automatically committed (if it still passes the
conformance tests and noone vetoes).
To explain again, the new process would not be interfering with the 
working mode of the most active drupal developers, but make reviewing 
patches from casual contributors obligatory.

Just speaking for me but i'd definitly see merit and take part in such
a process.

> Don't forget this doesn't just include patches that get submitted
> via the issue queues but all of the changes that the maintainers
> themselves commit as they're working on new features, etc.
Sure it does, and if anyone wants to submit a valid fix or 
enhancement, easily will the community okay the changes at which point 
they automatically get committed. Working on new features however is a 
different story: why should half-baked testing code get committed to 
the central repository at all? Nevertheless the process i'm proposing 
can be applied to experimental code changes just fine - they'd just 
not be committed until the work on that issue has resulted in 
something sane. Most patches going into core pretty much went through 
the exact same process: someone posting an initial patch which gets 
refined to a piece of sufficient quality in mutual exchange of code 
and opinions.

> Most Drupal contributors provide their time and effort for free - again
> it's not realistic, this proposal sounds like a full time job.
For whom? The additional work load of more thoroughly reviewing and 
careful sanitizing code submissions is not to be forced upon 
individual people. It's about making that a swarm thing!

> I also really dislike this proposal because, as you pointed out,
> the rate of changes to contrib will decrease.
If quantity goes down, quality goes up: is it bad or good? Which 
numbers count heavier, SLOC or #bugs?

> This includes both features and bug fixes.
How do bugs get introduced in the first place? Committing experimental 
stuff too quickly and without review.
How do modules end up in the situation where ugly hacks become 
necessary and new features become hard to implement? Bad design 
decisions because of the lack of a careful conceptualization phase.

> It goes against the whole "the drop is
> always moving" and in doing so, removes one of the great things
> about Drupal.
Does not. The drop will still be moving, even faster through uber meta 
channeling :D

> If you really want to help improve contrib, then help by writing
> more "comparisons of duplicated modules"
> (http://drupal.org/node/266179 - though the handbook is a bit
> messed up since the upgrade).
Waste of time better spent on reimplementing functionality in the best 
possible manner.

> Help by working with contrib project
> maintainers and convince them to merge their duplicate modules.
Hahahahaahahaha.. .. sorry the part about convincing was too funny. 
Make module 'owners' give up their precious 'property'? What about 
establishing the art of hand-knitting in London's most popular night 
clubs?

> Help by reviewing contrib modules and providing patches.
Been there done that. Let me repeat: once the shit *has* hit the fan, 
cleaning up is a messy unrewarding work.

> So a big -1 for this proposal.
Hope that's not set in stone ;)

Another point to make: D6 is good. Together with the vast variety of 
contrib modules, in some way or the other it does provide the 
functionality to easily implement web projects with almost any use 
case covered. So there's no need to rush out, neither D7 core nor 
contrib modules. Why not take the time to do things right from the 
beginning? If D6 module code has to be heavily modified anyways, why 
not consider the benefits of reimplementing it from scratch?

rgds 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