8 Mar
2009
8 Mar
'09
7:03 p.m.
... > 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