[development] D7 contrib module development
mpartap at gmx.net
Sun Mar 8 18:03:51 UTC 2009
> 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
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
> 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
> 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
> 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
> 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
> 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?
"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