Hi fellow drupal devs, wanted to bring up a few points about module development for some time and i guess now that module development happens to be the hot topic of the day would be a good time.. While D6 is proving to be a great success and through contrib modules can be flexibly expanded to almost unlimited use case customizations, working with a whole bunch of modules on our site my experience is that quantity is not necessarily a good compensation for quality. Several problems just keep coming up: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names but by far the most serious one is - duplication (partial feature overlap with existing modules). There might be different perspectives on this but IMHO specifically for D7 this is not a good way to go. An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others. While competition is a good thing, certainly having multiple similar D5 modules live on and slowly creep up the version ladder while fighting for the same 'market share' is hindering real progress (=feature innovation, code sanity and API excellence) more than it is promoting it. If we want D7 to become *THE* perfect open source CMS, maybe a change in the module development process can help guaranteeing a higher level of code quality. One possible option could be to go some steps towards the linux model, in which all patches have to be signed off by a small team of core developers. Drupal would not have to choose an official team of reviewers though - patches could be confirmed by a simple voting system, in combination with the already working automatic testing. The issue tracking system could be optimized for reviewing/auto testing/auto committing patches (more code centric). However the specific details: the point of that change would be to shift responsibility (=power) from individual module creators to the coding swarm of contributors. This would significantly lower the odds of b(rainde)ad code getting in and hopefully drastically cut down on duplication. Especially because of the to-be-expected great API changes in D7 and the resulting amount of code rewriting that has to be done, wouldn't it be a great point in time to get our act together and come up with a single bind-them-all notification framework? _One_ cleverly designed poll/decision extension? Merging/standardizing the various e-payment modules? Imho taking this direction in the long run will result in more coherent code and enable easier adaption to core API changes, also cutting down on user confusion - furthermore increasing overall D7 r0xorn3ss! What's your view on this? regards, 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
RE following the linux model -- we already are. Linux has one "kernel" and how ever many applications built on top it that there are individuals interested enough to write one. We follow the exact same model -- Drupal's kernel (the core) has two committers and a core group of individuals who either maintain subsections of our "kernel" or know enough about core development to "sign off" on patches before they're added to core. But in the Linux application space it's a wild wild west as far as quality standards go. There are many Linux applications of very high quality maintained by companies or dedicated individuals but again there's scads of poorly coded, poorly maintained duplicating applications available for Linux. As Drupal matures, so will the contributed modules space. Already more important modules like Views see significant commercial support and have code quality standards as high as core. I think forcing all contrib code to go through a central space is a really bad idea because a) it doesn't scale -- who wants to spend time reviewing someone's weekend hacking project? and b) it'd unfairly kill ugly baby modules which might mature into something significant. Innovation isn't "perfect" at the start. Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Sat, Mar 7, 2009 at 9:03 PM, Marcel Partap <mpartap@gmx.net> wrote:
Hi fellow drupal devs, wanted to bring up a few points about module development for some time and i guess now that module development happens to be the hot topic of the day would be a good time.. While D6 is proving to be a great success and through contrib modules can be flexibly expanded to almost unlimited use case customizations, working with a whole bunch of modules on our site my experience is that quantity is not necessarily a good compensation for quality. Several problems just keep coming up: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names but by far the most serious one is - duplication (partial feature overlap with existing modules). There might be different perspectives on this but IMHO specifically for D7 this is not a good way to go. An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others. While competition is a good thing, certainly having multiple similar D5 modules live on and slowly creep up the version ladder while fighting for the same 'market share' is hindering real progress (=feature innovation, code sanity and API excellence) more than it is promoting it.
If we want D7 to become *THE* perfect open source CMS, maybe a change in the module development process can help guaranteeing a higher level of code quality. One possible option could be to go some steps towards the linux model, in which all patches have to be signed off by a small team of core developers. Drupal would not have to choose an official team of reviewers though - patches could be confirmed by a simple voting system, in combination with the already working automatic testing. The issue tracking system could be optimized for reviewing/auto testing/auto committing patches (more code centric).
However the specific details: the point of that change would be to shift responsibility (=power) from individual module creators to the coding swarm of contributors. This would significantly lower the odds of b(rainde)ad code getting in and hopefully drastically cut down on duplication.
Especially because of the to-be-expected great API changes in D7 and the resulting amount of code rewriting that has to be done, wouldn't it be a great point in time to get our act together and come up with a single bind-them-all notification framework? _One_ cleverly designed poll/decision extension? Merging/standardizing the various e-payment modules? Imho taking this direction in the long run will result in more coherent code and enable easier adaption to core API changes, also cutting down on user confusion - furthermore increasing overall D7 r0xorn3ss! What's your view on this?
regards, 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
On 08/03/09 03:29, Kyle Mathews wrote:
RE following the linux model -- we already are. Linux has one "kernel" and how ever many applications built on top it that there are individuals interested enough to write one. [...] But in the Linux application space it's a wild wild west as far as quality standards go. Seems a bit to me like you intentionally misunderstood my analogy ;D The comparison i was (not even) trying to make is linux core kernel and optional modules versus Drupal core and contrib.
As Drupal matures, so will the contributed modules space. Even though you are trying hard, i am not talking names (of modules which contain code that just scares me).
Already more important modules like Views see significant commercial support and have code quality standards as high as core. Well so these modules are not the problem. But what about that notification modules mess?
I think forcing all contrib code to go through a central space is a really bad idea because a) it doesn't scale May i guess that you never been subscribed to the wine-patches mailing list? Granted the project's scope is very different, but a huge amount of code diffs is flowing through that channel everyday - and with designated nested folders in my thunderbird i find it highly manageable to skim through code i'm interested in.. speaking of which maybe a drupal-patches mailing list synchronized with an automatic patch tracker wouldn't be a bad way to handle this..
who wants to spend time reviewing someone's weekend hacking project? That's the point. Someone's weekend hacking project just doesn't belong in the d.o repository if the quality is not sufficient, period (imho *g).
and b) it'd unfairly kill ugly baby modules which might mature into something significant. Well those ugly baby modules then simply need to be rewritten for D7 to push the code to a higher level of quality. This is not about social fairness. This is about software that has to reliably work for millions of people. _And_ be fast at it. Innovation isn't "perfect" at the start. 'Course not - but we had D1-6 for that ain't it?
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
Innovation isn't "perfect" at the start.
'Course not - but we had D1-6 for that ain't it?
Don't expect too much from D7: http://buytaert.net/drupal-7-code-freeze-september-1st My 2 cents. sun
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcel Partap schrieb:
On 08/03/09 03:29, Kyle Mathews wrote:
RE following the linux model -- we already are. Linux has one "kernel" and how ever many applications built on top it that there are individuals interested enough to write one. [...] But in the Linux application space it's a wild wild west as far as quality standards go. Seems a bit to me like you intentionally misunderstood my analogy ;D The comparison i was (not even) trying to make is linux core kernel and optional modules versus Drupal core and contrib.
As Drupal matures, so will the contributed modules space. Even though you are trying hard, i am not talking names (of modules which contain code that just scares me).
Why not? Reporting hard to understand or otherwise scary code is a good thing for the module maintainer. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmzz0EACgkQfg6TFvELooRfZQCcCwk73pRSZ8sfWupmOUpFDkXS /NIAniLizJ8hEf72O/y2LF/KyeZjQNee =g7sX -----END PGP SIGNATURE-----
Several problems just keep coming up: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques
Go ahead and create patches for those modules. That's the only way to fix 'em.
but by far the most serious one is - duplication (partial feature overlap with existing modules).
Bad habit of module authors. Slap them, but create a patch to remove what has been duplicated afterwards.
There might be different perspectives on this but IMHO specifically for D7 this is not a good way to go. An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others.
The reason for that is that someone thought he/she could write something better, wrote it, and ended up with something that already exists. From then on, happy developers continued to improve the pre-existing thingy, while some others installed the duplicated thingy and advanced on that. The end result is: two parties that think either approach is wrong and a massive croud of users that thinks "And this is why Drupal sucks.(tm)" Removing the duplication requires that those module maintainers (finally) come to that conclusion.
One possible option could be to go some steps towards the linux model, in which all patches have to be signed off by a small team of core developers.
Core developers are already buried with core development. Take a look at issue queues of "sub-core" modules like Views and you'll understand that each project needs its own code-guards.
Drupal would not have to choose an official team of reviewers though - patches could be confirmed by a simple voting system, in combination with the already working automatic testing. The issue tracking system could be optimized for reviewing/auto testing/auto committing patches (more code centric).
Machines can not (yet) replace the complex thoughts and decisions of a human. If a patch passes some (human-created) tests, that only means a) it passed an expected behavior (which still can be wrong or outdated) and b) it passed coding-style tests (if there were some) - but there still has to be a gate-keeper who tells you about logic errors and the future of Drupal.
However the specific details: the point of that change would be to shift responsibility (=power) from individual module creators to the coding swarm of contributors. This would significantly lower the odds of b(rainde)ad code getting in and hopefully drastically cut down on duplication.
False assumption: Duplication is caused by braindead code. Also by developers who a) are unable to search or b) really want to get another project on their list to raise their ego. Cooperation and collaboration with maintainers of existing projects is the key (which still requires that you are competent enough to search).
Especially because of the to-be-expected great API changes in D7 and the resulting amount of code rewriting that has to be done, wouldn't it be a great point in time to get our act together and come up with a single bind-them-all notification framework? _One_ cleverly designed poll/decision extension? Merging/standardizing the various e-payment modules? Imho taking this direction in the long run will result in more coherent code and enable easier adaption to core API changes, also cutting down on user confusion - furthermore increasing overall D7 r0xorn3ss!
This mostly depends on the maintainers of those modules. Because if you would want to remove the duplication you would have to create yet another duplicated project.
What's your view on this?
Somebody circle stomp those developers. sun
On 08/03/09 03:57, Daniel F. Kudwien wrote:
Several problems just keep coming up: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques Go ahead and create patches for those modules. That's the only way to fix 'em. Dude i've been wasting my whole summer on that. Cleaning up afterwards is a hell lot of more unrewarding work than preventing the shit from hitting the fan.
but by far the most serious one is - duplication (partial feature overlap with existing modules). Bad habit of module authors. Slap them, but create a patch to remove what has been duplicated afterwards. Yeah like i even have multiple days each day - sorry i simply can not fix stuff beyond the needs of my NGO site. If the development process allows module authors to have bad habits - well maybe its not tightly regulated enough.
There might be different perspectives on this but IMHO specifically for D7 this is not a good way to go. An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others.
The reason for that is that someone thought he/she could write something better, wrote it, and ended up with something that already exists. From then on, happy developers continued to improve the pre-existing thingy, while some others installed the duplicated thingy and advanced on that. The end result is: two parties that think either approach is wrong and a massive croud of users that thinks "And this is why Drupal sucks.(tm)"
Removing the duplication requires that those module maintainers (finally) come to that conclusion. That seems far less realistic than setting up a strict regulatory bottleneck for every line of official core/contrib D7 code. Take a look at how extremely discerning the benevolent dictator of the Wine project - Alexandre Julliard - handles the many code submissions from wine-patches - and at the resulting quality. There's a reason he skips committing 30% of patches.
One possible option could be to go some steps towards the linux model, in which all patches have to be signed off by a small team of core developers.
Core developers are already buried with core development. Take a look at issue queues of "sub-core" modules like Views and you'll understand that each project needs its own code-guards. That very well i know. Maybe we can all improve the process and optimize the obligatory set of tools?
Drupal would not have to choose an official team of reviewers though - patches could be confirmed by a simple voting system, in combination with the already working automatic testing. The issue tracking system could be optimized for reviewing/auto testing/auto committing patches (more code centric). Machines can not (yet) replace the complex thoughts and decisions of a human. If a patch passes some (human-created) tests, that only means a) it passed an expected behavior (which still can be wrong or outdated) and b) it passed coding-style tests (if there were some) - but there still has to be a gate-keeper who tells you about logic errors and the future of Drupal. Of course not - but if the automated tests pass, AND 10 registered Drupal developers okay the patch by voting RTBC - for sure a commit bot can take the decision to just do it? My guess: swarm intelligence + sophisticated tools outperform stressed individual core developers.
However the specific details: the point of that change would be to shift responsibility (=power) from individual module creators to the coding swarm of contributors. This would significantly lower the odds of b(rainde)ad code getting in and hopefully drastically cut down on duplication. False assumption: Duplication is caused by braindead code. Also by developers who a) are unable to search or b) really want to get another project on their list to raise their ego. Cooperation and collaboration with maintainers of existing projects is the key (which still requires that you are competent enough to search). Well of course it is the key, and the docs have been endorsing it since years. In reality.. well uhem http://drupal.org/node/197093 cough cough.. Ok fine maybe it is more practical to set up an development algorithm *for D7* (not D6, everyone can still go bonkers there) that leaves less freedom for 'stuff' (communication, decisions) to 'go wrong'.
Especially because of the to-be-expected great API changes in D7 and the resulting amount of code rewriting that has to be done, wouldn't it be a great point in time to get our act together and come up with a single bind-them-all notification framework? _One_ cleverly designed poll/decision extension? Merging/standardizing the various e-payment modules? Imho taking this direction in the long run will result in more coherent code and enable easier adaption to core API changes, also cutting down on user confusion - furthermore increasing overall D7 r0xorn3ss! This mostly depends on the maintainers of those modules. Because if you would want to remove the duplication you would have to create yet another duplicated project. You can call it duplication - i'd prefer talking about rewriting and merging. Key focus should be on clean design, flexibility and code efficiency - just the values that are relevant to D7 core development.
What's your view on this? Somebody circle stomp those developers. Will that make the problem vanish? Or maybe it'll just annihilate precious programming talent.. X)
-- "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
Dude i've been wasting my whole summer on that. Cleaning up afterwards is a hell lot of more unrewarding work than preventing the shit from hitting the fan.
100% of all other contributors are "wasting" their time (not only the past summer) to improve Drupal core and contributed modules. Change requires to take some action.
Bad habit of module authors. Slap them, but create a patch to remove what has been duplicated afterwards. Yeah like i even have multiple days each day - sorry i simply can not fix stuff beyond the needs of my NGO site. If the development process allows module authors to have bad habits - well maybe its not tightly regulated enough.
We have several handbook pages that outline coding standards and best practices. You can simply put it this way: Developers who do not adhere to them do not want that anyone contributes to their modules. To be realistic, we can't regulate more than regulating that any code in CVS is licensed under GPL.
Removing the duplication requires that those module maintainers (finally) come to that conclusion. That seems far less realistic than setting up a strict regulatory bottleneck for every line of official core/contrib D7 code. Take a look at how extremely discerning the benevolent dictator of the Wine project - Alexandre Julliard - handles the many code submissions from wine-patches - and at the resulting quality. There's a reason he skips committing 30% of patches.
...which prevents innovation. At least one of my modules would not exist today if it would not have gone through 1 year of quality assurance and testing, becoming one of the most popular Drupal modules in the end.
Core developers are already buried with core development. Take a look at issue queues of "sub-core" modules like Views and you'll understand that each project needs its own code-guards. That very well i know. Maybe we can all improve the process and optimize the obligatory set of tools?
The issue is not the tools, but the brains and time of contributors. Each and every module needs people who "love" a module and can spare a fair amount of dedicated time to think about and work on a project. Improvement and innovation requires in-depth knowledge about something.
Machines can not (yet) replace the complex thoughts and decisions of a human. If a patch passes some (human-created) tests, that only means a) it passed an expected behavior (which still can be wrong or outdated) and b) it passed coding-style tests (if there were some) - but there still has to be a gate-keeper who tells you about logic errors and the future of Drupal. Of course not - but if the automated tests pass, AND 10 registered Drupal developers okay the patch by voting RTBC - for sure a commit bot can take the decision to just do it? My guess: swarm intelligence + sophisticated tools outperform stressed individual core developers.
We have this system already. It is called "co-maintainers". sun
Change requires to take some action. That's what me taking the initiative was all about ;)
Bad habit of module authors. Slap them, but create a patch to remove what has been duplicated afterwards. Yeah like i even have multiple days each day - sorry i simply can not fix stuff beyond the needs of my NGO site. If the development process allows module authors to have bad habits - well maybe its not tightly regulated enough. We have several handbook pages that outline coding standards and best practices. You can simply put it this way: Developers who do not adhere to them do not want that anyone contributes to their modules. To be realistic, we can't regulate more than regulating that any code in CVS is licensed under GPL. Yes we can. We can set up a clearly defined landing path for code submissions.
Removing the duplication requires that those module maintainers (finally) come to that conclusion. That seems far less realistic than setting up a strict regulatory bottleneck for every line of official core/contrib D7 code. Take a look at how extremely discerning the benevolent dictator of the Wine project - Alexandre Julliard - handles the many code submissions from wine-patches - and at the resulting quality. There's a reason he skips committing 30% of patches. ...which prevents innovation. At least one of my modules would not exist today if it would not have gone through 1 year of quality assurance and testing, becoming one of the most popular Drupal modules in the end. Does not. A lot of stuff has been tried already for D6 - for D7 everyone and his dog should have made the experiences from which we can benefit, especially about which design decisions cause maintenance problems later one. So in my opinion the concern you voice is valid even for D6, it would have stiffled innovation to regulate code committs. But for D7, i believe the goal should shift from having a huge quantity of modules to expandable frameworks for areas like notifications, polls/web forms/questionaires, payment that provide coherent and flexible APIs to obliterate fuplicate attempts of providing the same functionality. If it takes a lot of time to migrate certain modules from D6 to D7, and just as much time to implement a totally new module for D7 which merges functionality, code and vision of several modules, i (as a student of engineering, specializing in construction and development) *very very very* strongly would support the later choice. It might be difficult and require changes, but in the long run it will be worth it.
Core developers are already buried with core development. Take a look at issue queues of "sub-core" modules like Views and you'll understand that each project needs its own code-guards. That very well i know. Maybe we can all improve the process and optimize the obligatory set of tools? The issue is not the tools, but the brains and time of contributors. Each and every module needs people who "love" a module and can spare a fair amount of dedicated time to think about and work on a project. Yes and no. Each piece of code needs to be written by someone who needs the functionality AND is passionate about it, ACK. But that should not inherently make him the person to solely be responsible for the code. Instead, every code contribution should be subject of a community process in which everyone caring about it reviews and contributes, without defining single individuals as maintainer of a module (though recording the credits for each individual submission).
Improvement and innovation requires in-depth knowledge about something. True. How does a more swarm-like approach to code committal hinder that? That'd just channel the flow more tightly.
Machines can not (yet) replace the complex thoughts and decisions of a human. If a patch passes some (human-created) tests, that only means a) it passed an expected behavior (which still can be wrong or outdated) and b) it passed coding-style tests (if there were some) - but there still has to be a gate-keeper who tells you about logic errors and the future of Drupal. Of course not - but if the automated tests pass, AND 10 registered Drupal developers okay the patch by voting RTBC - for sure a commit bot can take the decision to just do it? My guess: swarm intelligence + sophisticated tools outperform stressed individual core developers. We have this system already. It is called "co-maintainers". Well it doesn't systemicly solve the problem, as it really just expands the number of stressed individual developers who have responsibility instead of tackling the root cause that makes all this even possible: no enforcement of coding standards, no wider review of changes before committal, no opportunity for improvements to be made before committal, single individuals responsible for decisions.
To clarify here's how it could work: - erection of drupal-patches mailing list for all code to pass through - coupling that mailing list with a revised patch tracking system - patch submissions to the ML create a patch issue - comments to the posting get also attached to the issue - in turn, patch issues file through the web interface are echoed on the ML, just as comments to it (similar how to what the mailman/mailhandler modules.. i hereby step up for a clean reimplementation of this functionality) - inserting a voting system into the patch issue tracker - two choices: 'ready to be committed' or 'veto' - core developers' votes get higher weight, can clear 1/2 veto votes - having the patch issue tracker DISPLAY the code by default additionally to providing it as attachment - setting up rules and regulation (proposal) - developers get awarded D7 svn rights by either landing more than 1K of code or 10 commits in core, or by being promoted - all code *has* to be either committed by these developers or has to get 10 RTBC votes with no vetoes - all code going in has to at least break no tests AND - all code is automatically tested for adherence to coding standard - patches can -and should- be improved by all who care until 10 RTBC - code contributors are recorded in each modules changelog / AUTHORS - several frameworks have to be put in place for D7: - messaging / change notification - polls / web forms / questionaires / quiz - translation (l10n server integration, finally!) - caching - media integration - probably e-commerce/payment => brainstorming in the corresponding groups needs to start Of course implementing this would require messing with the ways of some drupal developers, and it will definitly slow down the rate of contrib code increase. However, in the end, you get what you pay for! To explicitly say it again: all this is only viable because of the experience gained from D6 unregulated contrib development creativity. But looking at how *quality* is at the top of the D7 agenda, it might be a wise idea to apply more pruning and gardening tactics in general also to the modules to _not_ end up in an impenetrable jungle thicket like the D6 contrib area. And swarm intelligence is just the right buzzword to do it.. Webchick, Dries, core devs: pleace voice opinion NOW ;) 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
However, in the end, you get what you pay for!
Well, Drupal is free and you don't pay for it. :) 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, 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. 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. Most Drupal contributors provide their time and effort for free - again it's not realistic, this proposal sounds like a full time job. I also really dislike this proposal because, as you pointed out, the rate of changes to contrib will decrease. This includes both features and bug fixes. It goes against the whole "the drop is always moving" and in doing so, removes one of the great things about Drupal. 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). Help by working with contrib project maintainers and convince them to merge their duplicate modules. Help by reviewing contrib modules and providing patches. So a big -1 for this proposal. Cheers, Stella
... > 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
Marcel Partap wrote:
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.
There lies the fallacy. I don't believe there is any 'one best solution' for most given problems, especially in Drupal. Which is better: a simple solution that gives a few features out of the box, or a highly configurable, extensible solution that requires multiple configurations before it can be used? It depends on the site being built and on the site builder. In the realm of email subscription modules, for example, the needs of an internal documentation site versus a public news publishing site are very different. Likewise, Site builders who are coders are going to be drawn to the module that describes itself this way: "This is a complete Subscriptions/Notifications Framework aiming at extendability and escalability. It allows any number of plug-ins defining new event types or subscription types or a different user interface." Site builders who are afraid of PHP will drawn to: "This module allows users to subscribe to periodic emails which include all new or revised content and/or comments much like the daily news letters sent by some websites" or, if they already know the drupal lingo and need more power, maybe: "This module enables users to subscribe to be notified of changes to nodes or taxonomies, such as new comments in specific forums, or additions to some category of blog." Duplicated modules aren't necessarily competing modules. I think it's good to have different modules focused on meeting the needs of different audiences. One size does not fit all. It was suggested that some duplicated modules exist solely to feed developer ego. That's not the most flattering way to put it, but I have noticed that being the maintainer of a module does lead to business inquiries; I'm not keen to give up the publicity. One possible solution to this would be to have project pages list all the committers for a project, and not just the one owner. This would increase the value of collaboration and decrease the hesitation for developers to let a module die in favor or a new, truly better solution. Best, Matt
There lies the fallacy. I don't believe there is any 'one best solution' for most given problems, especially in Drupal. No, but what is possible is to come up with an algorithm that leads to a statistically significant improvement on the sustainability and correctness of decisions.
Which is better: a simple solution that gives a few features out of the box, or a highly configurable, extensible solution that requires multiple configurations before it can be used? Well you asked for it: better is an extensible framework which does what 80% of the users want in the minimum/default configuration, and can be expanded to all other use cases by activating extra modules (just like cck, i18n, views, xmlsitemap..). To have different code for simple and complex use cases is what i consider to be the worst case.
It depends on the site being built and on the site builder. In the realm of email subscription modules, for example, the needs of an internal documentation site versus a public news publishing site are very different. So a notification framework clearly needs a lot of clever thinking to come up with a structural design that scales from small and simple to huge and complex. That's why brainstorming on it has to start soon ;)
Likewise, Site builders who are coders are going to be drawn to the module that describes itself this way:
"This is a complete Subscriptions/Notifications Framework aiming at extendability and escalability. It allows any number of plug-ins defining new event types or subscription types or a different user interface."
Site builders who are afraid of PHP will drawn to:
"This module allows users to subscribe to periodic emails which include all new or revised content and/or comments much like the daily news letters sent by some websites"
or, if they already know the drupal lingo and need more power, maybe:
"This module enables users to subscribe to be notified of changes to nodes or taxonomies, such as new comments in specific forums, or additions to some category of blog." So the solution would be two frameworks: "Hi, i am the messaging framework and responsible for handling all communication. You can enable different sub modules for mail, sms, jabber, twitter, smoke signaling according to your needs." and "This module is for handling change notifications of nodes, fields and comments. By itself it does not expose any UI." plus the correspondent modules building on that: "regular notifications UI - user interface to enable intervalled updates for all types of subscriptions" "change notifications UI - notify users when an Drupal object changes" "advanced subscription settings UI - provide UI for more precise control of content subscriptions" (something along these lines, i'm sure many people more experienced with this stuff than me can do better)
Duplicated modules aren't necessarily competing modules. Disagree. I think it's good to have different modules focused on meeting the needs of different audiences. Yes, but the clever way is to make them share code. Just like all the .DLL and .so files on your computer, which are frameworks that provide a broad variety of special functions for applications to use a selected lot of them.
One size does not fit all. No, but reimplementing basic functionality multiple times in incompatible ways is not exactly the clever approach either.
It was suggested that some duplicated modules exist solely to feed developer ego. That's not the most flattering way to put it, but I have noticed that being the maintainer of a module does lead to business inquiries; I'm not keen to give up the publicity. Well the mission of drupal should definitly not to feed module maintainers, but to strive continuously to be the best open source CMS in existence. So this really shouldn't be influencing the decision. Furthermore, my proposal did state that each module collects the credits of its contributor, and i am sure we can find ways to give hard working coders some publicity. Ever read the KDE commit digests? They have some nice statistics at the top (people with most commits/bug fixes/buzz)...
One possible solution to this would be to have project pages list all the committers for a project, and not just the one owner. This would increase the value of collaboration and decrease the hesitation for developers to let a module die in favor or a new, truly better solution. Not invasive enough. In my opinion, bold steps will result in better results here. Trying to _promote_ a certain way of doing things or specific values does not seem to work well enough.
Still voting for 'let the swarm maintain the modules', 'improve code-centric tools and communication' and 'tightly enforce quality standards for the official D7 contrib repository' here. 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
Marcel Partap wrote:
So the solution would be two frameworks: "Hi, i am the messaging framework and responsible for handling all communication. You can enable different sub modules for mail, sms, jabber, twitter, smoke signaling according to your needs." and "This module is for handling change notifications of nodes, fields and comments. By itself it does not expose any UI." plus the correspondent modules building on that: "regular notifications UI - user interface to enable intervalled updates for all types of subscriptions" "change notifications UI - notify users when an Drupal object changes" "advanced subscription settings UI - provide UI for more precise control of content subscriptions" (something along these lines, i'm sure many people more experienced with this stuff than me can do better)
So now the first time site builder who just wants his friends to be able to decide if they want to receive email notice of new content needs to download and enable the right combination of at least 3 modules. Or he can just download and enable notify module. As a developer, sometimes it much easier for me to write my own solution to my own simple problem than to take the time to learn someone else's framework for a generic class of similar problems. Sometimes, duplicating basic code is the more efficient process, especially in a system as complex as you describe. Also, the cost of change is factor in the real world. Even though notify module is an inferior module on several levels, it was easier to upgrade it to D6 than to switch to one of the newer frameworks. Probably the only reason notify module still exists is because it's the oldest of the solutions. If someone wants to write a migration tool for the notifications or subscriptions framework, and a UI module that duplicates notify's simplicity, once these are included in the framework download package, I will gladly shutdown notify. Best, Matt
So now the first time site builder who just wants his friends to be able to decide if they want to receive email notice of new content needs to download and enable the right combination of at least 3 modules. Or he can just download and enable notify module.
Now your users start crying for a feature that Notify module does not provide. You create a patch for it, it gets committed, and Notify module is one more step closer to be a full duplicate of other notification modules.
As a developer, sometimes it much easier for me to write my own solution to my own simple problem than to take the time to learn someone else's framework for a generic class of similar problems. Sometimes, duplicating basic code is the more efficient process, especially in a system as complex as you describe.
The real issue starts with module integration. User-facing modules like Buddylist, Guestbook, Organic Groups, Privatemsg, and a lot others integrate either with one or the other notification module. So you end up with Privatemsg, which integrates with Subscriptions, and Guestbook, which integrates with Notifications. Now, module maintainers are either forced to integrate with more than one notification module, or none at all - requiring the notification modules to take over the integration. Drupal users (not developers) most often cannot do anything about it at all. All they could do is to install more than one notification module, but that would obviously be a pain for their site's users and performance. That's why duplication hurts the entire Drupal project and community.
Also, the cost of change is factor in the real world. Even though notify module is an inferior module on several levels, it was easier to upgrade it to D6 than to switch to one of the newer frameworks. Probably the only reason notify module still exists is because it's the oldest of the solutions. If someone wants to write a migration tool for the notifications or subscriptions framework, and a UI module that duplicates notify's simplicity, once these are included in the framework download package, I will gladly shutdown notify.
As long as there is this duplication, this won't happen anytime soon. Both modules, Subscriptions and Notifications, suffer from their own duplication - code-wise, feature-wise, as well as usability-wise. The same applies to other duplicated modules. sun
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel F. Kudwien schrieb:
So now the first time site builder who just wants his friends to be able to decide if they want to receive email notice of new content needs to download and enable the right combination of at least 3 modules. Or he can just download and enable notify module.
Now your users start crying for a feature that Notify module does not provide. You create a patch for it, it gets committed, and Notify module is one more step closer to be a full duplicate of other notification modules.
If the cries of your users get too loud it's time to either close the door or crank up the sound level... Or you could create a migration script to one of the more advanced notification modules.
As a developer, sometimes it much easier for me to write my own solution to my own simple problem than to take the time to learn someone else's framework for a generic class of similar problems. Sometimes, duplicating basic code is the more efficient process, especially in a system as complex as you describe.
The real issue starts with module integration. User-facing modules like Buddylist, Guestbook, Organic Groups, Privatemsg, and a lot others integrate either with one or the other notification module. So you end up with Privatemsg, which integrates with Subscriptions, and Guestbook, which integrates with Notifications.
Now, module maintainers are either forced to integrate with more than one notification module, or none at all - requiring the notification modules to take over the integration.
I believe the latter way is the way to go. Drupal core should make this process easy by providing hooks etc. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm0cHUACgkQfg6TFvELooSvCQCgqN6Wj6CBHch5vPtrhhdb8p01 rmIAnjJXiNdJPNlYpoNO6vM8iv5We7Xu =n4Lk -----END PGP SIGNATURE-----
Daniel F. Kudwien wrote:
Now your users start crying for a feature that Notify module does not provide. You create a patch for it, it gets committed, and Notify module is one more step closer to be a full duplicate of other notification modules.
If you had read the project page or the issue queue for notify, you would not have said this. I have a number of issue threads that end in 'I found this other combination of modules to do what I wanted' and I'm thrilled, because, as I said, I don't believe that duplicate modules are necessarily competitors. The solution is not always to eliminate modules that duplicate functionality; the key is to educate maintainers about the other modules, so that they can effectively recommend the best solutions to crying users. Much like the discussions of backward compatibility, if people would get out of the academic theory and actually read/write/port/use the code, we'd avoid a lot of needless FUD and abstract arguments that produce nothing. (I'm not referring specifically to Daniel's comments here; he & I are largely in agreement on the issue, I think.) Best, Matt
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<http://ftp.drupal.org/files/projects/%7Chtml2text>-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!
Yes, your observation is correct, but ... so what? We've always had stuff that falls off the face of earth. So what? The caravan continues on ... The very first module I contributed (feedback) illustrates a point: It was started in 2002 by someone called "barry". I had it working I took it over in 2004 with totally new code for Drupal 4.5. Then "fago" overhauled it a lot in 2006. Over time, the contact module in core came along, and I stopped using feedback. Then in 2008 "sun" took it over and repurposed it with new code. The "too many modules in contrib syndrome" can be taken as confusing, excessive, ...etc. but can also be taken as a sign of a healthy and vibrant community. So what if we have a few extra gigabytes of code? So what if they become unmaintained? If we raise the barrier or block new entries we will be shutting ourselves off from being the platform for the new chx or the new merlinofchaos. It does not matter ... if it is the wild wild west, then let it be. It is a small price to pay for innovation and the power of the masses. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
We've always had stuff that falls off the face of earth. So what? The caravan continues on ... Sorry but i don't consider that a logically valid argument.
The very first module I contributed (feedback) illustrates a point: It was started in 2002 by someone called "barry". I had it working I took it over in 2004 with totally new code for Drupal 4.5. Then "fago" overhauled it a lot in 2006. Over time, the contact module in core came along, and I stopped using feedback. Then in 2008 "sun" took it over and repurposed it with new code. Well good that process worked out than, btw i am actually using the module ;) But from the experiences gained, how would you design such a module from scratch? How could it be integrated with other modules, what could be factored out into 'frameworks' (/library modules) ? That is the stuff each of the drupal code contributors needs to think about as early as possible in the D7 cycle, which would be right about.. _now_!
The "too many modules in contrib syndrome" can be taken as confusing, excessive, ...etc. but can also be taken as a sign of a healthy and vibrant community. Sure. But what is the prior goal of the Drupal project? To create a healthy vibrant community? Or to create the best open source CMS CODE out there (best accomplished through a healthy vibrant community)?
So what if we have a few extra gigabytes of code? So what if they become unmaintained? Uhhm sorry i don't share that so-what mentality. I want to have *all* the functionality spread over slightly different modules with the same purpose, combined into one flexible solution. And i am quite sure i am not the only one.
If we raise the barrier or block new entries we will be shutting ourselves off from being the platform for the new chx or the new merlinofchaos. Woow stop for a minute please.. so you're saying people like chx or merlinofchaos are not capable of adapting to coding standards and qualified to contribute code which can be worked on to raise over the ready-and-useful barrier to be included in the official Drupal repository?
It does not matter ... if it is the wild wild west, then let it be. It is a small price to pay for innovation and the power of the masses. But the thing is, sometimes innovation needs channeling. Granted, in the early phases of the industrial revolution it would have been counterproductive to regulate machines and processes in any manner, simply because not enough practical experience had been gained. But once a certain level of sophistication is reached, there is no way you want to live without agreed standard interfaces and common norms. Imagine todays industries without all the ISO standards for screws, bearings, gears, quality management.. What do you think which kind of a car would you drive if none of them would exist? In my opinion with D7 we have reached that level of wild life experience to benefit from a more ordered development process. To say again, why trade in quality for quantity/speed? Most people will be quite happy with D6 for years to come.
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
On Mon, Mar 9, 2009 at 11:28 AM, Marcel Partap <mpartap@gmx.net> wrote:
We've always had stuff that falls off the face of earth. So what? The
caravan continues on ...
Sorry but i don't consider that a logically valid argument.
What I meant is modules come and disappear all the time. This experimentation has proven to be healthy, and the project is healthy despite that. It is not a negative to have unmaintained modules and such, given that others are thriving.
The very first module I contributed (feedback) illustrates a point: It
was started in 2002 by someone called "barry". I had it working I took it over in 2004 with totally new code for Drupal 4.5. Then "fago" overhauled it a lot in 2006. Over time, the contact module in core came along, and I stopped using feedback. Then in 2008 "sun" took it over and repurposed it with new code.
Well good that process worked out than, btw i am actually using the module ;) But from the experiences gained, how would you design such a module from scratch?
In the four instances, the code was rewritten from scratch, preserving the name and often obsoleting the prior functionality. How could it be integrated with other modules, what could be factored out
into 'frameworks' (/library modules) ?
It happens naturally. For example userpoints started as an application, then people wrote more applications for it, it was all in a single project. Later we took out the community contributions and split them into the userpoints_contrib project. Then we split off ANY and ALL applications (what used to be userpoints_basic, now userpoints_nc) leaving only the API in the project. Views started the same way with splitting off the bonus pack ...etc. What I am saying it happens naturally as people realize that they are evolving their pet project into an API/Framework over time.
That is the stuff each of the drupal code contributors needs to think about as early as possible in the D7 cycle, which would be right about.. _now_!
The "too many modules in contrib syndrome" can be taken as confusing,
excessive, ...etc. but can also be taken as a sign of a healthy and vibrant community.
Sure. But what is the prior goal of the Drupal project? To create a healthy vibrant community? Or to create the best open source CMS CODE out there (best accomplished through a healthy vibrant community)?
The vibrant community leads to the best open source CMS code. Creating the best CMS code does not mean that the default download be bloated with hundreds of modules that not everyone will use. As I said: kernel -> distros. One for education, one commerically supported, another for high traffic sites, another for whatever. It is working out ...
So what if we have a few extra gigabytes of code? So
what if they become unmaintained?
Uhhm sorry i don't share that so-what mentality.
You miss the fact that this is an ecosystem, and you have all kind of relationships: symbiosis, parasitism, commensalism, ..etc. You can't dictate what happens in contrib without stifling the innovation that this ecosystem has. We can nudge people to work together but we can't force them to.
I want to have *all* the functionality spread over slightly different modules with the same purpose, combined into one flexible solution. And i am quite sure i am not the only one.
You are advocating the "one true way". But without letting people experiment, that one true way could be the one with less features, with a non-committed maintainer, could be buggy, ...etc. You don't know until you put it out there and let the ecosystem decide. Who will decide the one true way? Committee? Hierarchy? Nope, sorry. Don't want that in a community led project. Might as well go to commercial CMSs then. What we can do is let things evolve for a while and then naturally a winner or two will emerge from the fray. As disconcerting this is to some, it is a sure way to have a proven solution for the problem space.
If we raise the barrier or block new entries we will be shutting
ourselves off from being the platform for the new chx or the new merlinofchaos.
Woow stop for a minute please.. so you're saying people like chx or merlinofchaos are not capable of adapting to coding standards and qualified to contribute code which can be worked on to raise over the ready-and-useful barrier to be included in the official Drupal repository?
No. I am saying is that without seeing people contribute for some time you don't know before hand if they will turn to be a drive-by contributor of a so-so project, or the author of the next big hit. And it is not only about technical prowess, it is about how you work with the community, are you committed to the community and Drupal, do you encourage others who use/contribute to your project, and much more. All that cannot be seen just from the first contribution adherence to coding standards.
It does not matter ... if it is the wild wild west, then let it be. It
is a small price to pay for innovation and the power of the masses.
But the thing is, sometimes innovation needs channeling. Granted, in the early phases of the industrial revolution it would have been counterproductive to regulate machines and processes in any manner, simply because not enough practical experience had been gained. But once a certain level of sophistication is reached, there is no way you want to live without agreed standard interfaces and common norms. Imagine todays industries without all the ISO standards for screws, bearings, gears, quality management.. What do you think which kind of a car would you drive if none of them would exist?
Fair point, standards will arise across CMS's too, such as the new proposed CMIS that makes them interoperate. There are differences in an information world than an industrial one too (capital required, barrier to entry, ...) But the argument is : are we at that point yet? Is it now? I don't think so myself. But within Drupal, I don't see we are the point where we have a central body . Later maybe? Perhaps. But not now. When you see a majority of the community cry for that, then it is time to re-evaluate.
In my opinion with D7 we have reached that level of wild life experience to benefit from a more ordered development process. To say again, why trade in quality for quantity/speed? Most people will be quite happy with D6 for years to come.
Again, you see "now is the time", I see "not now". As for D6, it will not get security support forever. So those who use it are on their own after D9 comes out, whenever that is.
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
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
It is not a negative to have unmaintained modules and such, given that others are thriving. Well what if unmaintained/bad modules are sucking the time of users and developers and annoying them for no good reason? Not negative?
How could it be integrated with other modules, what could be factored out into 'frameworks' (/library modules) ? It happens naturally.
Very well. But there's a reason bioengineering is the latest hype: it is a lot FASTER and more DIRECTED than the evolutionary process.
What I am saying it happens naturally as people realize that they are evolving their pet project into an API/Framework over time. At our university we are taught: the more brainwork you invest early on in the development process, the less headache you'll have to cope with.
Sure. But what is the prior goal of the Drupal project? To create a healthy vibrant community? Or to create the best open source CMS CODE out there (best accomplished through a healthy vibrant community)? The vibrant community leads to the best open source CMS code. No, not by itself. It needs some structural algorithm to have things develop into that direction.
You miss the fact that this is an ecosystem, and you have all kind of relationships: symbiosis, parasitism, commensalism, ..etc. If they interfere with the creation of top-most quality code - they should be prevented from doing that. If people can make money offering drupal services to customers: fine. Should the development process of an open source project try to facilitate that? I don't think so.
You can't dictate what happens in contrib without stifling the innovation that this ecosystem has. Who's talking about dictating.. Everyone can code freely. But for code to enter the official repository, quality checks should apply. That doesn't stop innovation, does it? Look at the few commits to the cck/views branches for example. Why is that kind of responsible code committing not scalable to all other modules as well?
We can nudge people to work together but we can't force them to. Well not many people who score goals by hand have made successfull career in football. How comes? Might it be that whoever doesn't respect the rules will not be allowed to play?
I want to have *all* the functionality spread over slightly different modules with the same purpose, combined into one flexible solution. And i am quite sure i am not the only one. You are advocating the "one true way". Am not. What i am advocating is a process that makes problems that occured in the past less likely to happen.
But without letting people experiment Why is not letting experimental code into the repository stopping people from trying stuff out? Please explain that to me, i simply don't get that.
that one true way could be the one with less features, with a non-committed maintainer, could be buggy, ...etc. You don't know until you put it out there and let the ecosystem decide.
Who will decide the one true way? Committee? Hierarchy? No - the swarm, that is us. We all work together on finding the best way to lay the foundation for the respective functionality. Aren't we already doing that with core? Is it impossible to apply to non-core modules?
What we can do is let things evolve for a while and then naturally a winner or two will emerge from the fray. So please tell me, what is the winning change notification framework? Notifications, Subscriptions, Comment Notify, Notify, ...? Which is the best module to create sophisticated web questionnaires? Is it webforms? Advanced Poll? Decisions? Do you really want to have the same situation with D7? Not terribly user-friendly, is it?
As disconcerting this is to some, it is a sure way to have a proven solution for the problem space. Is not. It might be sufficient, but it surely isn't the optimum.
No. I am saying is that without seeing people contribute for some time you don't know before hand if they will turn to be a drive-by contributor of a so-so project, or the author of the next big hit. Why is applying quality checks before applying code to the official repository making it harder for people to code, experiment, innovate? How does having each submission routinely reviewed by the community stop anyone to contribute?
All that cannot be seen just from the first contribution adherence to coding standards. Whos talking about judging people by their first code? But what is a good reason for the first contribution of someone starting to learn drupal to be included in the official repository? Wouldn't it be much more helpful to receive comments and tips in the discussion thread for their patch?
Fair point, standards will arise across CMS's too Didn't even touch _that_ topic.
But within Drupal, I don't see we are the point where we have a central body . Well i didn't propose a central committee, but for the whole community to pick up quality checking and maintain the modules as a huge diverse team. Sounds implausible? Well who's stopping us from trying.
Later maybe? Perhaps. But not now. When you see a majority of the community cry for that, then it is time to re-evaluate. At the time people are crying it usually is a bit late.
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
Who's talking about dictating.. Everyone can code freely. But for code to enter the official repository, quality >>checks should apply. That doesn't stop innovation, does it? Look at the few commits to the cck/views branches >>for example. Why is that kind of responsible code committing not scalable to all other modules as well?
We already have a way for code to get reviewed before it gets committed to the repository, it's called patches. The gatekeepers for core aren't just the two committers - there's also a whole layer of people who regularly review patches before they get committed, not enough of them, but that's how the code for core gets filtered. There are 92 pages of patches which need review against core or contrib. If we could fine people to review all of those patches intelligently - not to mention dealing with new bug reports and support requests for the top 200 most used modules, that'd help to consolidate efforts a lot. Anything else is putting the cart very, very far before the horse. http://drupal.org/project/issues/search?text=&projects=&assigned=&submitted=&participant=&status[]=8 That doesn't include all code marked for commit or needs work which nearly doubles that number. Or to put it another way, count the number people who reply to support requests, let alone post and review patches for the Views issue queue. It's a small number of overworked people. The people working on core and the 'top 40' (or 100, or 300) contrib modules are buried in issues, don't get nearly enough help with their projects - but then you want these people to review every commit as well?
No - the swarm, that is us. We all work together on finding the best way to lay the foundation for the respective >>functionality. Aren't we already doing that with core? Is it impossible to apply to non-core modules?
Yes it's impossible unless we massively increase the people dealing with support requests, bug reports and patch reviews for the major modules which have already 'won'. Let alone co-ordinating efforts to merge smaller/duplicated/abandoned modules as time goes on.
Why is not letting experimental code into the repository stopping people from trying stuff out? Please explain that >>to me, i simply don't get that.
A lot of sandbox projects on Drupal.org have turned into great modules or core patches - often resurrected by people other than the original author. Having all this code centralised is a good thing and isn't going to change. What will hopefully change is filtering those projects from the most widely used and supported ones for new users - again, there's efforts to do this both with the redesign and numerous feature requests to project*. Nat
On Mon, 09 Mar 2009 17:52:02 +0100 Marcel Partap <mpartap@gmx.net> wrote:
How could it be integrated with other modules, what could be factored out into 'frameworks' (/library modules) ? It happens naturally.
Very well. But there's a reason bioengineering is the latest hype: it is a lot FASTER and more DIRECTED than the evolutionary process.
Faster and more directed doesn't mean right. I think that evolution isn't rational... but at least it generally provide a lot of testing ;) We can try to be rational and let evolution do the "testing".
What I am saying it happens naturally as people realize that they are evolving their pet project into an API/Framework over time. At our university we are taught: the more brainwork you invest early on in the development process, the less headache you'll have to cope with.
If you invest it right and you're freeze in time. I'm not a strong fan of XP but still in its less X incarnation has its merits. The problem of low quality modules and duplication could be reduced to further info on module pages: activity, releases, downloads, related modules... These aren't perfect metrics but they can help without anyone playing God or just get into the way of developers making requirements.
You can't dictate what happens in contrib without stifling the innovation that this ecosystem has. Who's talking about dictating.. Everyone can code freely. But for code to enter the official repository, quality checks should apply. That doesn't stop innovation, does it? Look at the few commits to the cck/views branches for example. Why is that kind of responsible code committing not scalable to all other modules as well?
We can nudge people to work together but we can't force them to. Well not many people who score goals by hand have made successfull career in football. How comes? Might it be that whoever doesn't respect the rules will not be allowed to play?
I want to have *all* the functionality spread over slightly different modules with the same purpose, combined into one flexible solution. And i am quite sure i am not the only one. You are advocating the "one true way". Am not. What i am advocating is a process that makes problems that occured in the past less likely to happen.
But without letting people experiment Why is not letting experimental code into the repository stopping people from trying stuff out? Please explain that to me, i simply don't get that.
that one true way could be the one with less features, with a non-committed maintainer, could be buggy, ...etc. You don't know until you put it out there and let the ecosystem decide.
Who will decide the one true way? Committee? Hierarchy? No - the swarm, that is us. We all work together on finding the best way to lay the foundation for the respective functionality. Aren't we already doing that with core? Is it impossible to apply to non-core modules?
What we can do is let things evolve for a while and then naturally a winner or two will emerge from the fray. So please tell me, what is the winning change notification framework? Notifications, Subscriptions, Comment Notify, Notify, ...? Which is the best module to create sophisticated web questionnaires? Is it webforms? Advanced Poll? Decisions? Do you really want to have the same situation with D7? Not terribly user-friendly, is it?
As disconcerting this is to some, it is a sure way to have a proven solution for the problem space. Is not. It might be sufficient, but it surely isn't the optimum.
No. I am saying is that without seeing people contribute for some time you don't know before hand if they will turn to be a drive-by contributor of a so-so project, or the author of the next big hit. Why is applying quality checks before applying code to the official repository making it harder for people to code, experiment, innovate? How does having each submission routinely reviewed by the community stop anyone to contribute?
All that cannot be seen just from the first contribution adherence to coding standards. Whos talking about judging people by their first code? But what is a good reason for the first contribution of someone starting to learn drupal to be included in the official repository? Wouldn't it be much more helpful to receive comments and tips in the discussion thread for their patch?
Fair point, standards will arise across CMS's too Didn't even touch _that_ topic.
But within Drupal, I don't see we are the point where we have a central body . Well i didn't propose a central committee, but for the whole community to pick up quality checking and maintain the modules as a huge diverse team. Sounds implausible? Well who's stopping us from trying.
Later maybe? Perhaps. But not now. When you see a majority of the community cry for that, then it is time to re-evaluate. At the time people are crying it usually is a bit late.
rgds marcel.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Sure. But what is the prior goal of the Drupal project? To create a healthy vibrant community? Or to create the best open source CMS CODE out there (best accomplished through a healthy vibrant community)?
If we lost all the code tomorrow, we'd have 400,000 to put it back together (even if 1% of that are active coders that's still 4,000 people to actually write it). If the community gets collectively pissed off, everything falls apart.
So what if we have a few extra gigabytes of code? So
what if they become unmaintained?
Uhhm sorry i don't share that so-what mentality. I want to have *all* the functionality spread over slightly different modules with the same purpose, combined into one flexible solution. And i am quite sure i am not the only one.
This is already happening - every release, Views and CCK make another 1-200 modules obsolete. 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. If we raise the barrier or block new entries we will be shutting
ourselves off from being the platform for the new chx or the new merlinofchaos.
Woow stop for a minute please.. so you're saying people like chx or
merlinofchaos are not capable of adapting to coding standards and qualified to contribute code which can be worked on to raise over the ready-and-useful barrier to be included in the official Drupal repository?
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. Fortunately anyone can upload any patch they like to the core issue queue, getting beyond that is where it takes a lot of effort. And we already have a filter for people applying for a CVS account which tries to weed out the worst quality code or obvious duplication. It does not matter ... if it is the wild wild west, then let it be. It
is a small price to pay for innovation and the power of the masses.
But the thing is, sometimes innovation needs channeling. Granted, in the
early phases of the industrial revolution it would have been counterproductive to regulate machines and processes in any manner, simply because not enough practical experience had been gained. But once a certain level of sophistication is reached, there is no way you want to live without agreed standard interfaces and common norms.
Standards are emergent. Look at USB, high definition DVDs, RDF, SPARQL etc. The car industry is a terrible example to give, given most modern cars are really inefficient, and the whole thing is collapsing at the moment.
In my opinion with D7 we have reached that level of wild life experience to benefit from a more ordered development process. To say again, why trade in quality for quantity/speed? Most people will be quite happy with D6 for years to come.
Have you looked at Drupal 7 yet? How familiar are you with the core development process? 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. 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. Nat
In moving modules from 5.x to 6.x it is commonly suggested to move our drupal_add_css (and _js) into hook_init. Ceratinly I did this in nearly all my modules because it was the common suggestion. However, now that Im making a big change in one and having problems with the CSS, it dawned on me that this suggestion adds the CSS files to *every* page, not just the ones we were targeting. It finally dawned on me that I have hook_help that only fires on the pages I need to CSS on, so I moved the drupal_add_css into hook_help, which to me makes a lot more sense because now my CSS is only applied to those pages for which it is intended. What do others think of this? Are there pitfalls I may not have covered? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.11.9/1990 - Release Date: 3/8/2009 5:17 PM
Nancy Wichmann wrote:
In moving modules from 5.x to 6.x it is commonly suggested to move our “drupal_add_css” (and _js/) /into hook_init. Ceratinly I did this in nearly all my modules because it was the common suggestion. However, now that I’m making a big change in one and having problems with the CSS, it dawned on me that this suggestion adds the CSS files to **every** page, not just the ones we were targeting. It finally dawned on me that I have hook_help that only fires on the pages I need to CSS on, so I moved the “drupal_add_css” into hook_help, which to me makes a lot more sense because now my CSS is only applied to those pages for which it is intended. What do others think of this? Are there pitfalls I may not have covered?
You clicked "reply" on an email deep inside another thread to make your most recent post to the list. Most of us view our email in a threaded mail reader to follow discussions and this puts your new question WAY at the bottom of this existing (and seemingly interminable) discussion where it wont get the attention it deserves. Please dont reply to an email to compose a new message to the list. Instead just "compose one" from scratch so we can all see it :). To answer your question, with "css munging" drupal_add_css doesn't result in an additional page hit for the new css file (because they are combined into 1) and I normally suggest including it because the small bandwidth penalty on page load #1 is normally outweighed by the latency + bandwidth on the following page loads where it has t be dynamically loaded. if you dont use css munging then you approach has some validity i suppose but id be hesitant to put it in the help section and instead makes sure it is added when and where needed by your actual theme code so that it isnt a maintenance issue. -mf
If it makes sense for your use-case, drupal_add_css/_js() should always be invoked in the builder or rendering function of a "thing". I.e., if the CSS applies to a form, invoke drupal_add_css() from the form builder function. That way, the form (or other "thing") can be rendered with the proper stylesheet in other places. However, if your CSS applies specifically to your module's help text, then yeah, hook_help() is the proper location for invoking drupal_add_css() - so the help text would be the "thing" here. sun
Nancy Wichmann wrote:
In moving modules from 5.x to 6.x it is commonly suggested
to move our
“drupal_add_css” (and _js/) /into hook_init. Ceratinly I did this in nearly all my modules because it was the common suggestion. However, now that I’m making a big change in one and having problems with the CSS, it dawned on me that this suggestion adds the CSS files to **every** page, not just the ones we were targeting. It finally dawned on me that I have hook_help that only fires on the pages I need to CSS on, so I moved the “drupal_add_css” into hook_help, which to me makes a lot more sense because now my CSS is only applied to those pages for which it is intended. What do others think of this? Are there pitfalls I may not have covered?
To answer your question, with "css munging" drupal_add_css doesn't result in an additional page hit for the new css file (because they are combined into 1) and I normally suggest including it because the small bandwidth penalty on page load #1 is normally outweighed by the latency + bandwidth on the following page loads where it has t be dynamically loaded. if you dont use css munging then you approach has some validity i suppose but id be hesitant to put it in the help section and instead makes sure it is added when and where needed by your actual theme code so that it isnt a maintenance issue.
-mf
this existing (and seemingly interminable) discussion where it wont get the attention it deserves. I highly value your appreciation for my attempt to evaluate solutions to one of drupal's biggest problems. Thank you so much.
-- "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
Marcel This is not personal. Please understand why many see this the way they see it. Every six months, we get the same arguments and we have long running threads to something that was hashed out before many times. So, don't be offended. This list is normally low traffic and these discusses just get to some. My advice: jump in and contribute, review patches, get immersed. And most importantly: Persevere. Then revisit this issue in a year, and see if you changed your mind about how the community and open source works. On Mon, Mar 9, 2009 at 1:33 PM, Marcel Partap <mpartap@gmx.net> wrote:
this existing (and seemingly interminable) discussion
where it wont get the attention it deserves.
I highly value your appreciation for my attempt to evaluate solutions to one of drupal's biggest problems. Thank you so much.
-- "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
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Quoting Marcel Partap <mpartap@gmx.net>:
this existing (and seemingly interminable) discussion where it wont get the attention it deserves. I highly value your appreciation for my attempt to evaluate solutions to one of drupal's biggest problems. Thank you so much.
The problem here is that the issue you try to elaborate in discussion has already been discussed and the outcome of that discussion is what we already have in place. You perceive it as a problem while many more perceive it as the way it is and would be a bad thing to change. You then have the choices of continue wasting time in discussion on a dead (won't fix) issue or get busy and provide patches to make your favorite module better. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
2009/3/10 Marcel Partap <mpartap@gmx.net>:
this existing (and seemingly interminable) discussion where it wont get the attention it deserves.
I highly value your appreciation for my attempt to evaluate solutions to one of drupal's biggest problems. Thank you so much.
Marcel, I don't know if you've noticed but you haven't managed to visibly convince anyone your solution is a good one. Especially not anyone who will bother to try and implement it. On the contrary, you have a whole host of people saying it isn't a good idea and giving reasons why. These people (not me mind you) are the dedicated volunteers that do actually work hard to implement solutions to Drupals problems, and are each in their own way personally responsible for the current success of Drupal today. They do understand the background and developer culture of the community, and the reasons behind Drupals success. Don't take this personally, but your idea and justifications for it have an air of either ivory tower academia or heavyweight process driven enterprise thinking about them. Neither of which have a very good track record of actually getting things done in a volunteer driven open source community where inspiration and enthusiasm is the biggest driver behind doing anything. I started using Drupal when it was a practically unknown project and have seen it grow to be probably the 2nd most popular open source CMS out there and possibly the biggest in terms of developer community. The rate of progress in both Drupal and the supporting infrastructure over that time has been staggering. It's a tall order claiming that the environment or culture that achieved that success is broken - especially since people have come along and announced that plenty of times in the past. Why should that claim be correct now, when it has been shown to be false in the past? Your proposal to have every D7 contrib commit vetted by some sort of vote would just drive away the very enthusiasm and inspiration that drew in all the newbie contrib developers that grew up into veteran developers and core contributers (and that would be the single best way to kill Drupal). I certainly wouldn't bother releasing any Drupal 7 modules if that were the case. And for a lot of modules (eg my own), they simply don't have a user base capable of evaluating the quality of the commit - they will just vote for it anyway so they can get their hands on the bug fix or new feature they desperately need. In nearly all cases, the people doing the voting will know far less about coding or the internals of the module than the author. It won't change much in terms of code quality - it will just add frustration to everyones experience. -- Cheers Anton
Marcel, I don't know if you've noticed but you haven't managed to visibly convince anyone your solution is a good one. Well yes i do have noticed. Apart from 'don't like it' and 'messes with our ways' i have not heard any sound counter arguments though, but that might well be enough of an argument by itself in such a community project.
Especially not anyone who will bother to try and implement it. Well if we all wanted to, we could make it. Easily: it's just a matter of breaking habits, and not even that drastically. Btw it works for other projects (linux, wine).
On the contrary, you have a whole host of people saying it isn't a good idea and giving reasons why. Like 'nah dont like'. (Almost) noone even picked my arguments in favor of such a process, or tried to think up how it could be made to work, or even propose something entirely different.
These people (not me mind you) are the dedicated volunteers that do actually work hard to implement solutions to Drupals problems, and are each in their own way personally responsible for the current success of Drupal today. Well of course but i really missed some voices from those high-profile developers. BTW nothing would change for them, especially no increase in work-load.
They do understand the background and developer culture of the community, and the reasons behind Drupals success. So that implies i don't do that, which is wrong. But to truly achieve excellence, sometimes you have to trade in a bad habit (casual developers committing code to the central repository) for a bitter pill (having all code not from already proven drupal master minds undergo a transparent quality screening) for long term profit (cure the contrib). It's simply people not liking bitter pills until they suffer severely from their sickness.. totally human.
Don't take this personally Course not, but i would have hoped for some support. Without any community backing surely my idea does sound silly.
but your idea and justifications for it have an air of either ivory tower academia or heavyweight process driven enterprise thinking about them. Well it's not that my proposal is totally unrealistic. Only because no one is supporting it does it become so. Would Dries or Angela have proposed it, everybody and his dog would be up in flames of enthusiasm and surely consider it the right way to go.
Neither of which have a very good track record of actually getting things done in a volunteer driven open source community where inspiration and enthusiasm is the biggest driver behind doing anything. Who is trying to stop that. By preventing bull sh1t code from being committed to the official contrib? C'mon! We could easily set up a testing repository, set up a drupal-patches mailing list and nice up the issue tracker to facilitate more code centric work on stuff.
The rate of progress in both Drupal and the supporting infrastructure over that time has been staggering. Yes, true. So with all that gained, how are we possibly going to loose it through tighter quality management?
It's a tall order claiming that the environment or culture that achieved that success is broken - especially since people have come along and announced that plenty of times in the past. I didn't say it's broken, it just allows unlucky stuff to happen. Modifying it a bit could solve the problem for good. Not that this step is _required_, but maybe we as a *software* project would _profit_ from it.
Why should that claim be correct now, when it has been shown to be false in the past? A major core redesign is the best time to make these modifications. Why i proposed these changes i hope i have explained sufficiently.
Your proposal to have every D7 contrib commit vetted by some sort of vote would just drive away the very enthusiasm and inspiration that drew in all the newbie contrib developers that grew up into veteran developers and core contributers (and that would be the single best way to kill Drupal). Ahem, no. Why would anyone insist on committing every mind fart to the official drupal repository? Heck as stated above, how hard is it to have a staging branch? The main motivation to even waste my time in this discussion was to find a solution to the problems mentioned in the original posting: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names - duplication (partial feature overlap with existing modules). If anyone has a more viable solution at hand, i'm more than willing to surrender my effort to their proposal. Right now all i've heard is votes for natural selection. Surely that is one approach to it, but at least not my favorite. Also, almost every possible use case is covered by one or the other D6 module, making that 'no more innovation' argument really not that convincing. What is the point of producing D7 at all? Restructuring! How is that case invalid for non-core modules, simply don't see it. Furthermore, simply don't like the fact that individuals hold the keys to modules. The linux kernel f.e. handles this very differently: contributors get mentioned in the file header. Really, the linux approach of development is what i think drupal should hand pick some points from.
I certainly wouldn't bother releasing any Drupal 7 modules if that were the case. You must be kidding. And for a lot of modules (eg my own), they simply don't have a user base capable of evaluating the quality of the commit Code voting for developers only of course - sure all this needs implementing. Where's a will, there's a way.
In nearly all cases, the people doing the voting will know far less about coding or the internals of the module than the author. It won't change much in terms of code quality - it will just add frustration to everyones experience. Noone wants that, not even crazy me. But my belief still is: if we really want to find a way to improve the process, we can do it. If i stand alone, this is not a fight i'll waste my blood on.
BTW, i really wished i had the time to code all the stuff i'd like to, but obligations (you know.. school, work and stuff *g) shrink my visions to small compact pressed clumps that lay around. It would simply need some outside support to inflate them again, but convincing people to support something unknown nowadays doesn't seem to be too easy. Ah well.. back to work, the profane. regards -- "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
On Monday 09 March 2009 5:22:02 pm Marcel Partap wrote:
Well of course but i really missed some voices from those high-profile developers. BTW nothing would change for them, especially no increase in work-load.
Except that those high-profile developers would need to troll through contrib to vote on stuff.
Don't take this personally
Course not, but i would have hoped for some support. Without any community backing surely my idea does sound silly.
Perhaps the lack of community backing is a sign that the idea really is silly? If you want a "crowdsourced" approach to module maintenance, well, the crowd is right now voting against your idea in droves. That should tell you something.
Neither of which have a very good track record of actually getting things done in a volunteer driven open source community where inspiration and enthusiasm is the biggest driver behind doing anything.
Who is trying to stop that. By preventing bull sh1t code from being committed to the official contrib? C'mon! We could easily set up a testing repository, set up a drupal-patches mailing list and nice up the issue tracker to facilitate more code centric work on stuff.
You can already get email notifications of every single post to the issue queue if you want them. Yet another mailing list for that would be a big step backward.
If anyone has a more viable solution at hand, i'm more than willing to surrender my effort to their proposal. Right now all i've heard is votes for natural selection. Surely that is one approach to it, but at least not my favorite. Also, almost every possible use case is covered by one or the other D6 module, making that 'no more innovation' argument really not that convincing. What is the point of producing D7 at all? Restructuring! How is that case invalid for non-core modules, simply don't see it. Furthermore, simply don't like the fact that individuals hold the keys to modules. The linux kernel f.e. handles this very differently: contributors get mentioned in the file header. Really, the linux approach of development is what i think drupal should hand pick some points from.
Once again, as others have pointed out, you're mapping to the Linux module, um, wrong. Drupal core is to Linux kernel as Views is to KDE. Does KDE not get to commit something unless kernel devs sign off on it? Of course not, that would be insane. But it would get rid of that pesky "Do I use Gnome or KDE?" question. Duplication is just wasted effort, right?
And for a lot of modules (eg my own), they simply don't have a user base capable of evaluating the quality of the commit
Code voting for developers only of course - sure all this needs implementing. Where's a will, there's a way.
The vast majority of contrib modules have exactly one person who knows the code at all, much less well enough to be able to vet and vote intelligently on a patch. So it would fall to those "high level" devs to pick up the slack so that things could even get committed. We're kinda busy already. :-)
Noone wants that, not even crazy me. But my belief still is: if we really want to find a way to improve the process, we can do it. If i stand alone, this is not a fight i'll waste my blood on.
I think it should be apparent by now that you do stand alone on this issue.
BTW, i really wished i had the time to code all the stuff i'd like to, but obligations (you know.. school, work and stuff *g) shrink my visions to small compact pressed clumps that lay around. It would simply need some outside support to inflate them again, but convincing people to support something unknown nowadays doesn't seem to be too easy. Ah well.. back to work, the profane. regards
Convincing people to support something unknown shouldn't be easy. It should have to prove itself. It can happen, but it takes time and generally only happens if the idea really does have merit. The development process for D7 core has changed considerably, for the better, because we only made process changes that made sense to those involved and that reduced workload rather than increasing it. Once again, the fact that no one else supports this proposal should tell you something about it. -- Larry Garfield larry@garfieldtech.com
Except that those high-profile developers would need to troll through contrib to vote on stuff. Would not. On the contrary, all people writing Drupal code could handle all Drupal non-core code as a collective.
Perhaps the lack of community backing is a sign that the idea really is silly? Well my professor for the lecture 'quality management' came up with several examples where there was absolutely no support for ordered quality assurance procedures until something bad happened, at which point someone from the institute went in for counseling and after leaving everybody at the company highly supported the introduction of a structured approach to quality management on the process. It may seem to increase the amount of work needed at first, but really in the end it does the opposite. So no - i still don't think the idea is silly, as i understand it. However many times my points have been misinterpreted so maybe i just didn't make myself clear in the first place. Shame on me.
If you want a "crowdsourced" approach to module maintenance, well, the crowd is right now voting against your idea in droves. That should tell you something. Yeah, but nothing about the viability of the idea of a different approach to non-core code. And opinions change with the tides..
You can already get email notifications of every single post to the issue queue if you want them. Yet another mailing list for that would be a big step backward. Well maybe all the supporting infrastructure already in place just isn't the best it could be. Furthermore personally i still see huge benefit in a single drupal-patches mailing list that would allow me to take part in deciding where the code goes in a different way than filing reports - why let wrong code get in the first place.
Really, the linux approach of development is what i think drupal should hand pick some points from. Once again, as others have pointed out, you're mapping to the Linux module, um, wrong. Drupal core is to Linux kernel as Views is to KDE. How can you tell me the analogy i chose is wrong? The point is not the different layers of software but the development process. You could also compare the SLOC of codes, or the amount of code contributors, or the average color of the project's bike shed.
Does KDE not get to commit something unless kernel devs sign off on it? Of course not, that would be insane. That point is so totally void.
But it would get rid of that pesky "Do I use Gnome or KDE?" question. Duplication is just wasted effort, right? Like i'm getting myself involved in another flame war, nice try.
The vast majority of contrib modules have exactly one person who knows the code at all Which is a *problem* that a different development model would address.
, much less well enough to be able to vet and vote intelligently on a patch. So it would fall to those "high level" devs to pick up the slack so that things could even get committed. We're kinda busy already. :-) As long as you don't _really try to imagine_ how it could work you're not going to understand it anyways.
I think it should be apparent by now that you do stand alone on this issue. Well it is apparent to me that noone brought up any compelling arguments against it (besides 'dont like'). Some people however voiced their annoyance about the current situation - especially with module duplication - which has not been addressed adequately by anyone. Also up to now, the only approach to tackle the other existing real problem of overloaded, unresponsive and uncooperative module maintainers which hold the sole keys is mine. No alternative concept (except the new project queue idea, which has been already mentioned to not catch many of the cases) has been proposed. Yet if nothing is done, shit will just again hit the fan.
Once again, the fact that no one else supports this proposal should tell you something about it. Yes, that it isn't supported, which basically cancels it. That does not imply however it would not work, nor that it would not improve overall code quality, avoid module duplication and on the long run prove to be a scalable development process.
The people i'd really like to have heard an opinion of are people like Dries, Angela and the maintainers of overly complex modules (CCK and Views mainly) however. But now the jury has made up their mind it is too late for the idea anyways. regards, 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
Hallo, i agree very much to all your posting in the last days (did not check older ones ;-) ) i suggested in the attached mail to change the decision making process in the drupal community. Some people agreed and i want to start a group (if it not exists) that creates a proposal for the decision making process. Are you willing to join such a group on groups.drupal.org? Best Thomas Zahreddin Am Mittwoch, den 11.03.2009, 11:12 +0100 schrieb Marcel Partap:
Except that those high-profile developers would need to troll through contrib to vote on stuff. Would not. On the contrary, all people writing Drupal code could handle all Drupal non-core code as a collective.
Perhaps the lack of community backing is a sign that the idea really is silly? Well my professor for the lecture 'quality management' came up with several examples where there was absolutely no support for ordered quality assurance procedures until something bad happened, at which point someone from the institute went in for counseling and after leaving everybody at the company highly supported the introduction of a structured approach to quality management on the process. It may seem to increase the amount of work needed at first, but really in the end it does the opposite. So no - i still don't think the idea is silly, as i understand it. However many times my points have been misinterpreted so maybe i just didn't make myself clear in the first place. Shame on me.
If you want a "crowdsourced" approach to module maintenance, well, the crowd is right now voting against your idea in droves. That should tell you something. Yeah, but nothing about the viability of the idea of a different approach to non-core code. And opinions change with the tides..
You can already get email notifications of every single post to the issue queue if you want them. Yet another mailing list for that would be a big step backward. Well maybe all the supporting infrastructure already in place just isn't the best it could be. Furthermore personally i still see huge benefit in a single drupal-patches mailing list that would allow me to take part in deciding where the code goes in a different way than filing reports - why let wrong code get in the first place.
Really, the linux approach of development is what i think drupal should hand pick some points from. Once again, as others have pointed out, you're mapping to the Linux module, um, wrong. Drupal core is to Linux kernel as Views is to KDE. How can you tell me the analogy i chose is wrong? The point is not the different layers of software but the development process. You could also compare the SLOC of codes, or the amount of code contributors, or the average color of the project's bike shed.
Does KDE not get to commit something unless kernel devs sign off on it? Of course not, that would be insane. That point is so totally void.
But it would get rid of that pesky "Do I use Gnome or KDE?" question. Duplication is just wasted effort, right? Like i'm getting myself involved in another flame war, nice try.
The vast majority of contrib modules have exactly one person who knows the code at all Which is a *problem* that a different development model would address.
, much less well enough to be able to vet and vote intelligently on a patch. So it would fall to those "high level" devs to pick up the slack so that things could even get committed. We're kinda busy already. :-) As long as you don't _really try to imagine_ how it could work you're not going to understand it anyways.
I think it should be apparent by now that you do stand alone on this issue. Well it is apparent to me that noone brought up any compelling arguments against it (besides 'dont like'). Some people however voiced their annoyance about the current situation - especially with module duplication - which has not been addressed adequately by anyone. Also up to now, the only approach to tackle the other existing real problem of overloaded, unresponsive and uncooperative module maintainers which hold the sole keys is mine. No alternative concept (except the new project queue idea, which has been already mentioned to not catch many of the cases) has been proposed. Yet if nothing is done, shit will just again hit the fan.
Once again, the fact that no one else supports this proposal should tell you something about it. Yes, that it isn't supported, which basically cancels it. That does not imply however it would not work, nor that it would not improve overall code quality, avoid module duplication and on the long run prove to be a scalable development process.
The people i'd really like to have heard an opinion of are people like Dries, Angela and the maintainers of overly complex modules (CCK and Views mainly) however. But now the jury has made up their mind it is too late for the idea anyways. regards, marcel.
Are you willing to join such a group on groups.drupal.org? Yeah sure your mail and willing to support that.. however i might be going to the army soon which means i am not sure how much time i will be able to spend on drupal development.. That's why i wanted to get it sorted 'quickly'.. However if none of the developers would adopt such a process, pretty much all our efforts would be void in the first place. And by the way i am also not sure we should call it political names ;) ...also in the end the problem of actually making decisions is a small part of the cake that needs to be baked. More important are most efficient tools to better facilitate casual code reviewing, and to gather some folks to start working on the stuff that could be made into frameworks (messaging, notification, web forms).. .. marcel (clueless on how to go on)
-- "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
On Wed, Mar 11, 2009 at 12:41 PM, Marcel Partap <mpartap@gmx.net> wrote:
Are you willing to join such a group on groups.drupal.org?
Yeah sure your mail and willing to support that.. however i might be going to the army soon which means i am not sure how much time i will be able to spend on drupal development.. That's why i wanted to get it sorted 'quickly'..
Your points about Drupal community decision process might be valid, but your attitude and methods are completely wrong. You can't jump and say "you are doing that wrong, I'll tell you how you need to do that, and you will have to implement what I say yourself, because I'll not be around, why don't you do that? please do that quickly!". No wonder why you are pissing everyone off. Next time, try this instead: "hey, I think we are doing that wrong, I believe that we can do better. I'm ready to try to implement that if some people are willing to try my proposal. I'll be there to experiment and after some time, we could decide if we want to go on or not." Damien
You can't jump and say "you are doing that wrong, I'll tell you how you need to do that, and you will have to implement what I say yourself, because I'll not be around, why don't you do that? please do that quickly!". I never said that. The point about maybe having not much time i did only in this last point. No wonder why you are pissing everyone off. You make me think rude things i will not post.
Next time, try this instead: "hey, I think we are doing that wrong, I believe that we can do better. I'm ready to try to implement that if some people are willing to try my proposal. I'll be there to experiment and after some time, we could decide if we want to go on or not." Which is exactly what i did with my original posting!
-- "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
Well it is apparent to me that noone brought up any compelling arguments against it (besides 'dont like'). Some people however voiced their annoyance about the current situation - especially with module duplication - which has not been addressed adequately by anyone. Also up to now, the only approach to tackle the other existing real problem of overloaded, unresponsive and uncooperative module maintainers which hold the sole keys is mine. No alternative concept (except the new project queue idea, which has been already mentioned to not catch many of the cases) has been proposed. Yet if nothing is done, shit will just again hit the fan. regards, marcel.
Previous posters brought up arguments, but you obviously did not understand them. Refining the list: Unresovable causes for duplication: - Developer wants to implement things differently than maintainer and is unable to agree with maintainer. - Maintainer of existing module does not accept developer's contribution and also does not accept developer as co-maintainer. - Developer takes over existing project and turns it into something that was never intended. Resolvable causes for duplication: - Developer did not search. - Developer did search, but existing module uses different lingo. - Developer did search, but did not realize that existing module does the same in an abstracted way. - Developer was not able to imagine that his contribution would be accepted in existing module. - Developer was too lazy to grasp the API of existing module, better write a new one. - Developer spent weeks of coding in private, now he must release, even if it's 100% duplicate (ego). - Developer did not know about CVS sandboxes. - Developer wants to attract clients (ego). - Developer does not know how to patch, just learned how to use CVS from the handbooks. Given this list, a new project moderation queue would possibly be able to eliminate 75% of duplication causes. So what if this moderation would _blindly_ accept the above mentioned, unresolvable causes as reasons for creating a new project without further backtalk? I could even imagine that the content of this queue can be very interesting for all Drupalers - "I'd like to create a module that does X." - "Why don't you use Y with Z?" - "Bingo!" sun
> Previous posters brought up arguments, but you obviously did not understand > them. ??? Where are those? Despite - it would place all load upon a small load of developers who are already overloaded (not true) - would stiffle innovation (hardly true - restriction only on repo commits) - don't like it because it messes with my ways (can't argue with that) there was no argument i am aware of, and none of those strike me as real compelling evidence quality restriction would be a bad idea. > So what if this moderation would _blindly_ accept the above mentioned, > unresolvable causes as reasons for creating a new project without further > backtalk? ?? huh ?? The point was to make every non-core code just as community-maintained as core, but have a wider circle of people working on it. So how would the situation of an unresolvable conflict arises, if each area of functionality gets its own carefully and expandable framework, and code is okayed by the community? Don't get what you're trying to say, sorry. > I could even imagine that the content of this queue can be very interesting > for all Drupalers Well that's the point. Have all Drupalers maintain the modules, not just a specific maintainer. Just like core, but supported by better tools.. regards 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
Where are those? Despite ...
You obviously do not want to understand those arguments. I don't want to repeat what has been stated by others before.
The point was to make every non-core code just as community-maintained as core, but have a wider circle of people working on it. So how would the situation of an unresolvable conflict arises, if each area of functionality gets its own carefully and expandable framework, and code is okayed by the community? Don't get what you're trying to say, sorry.
You are rather talking about a distributed versioning system like git, where anyone can do anything anywhere. Some people are already investigating that, but that discussion has been moved elsewhere.
I could even imagine that the content of this queue can be very interesting for all Drupalers Well that's the point. Have all Drupalers maintain the modules, not just a specific maintainer. Just like core, but supported by better tools..
See above. Also, I was talking about a moderation queue, which would have an effect on new, potentially duplicated projects (not existing), trying to prevent the issue at all in the first place. sun
On Wednesday 11 March 2009 7:45:14 am Marcel Partap wrote:
Previous posters brought up arguments, but you obviously did not understand them.
there was no argument i am aware of, and none of those strike me as real compelling evidence quality restriction would be a bad idea.
Did it ever occur to you that as someone proposing a new idea it's up to you to present evidence why it's needed, not up to us to provide evidence that it's not? The onus is on you to show that your idea would improve the development process. After 100 or so messages in related threads, you have not. Please don't waste any more electrons repeating the same thing over and over. You had a suggestion, it was rejected, move along to something else. Right now all you're doing is wasting everyone's all-too-limited time, time that would be better spent reviewing patches. -- Larry Garfield larry@garfieldtech.com
On Mar 11, 2009, at 5:45 AM, Marcel Partap wrote:
>> Previous posters brought up arguments, but you obviously did not
>> understand
>> them.
> ???
> Where are those? Despite
> - it would place all load upon a small load of developers who are
> already overloaded (not true)
> - would stiffle innovation (hardly true - restriction only on repo
> commits)
> - don't like it because it messes with my ways (can't argue with that)
> there was no argument i am aware of, and none of those strike me as
> real compelling evidence quality restriction would be a bad idea.
>>
To All:
Sounds like there's two threads here, one about avoiding unnecessary
module duplication and another about improving quality of code that
does get committed. We've mostly been talking about the former. But
I sort of feel like commit time is way to late to be talking about
strategies for eliminating module duplication anyway, so.....
The current documentation on drupal.org basically suggests you should:
* to produce your contribution.
* to apply for contributor privileges.
In the interest of moving this forward/closing this. I've opened an
issue at:
http://drupal.org/node/396946
Which discusses adding guidelines for vetting your module idea. If we
have a process. Now there is already the Joining Forces With others
doc at http://drupal.org/node/23789. Which describes the desire to
communicate, but if there's a recommended protocol, perhaps we should
include it in the basic process description?
To Marcel:
The stifle innovation argument is valid although you've called it
invalid several times.
You have proposed that 10 (not high profile) developer reviews would
be required in order to commit code. Assuming you mean what you say
and the overloaded developers (high profile) don't have an increased
workload, then that means i need 10 reviews to get my code committed.
I maintain a non-duplicative module that plays an important role in
universities that are doing single sign on with drupal. I have
struggled with getting ONE person to review my patches, but my code
does get reviewed at my place of work, outside of the drupal
commmunity. This project would likely not be viable on drupal.org
under the solution you describe.
There are several ways for you to get involved in patch reviews:
1. Play Contrib patch Bingo
2. Filter the project issue queue by Feature Requests that are Ready
for Review
3. Subscribe to the issue queues of projects you're interested in
helping with.
I would add my voice to the voice of other that suggest that there
are more effective ways for us all to spend time improving quality of
contrib code, the biggest of which could be joining the developer
documentation effort.
To Marcel: The stifle innovation argument is valid although you've called it invalid several times. You have proposed that 10 (not high profile) developer reviews would be required in order to commit code. Assuming you mean what you say and the overloaded developers (high profile) don't have an increased workload, then that means i need 10 reviews to get my code committed. No that was not exactly what i proposed. The proposal (!) was to have a patch get autocommitted (if style checks run fine and no tests break) by a bot after receiving 10 RTBC vote 'points' and no veto status. The fact that needs to be taken into account here is the level of coding skills and experience of the reviewing person, f.e. by giving people like merlinofchaos chx dries karens etc. (i.e. who have proven to be capable working even on especially complex code) a voting weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital. That'd of course be an arbitrary decision - i'm sure though we could come up with something that worked.
I maintain a non-duplicative module that plays an important role in universities that are doing single sign on with drupal. I have struggled with getting ONE person to review my patches, but my code does get reviewed at my place of work, outside of the drupal commmunity. This project would likely not be viable on drupal.org under the solution you describe. The solution i described means that you'd post your code to a drupal-patches mailing list, which would in turn create a patch queue entry. Now anyone just watching could quickly review the code from their mail reader and if they feel like making a decision, do so on the respective, or leave their comments either by replying to the mailing list post or the tracker item, which would in turn be sent to the respective other channel. Now once that piece of core - or a modified version that gets posted later to the tracker item - receives its 10 RTBC points and passes the mentioned checks, it gets committed automatically. That at least was my basic idea which of course might have plenty space for improvement.
There are several ways for you to get involved in patch reviews:
1. Play Contrib patch Bingo 2. Filter the project issue queue by Feature Requests that are Ready for Review 3. Subscribe to the issue queues of projects you're interested in helping with. I like mailing lists. Wine-patches is just great for watching code that passes by. It'd be really useful as a tool by itself imho, although those other options already exist. You have to agree there is a slight but notable difference in actively subscribing/seeking something or passively get pushed the new code to your inbox.
I would add my voice to the voice of other that suggest that there are more effective ways for us all to spend time improving quality of contrib code, the biggest of which could be joining the developer documentation effort. There already is pretty good documentation and style guides and everything available. However, obviously that does *not* prevent people from ignoring these, which could simply be cured by a different commit policy for the official repository. It might get time for people to get accustomed to it, but i still think it would be beneficial for the whole drupal project in the long term.
regards 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
On Wed, 11 Mar 2009 22:03:34 +0100 Marcel Partap <mpartap@gmx.net> wrote:
To Marcel: The stifle innovation argument is valid although you've called it invalid several times. You have proposed that 10 (not high profile) developer reviews would be required in order to commit code. Assuming you mean what you say and the overloaded developers (high profile) don't have an increased workload, then that means i need 10 reviews to get my code committed. No that was not exactly what i proposed. The proposal (!) was to have a patch get autocommitted (if style checks run fine and no tests break) by a bot after receiving 10 RTBC vote 'points' and no veto status. The fact that needs to be taken into account here is the level of coding skills and experience of the reviewing person, f.e. by giving people like merlinofchaos chx dries karens etc. (i.e. who have proven to be capable working even on especially complex code) a voting weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital. That'd of course be an arbitrary decision - i'm sure though we could come up with something that worked.
I prefer push approach for this kind of stuff rather than pull. In fact I proposed a feed for just getting changes to docs, api etc... I sincerely don't feel comfort with the drupal project infrastructure. It may be my ignorance or maybe "eat your own dog food" works to some extent but is not a commandment. Anyway I think you could obtain a similar effect subscribing to the feeds of issue queues. Still I don't feel the review score system is going to work for contrib.
I like mailing lists. Wine-patches is just great for watching code that passes by. It'd be really useful as a tool by itself imho, although those other options already exist. You have to agree there is a slight but notable difference in actively subscribing/seeking something or passively get pushed the new code to your inbox.
That's different from imposing review scores on contrib. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Wednesday 11 March 2009 4:03:34 pm Marcel Partap wrote:
To Marcel: The stifle innovation argument is valid although you've called it invalid several times. You have proposed that 10 (not high profile) developer reviews would be required in order to commit code. Assuming you mean what you say and the overloaded developers (high profile) don't have an increased workload, then that means i need 10 reviews to get my code committed.
No that was not exactly what i proposed. The proposal (!) was to have a patch get autocommitted (if style checks run fine and no tests break) by a bot after receiving 10 RTBC vote 'points' and no veto status. The fact that needs to be taken into account here is the level of coding skills and experience of the reviewing person, f.e. by giving people like merlinofchaos chx dries karens etc. (i.e. who have proven to be capable working even on especially complex code) a voting weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital. That'd of course be an arbitrary decision - i'm sure though we could come up with something that worked.
So those "uber devs" with veto status would STILL have to police the rest of the issues to prevent auto-commits after ten people who don't know what they're talking about randomly +1 an issue. Fail. If chx saying +1 on a patch against one of my modules makes the patch commit without me agreeing, then I will not upload any of my modules to CVS. Period. That's not territoriality, that's basic software architecture. Any body of code needs some sort of directed design so that it maintains some level of consistency and coherence. What you're proposing would actively prevent that. Moreover, I may be working toward one particular architectural design decision and some other random patch would break it. Poof, it gets committed and breaks what I'm working on. That is unacceptable. Period. Besides, even uber-devs screw up big time now and again (more often than most people think), and auto-committing in those circumstances just breaks things. Voting on issues to give maintainers feedback on what users think is a high priority? Sure, that's useful information and I've openly said I'm in favor of that before. But the actual commit process MUST be done by a human, not a bot.
The solution i described means that you'd post your code to a drupal-patches mailing list, which would in turn create a patch queue entry. Now anyone just watching could quickly review the code from their mail reader and if they feel like making a decision, do so on the respective, or leave their comments either by replying to the mailing list post or the tracker item, which would in turn be sent to the respective other channel. Now once that piece of core - or a modified version that gets posted later to the tracker item - receives its 10 RTBC points and passes the mentioned checks, it gets committed automatically. That at least was my basic idea which of course might have plenty space for improvement.
Explain to me how having to email patches to a mailing list and then writing a mechanism to parse the patch out and create an issue for it, and then figure out if the patch is a follow-up to another patch (which the vast majority of patches are), and then losing all of the back and forth discussion that happens in the issue queue now is an improvement on having a central location for patches and discussion and screen shots that can be easily tracked, to which you can already subscribe via RSS or email and have been able to do so since long before I was involved in Drupal. No, on second though, don't explain it. Just stop. Your proposal gets worse every time you restate it.
I like mailing lists. Wine-patches is just great for watching code that passes by. It'd be really useful as a tool by itself imho, although those other options already exist. You have to agree there is a slight but notable difference in actively subscribing/seeking something or passively get pushed the new code to your inbox.
You like mailing lists. Great. I hate spam. So do most people. I don't think you realize just how many patches are submitted every single day just against core, to say nothing of contrib. Just because you like mailing lists doesn't mean we should gut a very effective patch management process. You want the patch firehose? Click the subscribe link on any project's issue queue and you can get all the push-based notifications your heart desires. You can do this *right now*, without having to create a few hundred hours work for other people that will just make it more difficult to develop for a project this size. Really, Marcel. Do yourself and everyone else a favor and just let it go. Your proposal was read, considered, and rejected. Reasons have been given. All you're doing is making yourself look like a crybaby because your pet idea was rejected by the people it would affect the most. Since I'm sure that's not what your intent is, I strongly urge you to simply let it go and find some other way to contribute. This proposal is not it. -- Larry Garfield larry@garfieldtech.com
That'd of course be an arbitrary decision - i'm sure though we could come up with something that worked. So those "uber devs" with veto status No no everyone would have be able to vote veto, only clearing would need response from a 'veteran' developer.
would STILL have to police the rest of the issues to prevent auto-commits after ten people who don't know what they're talking about randomly +1 an issue. Fail. Of course, only people who have landed code in the repo at least once do have a vote. Others can only comment, otherwise the code voting would be pretty useless.
If chx saying +1 on a patch against one of my modules makes the patch commit without me agreeing, then I will not upload any of my modules to CVS. Period. Well i think you quite didn't get that another point of the proposal was to take out the concept of individuals as module ow.. maintainers. You can submit code, if it's good it gets committed, if not it gets improved. Obviously the prospect of loosing ownership of 'their' code has brought up some fierce opposition though.
That's not territoriality, that's basic software architecture. Any body of code needs some sort of directed design so that it maintains some level of consistency and coherence. And to facilitate it, making the community design frameworks for stuff common to many modules' detailed functionality would be a start. That means that in the next few months, we would take part in this process and together engineer those frameworks, as basis for expanding them by our pet code later one.
What you're proposing would actively prevent that. Duh i thoroughly failed to get people to understand my proposal.
Moreover, I may be working toward one particular architectural design decision and some other random patch would break it. Poof, it gets committed and breaks what I'm working on. So you go and veto it, explaining that you are working on something, reasoning why it is the better approach to the problem at hand. That is unacceptable. Period. Besides, even uber-devs screw up big time now and again (more often than most people think), and auto-committing in those circumstances just breaks things. So auto-committing stuff after it received 10 vote 'points' and still passing the criterion of breaking no tests and having no coding standard collisions is more dangerous than just committing. Sorry, i do not follow.
Voting on issues to give maintainers feedback on what users think is a high priority? Totally not part of what i proposed. a) no more module maintainers, just (top) contributors. b) no users voting on code.
Sure, that's useful information and I've openly said I'm in favor of that before. But the actual commit process MUST be done by a human, not a bot. So other devs acknowledging the code before it gets auto committed does not qualify for that description?
Explain to me how having to email patches to a mailing list and then writing a mechanism to parse the patch out and create an issue for it, and then figure out if the patch is a follow-up to another patch (which the vast majority of patches are), and then losing all of the back and forth discussion that happens in the issue queue now is an improvement on having a central location for patches and discussion and screen shots that can be easily tracked, to which you can already subscribe via RSS or email and have been able to do so since long before I was involved in Drupal. Well obviously it's not, that's why i proposed something different: a cleverly integrated solution, where the discussion is synced on the mailing list and the patch tracking item.
No, on second though, don't explain it. Just stop. Your proposal gets worse every time you restate it. Maybe people dig deeper and deeper into misunderstanding it, despite me correcting that every single time. It does surely seem useless.
I like mailing lists. Wine-patches is just great for watching code that passes by. It'd be really useful as a tool by itself imho, although those other options already exist. You have to agree there is a slight but notable difference in actively subscribing/seeking something or passively get pushed the new code to your inbox. You like mailing lists. Great. I hate spam. So do most people. So don't frigging subscribe and use the channels you're used to, sheesh.
I don't think you realize just how many patches are submitted every single day just against core, to say nothing of contrib. a) yes i do and b) so because of the sheer amount of code that flows by, quality checks before committing would be a mistake. Sorry that does not convince me.
Just because you like mailing lists doesn't mean we should gut a very effective patch management process. Repeating myself does get ridiculous at some point but anyways: i never proposed to kill working operational procedures, because obviously that'd be stupid.
You want the patch firehose? Click the subscribe link on any project's issue queue and you can get all the push-based notifications your heart desires. Which makes me miss all the other code that is trying to get into the repo, what a great idea.
Really, Marcel. Do yourself and everyone else a favor and just let it go. I've already given up on making it happen, i'm just fighting for correcting the misunderestimation of the concept. Your proposal was read, considered, and rejected. No, it was read, misunderstood, considered and then rejected. Reasons have been given. Mostly either based on misunderstanding or emotions. And by the way i always get aroused by good points in a rational debate so i am actually looking for them.
All you're doing is making yourself look like a crybaby because your pet idea was rejected by the people it would affect the most. Really, i'm not. And how many people do have SVN accounts currently? How many of those have voiced their opinion? Does an idea being rejected based on gross misunderstanding actually correlate with the idea?
Since I'm sure that's not what your intent is, I strongly urge you to simply let it go and find some other way to contribute. My intent was to propose a solution to the problems i listed in the original posting, i am not going to repeat them.
This proposal is not it. What your idea of it is is definitly not.
-- "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
On Wed, 11 Mar 2009 13:45:14 +0100 Marcel Partap <mpartap@gmx.net> wrote:
I could even imagine that the content of this queue can be very interesting for all Drupalers Well that's the point. Have all Drupalers maintain the modules, not just a specific maintainer. Just like core, but supported by better tools..
That's not going to happen. Wine and the kernel are far different projects. There are already few reviewers for core. Don't expect to have reviewers for contrib. It is clearer how core gains from public review. It's not that clear how a maintainer may gain from code review. I'm not talking about quality of code... I'm talking about the interest of the maintainers. Core and contrib are quite different in terms of speed of development, purposes, design, coders sub-communities... People may use drupal infrastructure just if: - They're looking for public review - They're looking for co-maintainers - They're looking for exposure - They just feel "generous" and they think someone else may make good use of their code without bothering them Release early, release often refers to your users... not to everyone. If I can't release early and often for *my users* because someone else is not going to review my patch, I'm going to move my stuff elsewhere. If someone is pushing my module in a direction that doesn't fit *my users* I'm going to resist to the change. Very frequently the maintainer of a module is the one that keeps contributing the module most. You're starting from the unproved assumption that for every maintainer code review and exposure are a larger benefit than keep on being the steering committee of its own project and that drupal benefit more from a supposed increase of code quality and reduction in duplication than having a prolific competitive community of contributors. Otherwise you're heading to balkanization of contrib repositories. While I agree that natural selection may be suboptimal and rationally planning and channelling efforts may achieve better results in a shorter time[1]... natural selection is self testing and it already happens with no extra effort. Other theories have to be proved and require efforts to be put in practice. Now... if you've something better to substitute to natural selection and you can prove it is better, that's just the starting point as Laura Scott pointed out at the end of her post. If no one feels your hypothesis is worth a test, provide your own test. Then maybe you'll reach the point where "d(em)ocracy" and evolution sucks and you may start complaining ;) Otherwise there is no reason to accept "intelligent design" as a real competitor. [1] let's turn this into a flamewar about XP vs. waterfall vs. academia vs. corporate vs. opensource vs. emacs as well ;) -- Ivan Sergio Borgonovo http://www.webthatworks.it
There are already few reviewers for core. Don't expect to have reviewers for contrib. Well the idea was to convert all people currently posessing an SVN account the reviewing collective, not getting additional reviewers. Am i interested in the modules i have submitted codes for? Sure i am. Am i interested in the code quality / functionality of all the other modules aswell? YES i AM - because they all affect what and how i can use Drupal to accomplish stuff.
It is clearer how core gains from public review. It's not that clear how a maintainer may gain from code review. No more maintainers, just contributors. I'm not talking about quality of code... I'm talking about the interest of the maintainers. Well take them out of the equation. Anyone in fear of leaving his title as 'maintainer of module foo' should be soothed by the opportunity that per-module commit statics provide for fame.
Core and contrib are quite different in terms of speed of development, purposes, design, coders sub-communities...
People may use drupal infrastructure just if: - They're looking for public review - They're looking for co-maintainers - They're looking for exposure - They just feel "generous" and they think someone else may make good use of their code without bothering them Well my belief is that enforcing a community process on all developers for any D7 might be a good thing, strengthening the community and resulting in better code. And i highly doubt just out of pride people would take their module code elsewhere just because they won't be the sole 'owner' in the d.o repository.
Release early, release often refers to your users... not to everyone. If I can't release early and often for *my users* because someone else is not going to review my patch, I'm going to move my stuff elsewhere. Having your experimental code reside in a staging repository until the code is ready for being unleashed onto thousands of sites is too much of a pain to take?
If someone is pushing my module in a direction that doesn't fit *my users* I'm going to resist to the change. Veto the change, comment on your reasoning. Is too bad of a way to handle it?
Very frequently the maintainer of a module is the one that keeps contributing the module most. So uhhm that'd make them 'top contributor' instead of 'guy who holds the golden key'.
You're starting from the unproved assumption that for every maintainer code review and exposure are a larger benefit than keep on being the steering committee of its own project and that drupal benefit more from a supposed increase of code quality and reduction in duplication than having a prolific competitive community of contributors. Difficult to answer.. in my opinion most of the stuff that even can be done with a website is already available in some form or another as D6 module. Taking all this great innovative stuff in contrib, there's really not much stuff left to be desired. A lot of this code can be just migrated to D7, continuing as in past drupal version jumps. But having almost every thinkable use case already covered would allow us to take a different direction: cleaning up, merging and refactoring the existing modules, transplanting good code and skipping not-so-good. The competition that has been going on up to now already has created a huge pile of excellent stuff to pick from. Why not make the decision to not take the huge pile, but only the best part of it? Also, frameworks for basic shared functionality should be designed in a way that makes them as expandable and REPLACEABLE as possible, i.e. clear interface definitions. Having competition on that basic fundamental level of groundwork services (the prime examples again: notifications, web forms) in a project of this maturity level at least to me does not seem to be a good idea- because it REALLY REALLY isn't. Other people have stated why they support that statement.
Otherwise you're heading to balkanization of contrib repositories. Really have my doubts people would like to use modules that are not from the official d.o repository. Having all code committed only after quality reviews have been applied is more of an USP than anything other!
While I agree that natural selection may be suboptimal and rationally planning and channelling efforts may achieve better results in a shorter time[1]... natural selection is self testing and it already happens with no extra effort. Yeah so at this point we could look back at the pile of code it created and transplant ONLY THE GOOD PARTS of it into the D7 repository.
Other theories have to be proved and require efforts to be put in practice. Well apparently
Now... if you've something better to substitute to natural selection and you can prove it is better, that's just the starting point as Laura Scott pointed out at the end of her post. How can i prove that on my own? From my level of education on the object of process and quality management aswell as open source communities, i think it does.
If no one feels your hypothesis is worth a test, provide your own test. I'd gladly do everything i proposed myself (if only to show off) but time is the limiting factor again. Maybe i should have used the time debating here with people who misunderstand what i am trying to communicate to come up with a design draft for a D7 notification API, duh.
Then maybe you'll reach the point where "d(em)ocracy" and evolution sucks and you may start complaining ;) There's always this tiny fraction of people warning about shit tending towards the fan long before shit gets there. Not only the current climate change situation is a good example for that. Why is it that the majority can never be convinced to listen to such criticism BEFORE TSHTF?
[1] let's turn this into a flamewar about XP vs. waterfall vs. academia vs. corporate vs. opensource vs. emacs as well ;) ok let's try this: xp is to opensource as emacs is to .. ah well no let's not. marcel, tired of a debate not representing his proposal.
-- "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
On Friday 13 March 2009 00:12:49 Marcel Partap wrote:
marcel, tired of a debate not representing his proposal.
While I agree with most of the sentiments expressed by Kyle, catch, sun, Khalid, Earnie, Anton, Crell, Ivan, Andrew, Earl, and Laura, out of everything you've written, I find this part most unsettling. It suggests a deep ignorance of how communities like ours work. The community has heard you; whether or not we heard what you intended us to is _no longer in your realm of control_. Debate may get your point across in school or small groups, but that's not how communities work. Ideas take off only when community members get to own and interpret the ideas on their own terms, with respect to their own experience; badgering people for doing so is exactly the wrong approach. Personally, I find your apparent ignorance of this basic community dynamic to be sufficient evidence for not trusting you as a community captain. Keep in mind that this is coming from a guy who's spent the better part of a year planning, proposing, and advocating group decisionmaking systems for drupal. So, let me second Larry: Please, stop.
evidence for not trusting you as a community captain. Never did i strive to be any kind of captain, i just tried to help with an existing issue that happens to annoy me (and seemingly others). Guess the next time i'm trying to convince anyone of anything i'll make sure to bring the examples upfront (instead of at the end of a discussion) so there is no place to be misunderstood in the first place.
Please, stop. Fine. You (sceptics) win, i loose. Better luck next time.
regards marcel.
On Fri, Mar 13, 2009 at 10:57 AM, Marcel Partap <mpartap@gmx.net> wrote:
Please, stop.
Fine. You (sceptics) win, i loose. Better luck next time.
This is not a win or lose situation. Get involved, contribute, understand the project and community better, then reevaluate your stance in light of what you learned. Then see if you still hold the same view or you change your view. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Get involved, contribute, understand the project and community better, That i have done for one year. How that is not sufficient i do not see. And i don't open my mouth that wide if i can not provide solid and thoroughly reflected reasoning for my points, which i tried to.
then reevaluate your stance in light of what you learned. Constantly doing that, but i would be highly surprised if history would really prove me wrong. However of course i'd be more than ready to accept that. regards 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
On 11-Mar-09, at 7:50 AM, Daniel F. Kudwien wrote:
Given this list, a new project moderation queue would possibly be able to eliminate 75% of duplication causes.
I was going to suggest that we create a group to simply try this method out among those who are on this list and interested. But it looks like a group all ready exists! http://groups.drupal.org/contributed-module-ideas If it had the ability to tag a post with applicable modules, it might be very good. That way, you could do a listing of all posts where the solution was "views". A field for "use cases" might be good too. There's the site-wide tags field; is it possible to add taxonomy vocabularies per group with og? --Andrew
On Wednesday 11 March 2009, at 4:12 am, Marcel Partap wrote:
Except that those high-profile developers would need to troll through contrib to vote on stuff. Would not. On the contrary, all people writing Drupal code could handle all Drupal non-core code as a collective.
I see this as one fundamental misconception of what this community is. It's a do-ocracy. The results are from people doing -- scratching their own itch -- not from people working as drones or workers in a hive collective. The best innovation often comes when someone develops a better way to build the mousetrap. Forcing that innovation to collaborate with the existing hegemony in that feature area or go away is not going to be conducive to active development contributions, imho. In the free market, there are many instances of companies "duplicating" efforts out there, often with great success. There are many cases where "duplications" in contrib have resulted in better modules and the deprecation of the previous project. CCK's replacing of Flexinode is one example of many. We just did an upgrade of a site from 4.7 to 6, and at least half the modules did not have upgrade paths. However, nearly all of those had /better/ solutions available in Drupal 6, developed by different developers, found under different project names. In the end, the website is better than before.
The people i'd really like to have heard an opinion of are people like Dries, Angela and the maintainers of overly complex modules (CCK and Views mainly) however. But now the jury has made up their mind it is too late for the idea anyways.
This statement, to my mind, is an illustration of why this gatekeeper approach could not work effectively in this community. You are stating that you are feeling stifled and not getting the response you want. Imagine that feeling from every potential contributor to the community, who feels he or she has a great idea but the gatekeepers are preventing that contribution for whatever reason. My suggestion is that if you feel this is such an important thing, then don't feel stifled, just do it. Create an index of duplicated functionalities in projects, make it searchable, tagable, whatever, recruit collaborators, and establish the credibility of this approach. And attract people through demonstration, proving the concept. Build that collective and outperform all the individual efforts out there. Laura
Marcel You mentioned something more than once in two contexts: having requirements and planning beforehand saves time in the long run, and your professor in a quality course. Let me point out again that this is open source and not a corporate environment, and hence the difference. Basically everything we assumed about how corporate shops work does not work at all, or not as well in open source. Several years ago, when I was with a corporation, we got a professor from the top Canadian university to present on requirements. He made the point that the more time you spend on requirements the less time you will spend on implementation. As an aside, the same concept was being touted in the business arena in the 80s as "the Japanese way" of management. When I asked him how does this apply to open source, and the success it had without this lengthy centralized planning. He did not have an answer. Once you have hundreds and thousands of contributors who never met each other, spread across the globe, each scratching their own (or their client/employer's) itch, we have a new paradigm (yeah, another buzzword). You have organized chaos. This is also why Agile/Scrum is showing success, as opposed to the traditional waterfall method tried and tested for more than half a century. For us who came from a corporate, or those like you who are still in academia, it may be hard to adjust at first. But once you "get it", it is a wonderful thing to watch and join. So, jump in and "Do". Write about it 6 and 12 months from now and see if you have changed your mind, and what you learned. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
On 11/03/09 15:04, Khalid Baheyeldin wrote:
Marcel
You mentioned something more than once in two contexts: having requirements and planning beforehand saves time in the long run, and your professor in a quality course.
Let me point out again that this is open source and not a corporate environment, and hence the difference. Basically everything we assumed about how corporate shops work does not work at all, or not as well in open source.
Several years ago, when I was with a corporation, we got a professor from the top Canadian university to present on requirements. He made the point that the more time you spend on requirements the less time you will spend on implementation. As an aside, the same concept was being touted in the business arena in the 80s as "the Japanese way" of management.
When I asked him how does this apply to open source, and the success it had without this lengthy centralized planning. He did not have an answer.
Once you have hundreds and thousands of contributors who never met each other, spread across the globe, each scratching their own (or their client/employer's) itch, we have a new paradigm (yeah, another buzzword). You have organized chaos.
This is also why Agile/Scrum is showing success, as opposed to the traditional waterfall method tried and tested for more than half a century.
For us who came from a corporate, or those like you who are still in academia, it may be hard to adjust at first. But once you "get it", it is a wonderful thing to watch and join.
So, jump in and "Do". Write about it 6 and 12 months from now and see if you have changed your mind, and what you learned. -- Khalid M. Baheyeldin 2bits.com <http://2bits.com>, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
-- "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
(uuhm sorry about the former reply that ehh wasn't ready yet.)
Let me point out again that this is open source and not a corporate environment, and hence the difference. Basically everything we assumed about how corporate shops work does not work at all, or not as well in open source. Point true 80%. There are comparable situations, in which similar methods can successfully be applied.
When I asked him how does this apply to open source, and the success it had without this lengthy centralized planning. He did not have an answer. Once you have hundreds and thousands of contributors who never met each other, spread across the globe, each scratching their own (or their client/employer's) itch, we have a new paradigm (yeah, another buzzword). You have organized chaos. This it in fact very true. This is the great method of success for this kind of software. However as the project grows, you get into a situation where the chaos gets too big of a mess. Additionally, one thing an evolutionary software development process does achieve is building experience. Competition also does help in that phase. BUT this all takes part with D6 contrib - and is also creating problems. These can be solved by applying methods which are meant to filter by quality standards - but ONLY because we have such a huge stash of already working code to pick from! In the whole D6 cycle, i'd never have proposed to restrict code committing, just because of all the reasons people have brought up in this discussion! But because we DO have all that GPLed code available, and a great lot of skilled coders, we could now shift focus for D7 from creating modules for each use case to _building a structure that can handle each use case_. We can do so by selecting from all the great code there already is - but the process of careful structural design and _selecting good code_ is a procedure that will filter out all the (small) issues which have come up in the past such as code duplication, disregard of coding standards and low quality. If we want D7 to really rock as hard as possible, we surely want to minimize these problems. That is the reason why i still believe that overlaying a new method onto the drupal project and community as it stands now is a viable way to go. This would not have been the case at any point in time before - simply because we NEEDED the drastic level of competition and free form creativity!
So, jump in and "Do". Write about it 6 and 12 months from now and see if you have changed your mind, and what you learned. Ok well even though i might seem naive and immature at times, i actually have 'done', furthermore always reflect and adapt to reality as it is. I have been with this great project for almost a year, although with low visibility and only few code inside some of core and several modules. But i do have a good understanding of how open source projects work, really (duh i use hundreds of them, and contributed to a handful - still small stuff though, started programming only two years ago.. but getting better ;). Sometimes it really *is* all about the color of the damn bike shed ^ ^ regards 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
Marcel Partap wrote:
Well of course but i really missed some voices from those high-profile developers. BTW nothing would change for them, especially no increase in work-load.
If you would like a voice from a high profile developer, here is my voice: I find work on core to be incredibly, mind-numbingly dull. Not due to the work, but due to the difficulty of getting it committed. If i had to go through a gateway process on my own projects, where someone who doesn't even necessarily understand the project has to decide whether or not it gets committed was in the way, I would certainly have never ended up a big time Drupal developer. The openness of contrib allowed me to succeed on my own merits. It has allowed others to fail on their own merits. What it hasn't yet done is provided the community a way of letting people know about the successes and failures of developers. We need to focus on community moderation, not source code moderation.
Marcel, Drupal uses your idea on Drupal core. But we aren't linux and wine, we have a core and then a constellation of contrib. Best stuff then bubbles up through contrib (example is part of views and cck going into core for Drupal 7)... contrib is a test tube, a source forge (which works really well by committing mind farts and then folks vote by using or not using, community actually decides best quality). That way we get the most creativity, and the community decides in their use/reuse/discard attitude towards the modules. A thousand eyes of feature hungry users informs better than one pair of expert eyes. And frees up the expert to do his thing too, instead of bureaucratizing contrib. That's the Drupal way, and it rocks (for this particular application)! Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com On Mon, Mar 9, 2009 at 3:22 PM, Marcel Partap <mpartap@gmx.net> wrote:
Marcel, I don't know if you've noticed but you haven't managed to
visibly convince anyone your solution is a good one.
Well yes i do have noticed. Apart from 'don't like it' and 'messes with our ways' i have not heard any sound counter arguments though, but that might well be enough of an argument by itself in such a community project.
Especially not anyone who will bother to try and implement it.
Well if we all wanted to, we could make it. Easily: it's just a matter of breaking habits, and not even that drastically. Btw it works for other projects (linux, wine).
On the contrary, you have a whole host of people saying it isn't a
good idea and giving reasons why.
Like 'nah dont like'. (Almost) noone even picked my arguments in favor of such a process, or tried to think up how it could be made to work, or even propose something entirely different.
These people (not me mind you) are the dedicated volunteers that do
actually work hard to implement solutions to Drupals problems, and are each in their own way personally responsible for the current success of Drupal today.
Well of course but i really missed some voices from those high-profile developers. BTW nothing would change for them, especially no increase in work-load.
They do understand the background and developer culture of the
community, and the reasons behind Drupals success.
So that implies i don't do that, which is wrong. But to truly achieve excellence, sometimes you have to trade in a bad habit (casual developers committing code to the central repository) for a bitter pill (having all code not from already proven drupal master minds undergo a transparent quality screening) for long term profit (cure the contrib). It's simply people not liking bitter pills until they suffer severely from their sickness.. totally human.
Don't take this personally
Course not, but i would have hoped for some support. Without any community backing surely my idea does sound silly.
but your idea and justifications for it have an air of either ivory
tower academia or heavyweight process driven enterprise thinking about them.
Well it's not that my proposal is totally unrealistic. Only because no one is supporting it does it become so. Would Dries or Angela have proposed it, everybody and his dog would be up in flames of enthusiasm and surely consider it the right way to go.
Neither of which have a very good track record of actually getting
things done in a volunteer driven open source community where inspiration and enthusiasm is the biggest driver behind doing anything.
Who is trying to stop that. By preventing bull sh1t code from being committed to the official contrib? C'mon! We could easily set up a testing repository, set up a drupal-patches mailing list and nice up the issue tracker to facilitate more code centric work on stuff.
The rate of progress in both Drupal and the supporting
infrastructure over that time has been staggering.
Yes, true. So with all that gained, how are we possibly going to loose it through tighter quality management?
It's a tall order claiming that the environment or culture that
achieved that success is broken - especially since people have come along and announced that plenty of times in the past.
I didn't say it's broken, it just allows unlucky stuff to happen. Modifying it a bit could solve the problem for good. Not that this step is _required_, but maybe we as a *software* project would _profit_ from it.
Why should that claim be correct now, when it has been shown to be
false in the past?
A major core redesign is the best time to make these modifications. Why i proposed these changes i hope i have explained sufficiently.
Your proposal to have every D7 contrib commit vetted by some sort
of vote would just drive away the very enthusiasm and inspiration that drew in all the newbie contrib developers that grew up into veteran developers and core contributers (and that would be the single best way to kill Drupal).
Ahem, no. Why would anyone insist on committing every mind fart to the official drupal repository? Heck as stated above, how hard is it to have a staging branch? The main motivation to even waste my time in this discussion was to find a solution to the problems mentioned in the original posting:
- modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names - duplication (partial feature overlap with existing modules).
If anyone has a more viable solution at hand, i'm more than willing to surrender my effort to their proposal. Right now all i've heard is votes for natural selection. Surely that is one approach to it, but at least not my favorite. Also, almost every possible use case is covered by one or the other D6 module, making that 'no more innovation' argument really not that convincing. What is the point of producing D7 at all? Restructuring! How is that case invalid for non-core modules, simply don't see it. Furthermore, simply don't like the fact that individuals hold the keys to modules. The linux kernel f.e. handles this very differently: contributors get mentioned in the file header. Really, the linux approach of development is what i think drupal should hand pick some points from.
I certainly wouldn't bother releasing any Drupal
7 modules if that were the case.
You must be kidding.
And for a lot of modules (eg my
own), they simply don't have a user base capable of evaluating the quality of the commit
Code voting for developers only of course - sure all this needs implementing. Where's a will, there's a way.
In nearly all cases, the people doing the voting will know
far less about coding or the internals of the module than the author. It won't change much in terms of code quality - it will just add frustration to everyones experience.
Noone wants that, not even crazy me. But my belief still is: if we really want to find a way to improve the process, we can do it. If i stand alone, this is not a fight i'll waste my blood on.
BTW, i really wished i had the time to code all the stuff i'd like to, but obligations (you know.. school, work and stuff *g) shrink my visions to small compact pressed clumps that lay around. It would simply need some outside support to inflate them again, but convincing people to support something unknown nowadays doesn't seem to be too easy. Ah well.. back to work, the profane. regards
-- "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
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_q... ..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
I think Khalid is exactly right here. The low barrier to entry is one of the non-obvious secrets to Drupal's success. It helps sucks new people in, gets them connected to the community, and we all benefit as their skills and contributions grow. Clay Shirky's book, "Here comes everybody" is all about the fundamental change that the internet is sparking: the change from create-filter-publish, to create-publish-filter. It can seem like a small change, but it is unleashing a huge wave of energy and creativity into the world. And Drupal is benefiting from that wave, every bit as much more obvious projects, like Wikipedia or Flickr. Of course, drupal.org has been a little weak in terms of tools for harnessing the power of the group mind in filtering after publishing, and it can be frustrating trying to separating the wheat from the chaff on your own. Currently drupalmodules.com is the best place for viewing and contributing to the collective wisdom about existing modules, but http://drupal.org/project/usage is also a big step forward, and the drupal.org redesign will move the ball forward even more. I would say that anyone that feel passionately about this subject should get involved with the drupal.org redesign, and start contributing there, either with time and expertise, or with funding. cheers, -tao
Yes, your observation is correct, but ... so what?
We've always had stuff that falls off the face of earth. So what? The caravan continues on ...
The very first module I contributed (feedback) illustrates a point: It was started in 2002 by someone called "barry". I had it working I took it over in 2004 with totally new code for Drupal 4.5. Then "fago" overhauled it a lot in 2006. Over time, the contact module in core came along, and I stopped using feedback. Then in 2008 "sun" took it over and repurposed it with new code.
The "too many modules in contrib syndrome" can be taken as confusing, excessive, ...etc. but can also be taken as a sign of a healthy and vibrant community. So what if we have a few extra gigabytes of code? So what if they become unmaintained?
If we raise the barrier or block new entries we will be shutting ourselves off from being the platform for the new chx or the new merlinofchaos.
It does not matter ... if it is the wild wild west, then let it be. It is a small price to pay for innovation and the power of the masses. -- Khalid M. Baheyeldin 2bits.com <http://2bits.com>, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
On Sun, Mar 8, 2009 at 8:46 AM, Stella Power <stella@stellapower.net> wrote:
However, in the end, you get what you pay for!
Well, Drupal is free and you don't pay for it. :)
One of the things that surprised me when I started working with Drupal is the breadth of functionality that's left out of core. No automatic path aliasing? No subscribing to a post? Wait, I can't add more fields to my content types??? For a "Content Management System", Drupal core is _severely_ lacking in features. The logical end is that modules now have inflated importance to Drupal, because you (basically) can't do jack without at least some of them. This creates an odd disparity: the concept of "modules" refers to both one-off, unimportant, unfinished modules, AND to cck/views/pathauto, three modules you basically can't build a site without. -D
On Sun, Mar 8, 2009 at 1:09 PM, Domenic Santangelo <domenic@workhabit.com>wrote:
On Sun, Mar 8, 2009 at 8:46 AM, Stella Power <stella@stellapower.net> wrote:
However, in the end, you get what you pay for!
Well, Drupal is free and you don't pay for it. :)
One of the things that surprised me when I started working with Drupal is the breadth of functionality that's left out of core. No automatic path aliasing? No subscribing to a post? Wait, I can't add more fields to my content types??? For a "Content Management System", Drupal core is _severely_ lacking in features.
The logical end is that modules now have inflated importance to Drupal, because you (basically) can't do jack without at least some of them. This creates an odd disparity: the concept of "modules" refers to both one-off, unimportant, unfinished modules, AND to cck/views/pathauto, three modules you basically can't build a site without.
That is actually one of the strengths of Drupal. Core providing extensibility, and not trying to be everything for everyone, and farming out functionality to contrib. Contrib is where innovation happens faster than in core, because the "think it, code it, commit it, release it, download it, try it, improve it" cycle is faster in contrib. It is not dependent on a few core committers with limited times and hundreds of tasks to get it in. People who want to try something can do it faster and people download and test and improve it faster as well. The second thing is that there are many arguments of task X be done in a certain way, and not another. If core did something just one way, then all the others will be precluded without being tried in the field. By providing an extensible framework where people extend it in different ways, and "let the market decide" which one is better, or even if all of them exist at the same time, everyone wins. Over time, we continually re-evaluate and move stuff in and out of core as appropriate. We pick what has been proven and get it in core, like we are doing with fields now. And we send other parts to contrib. This is the open source way: It does not have to be perfect, just good enough, and then released to the community to tear apart, use, extend, remix, borrow, copy/paste, ...etc. Think of Linux: it is just a kernel and people take it and extend it, bundle it, port it so it runs on everything from cell phones to IBM mainframes to supercompters and many things in between. If Linus insisted on doing a distro early on, it may not have been as successful as it is now. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
So in my opinion the concern you voice is valid even for D6, it would have stiffled innovation to regulate code committs. But for D7, i believe the goal should shift from having a huge quantity of modules to expandable frameworks for areas like notifications, polls/web forms/questionaires, payment that provide coherent and flexible APIs to obliterate fuplicate attempts of providing the same functionality. If it takes a lot of time to migrate certain modules from D6 to D7, and just as much time to implement a totally new module for D7 which merges functionality, code and vision of several modules, i (as a student of engineering, specializing in construction and development) *very very very* strongly would support the later choice. It might be difficult and require changes, but in the long run it will be worth it.
That's a nice vision you have there. But it sounds like you only want to talk about it. Merging and rewriting most of those duplicated modules from scratch (e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc) requires a lot of development time - much more than simply porting them to yet another Drupal core version. To have any effect in the end, it also requires that all module maintainers agree on the "roadmap", which means that they will let their own, duplicated modules die in favor of the new, centralized module. This has been done before. Two examples: - Content profile module is the successor of Bio, Node profile, and Usernode modules, created after months of discussions between all maintainers, developers, and contributors of the previous modules. Given that Fields (CCK) are in D7 core now, this decision and joined effort for 6.x will ensure that there is a unique upgrade path to 7.x all developers can work on. - Wysiwyg API module is the successor of all client-side editor integration modules, because someone analyzed the anatomy of all previously existing modules and thought about a better, generic way to do it with Drupal. Almost none of the other maintainers and developers ever contributed to this vision, which is the reason for why the few developers of this project are completely buried with work, and Drupal users are (even more) confused about which module to choose/install. Because of that, we won't have better Wysiwyg support in Drupal 7 core.
Yes and no. Each piece of code needs to be written by someone who needs the functionality AND is passionate about it, ACK. But that should not inherently make him the person to solely be responsible for the code. Instead, every code contribution should be subject of a community process in which everyone caring about it reviews and contributes, without defining single individuals as maintainer of a module (though recording the credits for each individual submission). ...
Improvement and innovation requires in-depth knowledge about something. True. How does a more swarm-like approach to code committal hinder that? That'd just channel the flow more tightly.
People most often forget that maintaining a project is primarily about responsibility, once it is in the wild. Yet another example: If there was some bad, not carefully reviewed code committed to Views module, then 72,799 sites could go down. I have seen issues where 10 or more contributors reviewed and gave their thumbs up, but luckily there was this responsible maintainer who told them that the entire approach is wrong, followed by the proper way to do it. That is the primary job of maintainers (gate-keepers) and the reason for why it is both excellent and required to have separate, specialized knowledge and vision per project.
We have this system already. It is called "co-maintainers".
Well it doesn't systemicly solve the problem, as it really just expands the number of stressed individual developers who have responsibility instead of tackling the root cause that makes all this even possible: no enforcement of coding standards, no wider review of changes before committal, no opportunity for improvements to be made before committal, single individuals responsible for decisions.
If a project or maintainer does not adhere to Drupal's coding standards and best practices, there are most likely no co-maintainers. The reason is simple: Without adhering to them, other developers and contributors have very hard times to fix, improve, and advance on what's there. Your proposal really boils down to the question whether a project maintainer is open to improvements by the Drupal community and thereby takes the required, additional steps to ensure that the community is able to contribute. It's about following a certain paradigm - or not. No automated process or AI will be able to change the paradigms of humans who do not want to follow a certain paradigm.
But looking at how *quality* is at the top of the D7 agenda, it might be a wise idea to apply more pruning and gardening tactics in general also to the modules to _not_ end up in an impenetrable jungle thicket like the D6 contrib area. And swarm intelligence is just the right buzzword to do it..
We can measure quality in contrib (and there are plans to do so), but putting regulations onto contrib hinders innovation, evolution, contributions, and lastly freedom. That said, I was wrong in that our CVS licensing policy is the only constraint. Fresh Drupal developers who want to create a new project on drupal.org must pass an initial code review quality assurance. Because 99.9999% of all Drupalers are not really aware of that, I want to take the chance to publicly say THANK YOU to Andy Kirkham (AjK), who does an awesome job on carefully reviewing a bloat of CVS applications - mostly alone. We get several new CVS applications *each day*. Although there are a few other community members who are eligible to process CVS applications, he is the one who takes this on with the required responsibility, discipline, and motivation. That's an ungrateful job, because many applicants complain about the slow review process and in parallel, his hard and time-consuming work is not recognized throughout the community. :( Thank you, Andy! You are one of the most important people for Drupal. Without you, Drupal contrib would certainly be a pain. sun
...
Because 99.9999% of all Drupalers are not really aware of that, I want to take the chance to publicly say THANK YOU to Andy Kirkham (AjK), who does an awesome job on carefully reviewing a bloat of CVS applications - mostly alone. We get several new CVS applications *each day*. Although there are a few other community members who are eligible to process CVS applications, he is the one who takes this on with the required responsibility, discipline, and motivation. You're right, haven't noticed him although he probably also processed my application.. KUDOS Andy for bearing with the community ;)
That's an ungrateful job, because many applicants complain about the slow review process and in parallel, his hard and time-consuming work is not recognized throughout the community. :( Yeah being in the jury just never pay off.
Thank you, Andy! You are one of the most important people for Drupal. Without you, Drupal contrib would certainly be a pain. Wow i didn't realize it could be far worse.. Now on to the more profane stuff.
It might be difficult and require changes, but in the long run it will be worth it. That's a nice vision you have there. But it sounds like you only want to talk about it. Well admittedly starting the discussion is only a first small part. For much of the work i can not be of help simply because i have other obligations, but i volunteered for reimplementing a mailman/drupal integration module and would contribute as much as possible.
Merging and rewriting most of those duplicated modules from scratch (e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc) requires a lot of development time - much more than simply porting them to yet another Drupal core version. Well of course it does, but a) the structural sanity benefit might be worth it and b) the license doesn't prohibit code reuse ;)
To have any effect in the end, it also requires that all module maintainers agree on the "roadmap", which means that they will let their own, duplicated modules die in favor of the new, centralized module. No. It does require the community at large to do the work of discussing, drafting and finalizing the structural design of these new frameworks - module maintainers are not required, but of course their experience would be of tremendous use.
This has been done before. Fine. So uhm let's do.
- Wysiwyg API module is the successor of all client-side editor integration modules, because someone analyzed the anatomy of all previously existing modules and thought about a better, generic way to do it with Drupal. Almost none of the other maintainers and developers ever contributed to this vision, which is the reason for why the few developers of this project are completely buried with work, and Drupal users are (even more) confused about which module to choose/install. Because of that, we won't have better Wysiwyg support in Drupal 7 core. Shame on those module maintainers! But still, all is not lost. Let us try making it suceed and mirroring the process, without leaving current module maintainers out of the equation. By the way, a policy change like described would put more pressure on those maintainers - if they want to have at least some of their code run on D7 - they better be cooperative!
True. How does a more swarm-like approach to code committal hinder that? That'd just channel the flow more tightly. People most often forget that maintaining a project is primarily about responsibility, once it is in the wild. Ok now that's a valid point. Maybe it can be possible for people to take responsibility without having exclusive access rights to a module?
Yet another example: If there was some bad, not carefully reviewed code committed to Views module, then 72,799 sites could go down. So as that has not yet happened it seems responsible developers exist in the drupal community.. hurray! ;)
I have seen issues where 10 or more contributors reviewed and gave their thumbs up, but luckily there was this responsible maintainer who told them that the entire approach is wrong, followed by the proper way to do it. That's the scenario where the veto vote i proposed comes into play ;)
That is the primary job of maintainers (gate-keepers) and the reason for why it is both excellent and required to have separate, specialized knowledge and vision per project. Well if it work better, that'd be great. However not all individuals live up to these standards, which is why i think maybe the drupal dev collective at large can better fulfill this role!
Your proposal really boils down to the question whether a project maintainer is open to improvements by the Drupal community and thereby takes the required, additional steps to ensure that the community is able to contribute. My proposal was to shift the responsibility from individual persons to a community process, to minimize possible negative influence of those. The process should promote and support taking responsibility by anyone, and hinder the opposite.
It's about following a certain paradigm - or not. No automated process or AI will be able to change the paradigms of humans who do not want to follow a certain paradigm. True, _but_ individuals who do not want to follow the common shared values may be excluded from using the community to publish their code. That will teach them ;)
We can measure quality in contrib (and there are plans to do so), but putting regulations onto contrib hinders innovation, evolution, contributions, and lastly freedom. Yes and no. It restricts freedom, true. But why does experimental code need to be committed to the central repository, and how does enforcing an open development process hinder evolution?
-- "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
It seems we're falling into one of two sides of the old argument over design philosophies. One side says "do the right thing", the other believes "worse is better." One side builds monolithic jewels, the other side builds simple modular tools that while messy are simple to use and understand. More here: http://www.jwz.org/doc/worse-is-better.html There are also parallels here to a comparison of publishing on the internet and traditional publishing in print. Publishing a magazine or newspaper is expensive, very expensive. So nothing is printed until it passes through an army of editors, fact checkers, graphic designers etc. that mold the content into something special. Publishing on the internet is, on the other hand, extraordinarily cheap. Head over to wordpress.com and 5 minutes later, you have an international publishing platform -- for free. And millions of people have done that which is why the internet is now full of junk and useless or so critics will say. But it's still very easy to find very high-quality useful information on the internet. Why? Because there's tools which help filter out the good content by mining the collective intelligence of human of human interaction on the web. Google works its search magic by discovering which pages have the most "votes" from incoming links. Collaborative news sites such as digg, hacker news, reddit, and others work by voting. The best news bubbles up to the top. Memetrackers analyze new content and discover which topics are being discussed the most and push those conversational clusters to the top of the news page. And so on. Both systems of publishing content are filters -- the traditional system says -- "publishing is expensive, so we'll filter content *before*publishing." The second system says "we can't stop people from publishing -- so let's devise better filters to help the best content still come out on top." Many people will argue against the second system complaining about information overload -- "there's too much stuff on the internet, we need professional editors to help us know what to read." Clay Shirky talked about this awhile ago and said "there's no such thing as information overload, just filter failure." He expanded on the argument<http://www.cjr.org/overload/interview_with_clay_shirky_par.php?page=all> : So, the real question is, how do we design filters that let us find our way through this particular abundance of information? And, you know, my answer to that question has been: the only group that can catalog everything is everybody. One of the reasons you see this enormous move towards social filters, as with Digg, as with del.icio.us, as with Google Reader, in a way, is simply that the scale of the problem has exceeded what professional catalogers can do. But, you know, you never hear twenty-year-olds talking about information overload because they understand the filters they’re given. You only hear, you know, forty- and fifty-year-olds taking about it, sixty-year-olds talking about because we grew up in the world of card catalogs and *TV Guide*. And now, all the filters we’re used to are broken and we’d like to blame it on the environment instead of admitting that we’re just, you know, we just don’t understand what’s going on. Now I hope I'm not distorting Marcel's argument here (and if I'm wrong I'm sure he'll correct me :) when I say he's arguing that there's too many modules, too many "bad" developers, writing too much "bad" code and we'd be all better off if the module landscape was less messy and more prestine. Perhaps this is too neat but it seems his argument falls along the same lines as those who say we need professional editors to filter content before publishing. I think his idea is a bad one (for our situation -- it works great for manufacturing, magazines, skyscrapers, etc.) for many of the same reasons as others have argued. But we do need better filters to help us find the best and right modules to use (and I'm sure some duplicate modules are written simply because the author didn't *know* there was an existing solution). And I think the drupal community is already working very hard to do just that -- provide better filters to point site builders to the current "best-of-breed" modules for a given situation. Much of the drupal.org design was directed at that problem and the (still coming) Drupal distro revolution will also greatly help at standardizing the module selection and focusing developer effort. Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Sun, Mar 8, 2009 at 3:47 PM, Marcel Partap <mpartap@gmx.net> wrote:
...
Because 99.9999% of all Drupalers are not really aware of that, I want to take the chance to publicly say THANK YOU to Andy Kirkham (AjK), who does an awesome job on carefully reviewing a bloat of CVS applications - mostly alone. We get several new CVS applications *each day*. Although there are a few other community members who are eligible to process CVS applications, he is the one who takes this on with the required responsibility, discipline, and motivation.
You're right, haven't noticed him although he probably also processed my application.. KUDOS Andy for bearing with the community ;)
That's an ungrateful job, because many applicants complain about
the slow review process and in parallel, his hard and time-consuming work is not recognized throughout the community. :(
Yeah being in the jury just never pay off.
Thank you, Andy! You are one of the most important people for
Drupal. Without you, Drupal contrib would certainly be a pain.
Wow i didn't realize it could be far worse.. Now on to the more profane stuff.
It might be difficult and require changes, but in the long run it
will be worth it.
That's a nice vision you have there. But it sounds like you only want to talk about it.
Well admittedly starting the discussion is only a first small part. For much of the work i can not be of help simply because i have other obligations, but i volunteered for reimplementing a mailman/drupal integration module and would contribute as much as possible.
Merging and rewriting most of those duplicated modules from scratch
(e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc) requires a lot of development time - much more than simply porting them to yet another Drupal core version.
Well of course it does, but a) the structural sanity benefit might be worth it and b) the license doesn't prohibit code reuse ;)
To have any effect in the end, it also requires that all module
maintainers agree on the "roadmap", which means that they will let their own, duplicated modules die in favor of the new, centralized module.
No. It does require the community at large to do the work of discussing, drafting and finalizing the structural design of these new frameworks - module maintainers are not required, but of course their experience would be of tremendous use.
This has been done before.
Fine. So uhm let's do.
- Wysiwyg API module is the successor of all client-side editor
integration modules, because someone analyzed the anatomy of all previously existing modules and thought about a better, generic way to do it with Drupal. Almost none of the other maintainers and developers ever contributed to this vision, which is the reason for why the few developers of this project are completely buried with work, and Drupal users are (even more) confused about which module to choose/install. Because of that, we won't have better Wysiwyg support in Drupal 7 core.
Shame on those module maintainers! But still, all is not lost. Let us try making it suceed and mirroring the process, without leaving current module maintainers out of the equation. By the way, a policy change like described would put more pressure on those maintainers - if they want to have at least some of their code run on D7 - they better be cooperative!
True. How does a more swarm-like approach to code committal
hinder that? That'd just channel the flow more tightly.
People most often forget that maintaining a project is primarily about responsibility, once it is in the wild.
Ok now that's a valid point. Maybe it can be possible for people to take responsibility without having exclusive access rights to a module?
Yet another example: If there was some bad, not carefully reviewed
code committed to Views module, then 72,799 sites could go down.
So as that has not yet happened it seems responsible developers exist in the drupal community.. hurray! ;)
I have seen issues where 10 or more contributors reviewed and gave
their thumbs up, but luckily there was this responsible maintainer who told them that the entire approach is wrong, followed by the proper way to do it.
That's the scenario where the veto vote i proposed comes into play ;)
That is the primary job of maintainers (gate-keepers) and the
reason for why it is both excellent and required to have separate, specialized knowledge and vision per project.
Well if it work better, that'd be great. However not all individuals live up to these standards, which is why i think maybe the drupal dev collective at large can better fulfill this role!
Your proposal really boils down to the question whether a project
maintainer is open to improvements by the Drupal community and thereby takes the required, additional steps to ensure that the community is able to contribute.
My proposal was to shift the responsibility from individual persons to a community process, to minimize possible negative influence of those. The process should promote and support taking responsibility by anyone, and hinder the opposite.
It's about following a certain paradigm - or not. No automated
process or AI will be able to change the paradigms of humans who do not want to follow a certain paradigm.
True, _but_ individuals who do not want to follow the common shared values may be excluded from using the community to publish their code. That will teach them ;)
We can measure quality in contrib (and there are plans to do so),
but putting regulations onto contrib hinders innovation, evolution, contributions, and lastly freedom.
Yes and no. It restricts freedom, true. But why does experimental code need to be committed to the central repository, and how does enforcing an open development process hinder evolution?
-- "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
Well overall it seems my proposal does not find much support here, but anyways *g
There are also parallels here to a comparison of publishing on the internet and traditional publishing in print. Parallels, yes. But software is very different from news articles.
And millions of people have done that which is why the internet is now full of junk Well it is, and means not only wasting the time of those producing poor content, but especially of those who don't know how to properly use the filters.
Google works its search magic by discovering which pages have the most "votes" from incoming links. Collaborative news sites such as digg, hacker news, reddit, and others work by voting. The best news bubbles up to the top. Is not. The most popular news does. Quantity before quality - which is why many people have difficulties penetrating that thick layer of crap and spam to reach the real quality regions of the internet.
Both systems of publishing content are filters -- the traditional system says -- "publishing is expensive, so we'll filter content /before/ publishing." The second system says "we can't stop people from publishing -- so let's devise better filters to help the best content still come out on top." But what i am proposing is more like publishing it internally and not release until a sufficient number of people agree with the quality. Ah well the metaphor just doesn't hold. :)
Now I hope I'm not distorting Marcel's argument here (and if I'm wrong I'm sure he'll correct me :) Here i am fullfilling your prediction *g
when I say he's arguing that there's too many modules, too many "bad" developers, writing too much "bad" code and we'd be all better off if the module landscape was less messy and more prestine. Well i wouldn't have phrased it so negatively but basically, imho the current process just leaves to much room for people to fail and 'ungood' stuff to happen.
Perhaps this is too neat but it seems his argument falls along the same lines as those who say we need professional editors to filter content before publishing. But this is a very different matter. The point is not so much to make 'professionals' decide about what goes in and what not, but rather about a process that, although promoting creativity and innovative work, in the end guarantees that stuff that goes in is worth being there.
And I think the drupal community is already working very hard to do just that -- provide better filters to point site builders to the current "best-of-breed" modules for a given situation. But why create bad code to filter out in the first place? Setting up a tighter process for contrib code makes sure that developers do *have* to make sure they are in line with the Drupal standards. Maybe filtering out by popularity was enough of a solution for D6. Maybe it even is for D7 - but changing the process may prove to be even a better one.
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
On Sun, Mar 8, 2009 at 4:57 AM, Daniel F. Kudwien <news@unleashedmind.com> wrote: ...snip...
An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others.
The reason for that is that someone thought he/she could write something better, wrote it, and ended up with something that already exists. From then on, happy developers continued to improve the pre-existing thingy, while some others installed the duplicated thingy and advanced on that. The end result is: two parties that think either approach is wrong and a massive croud of users that thinks "And this is why Drupal sucks.(tm)"
Removing the duplication requires that those module maintainers (finally) come to that conclusion.
I remember watching the relevant discussions. I think the issue of the different subscription/notification modules is good evidence that the problem is often organic and not just a result of incompetence, negligence, or lack of information. On one side, we have some fine developers who can allocate only so much time and energy on a particular module, and will refuse big patches which could make them lose control or delay or break the module if they don't do much more work than they intended to do. On the other side, we may have also good developers with some particular need at the time, who offer a huge chunk of code. This is always a tough call for a responsible module maintainer, who can't even predict if the newcomer developer can/will continue to work on the project or will move on to something else. In the case of the subscription/notification modules, so far both project seem to be doing fine. Eventually one may win the users, or they may take different directions. Much more often, the newcomer developer moves on, and the maintainer says "I told you so". What about the argument for banning duplicate modules? A reason that this is not possible is the antithesis between the responsibility of the maintainer who wants to have a working module within the constraints of real life vs the apparent needs of the newcomer developer. Introducing a third party who will decide the fate of a project unaffected by these realities isn't such a good thing, since that third party can't force anyone to work. I think all we can do is ask for documentation of the differences and put some pressure on the people involved to make them "think aloud" about the particular situation and make sure that they have considered the consequences and the options. ...snip...
On Sun, 08 Mar 2009 03:03 +0100, "Marcel Partap" <mpartap@gmx.net> wrote:
One possible option could be to go some steps towards the linux model, in which all patches have to be signed off by a small team of core developers.
Linux is an operating system -- specifically, an eighteen-year-old elaboration of a thirty-seven-year-old operating system. Wine is end-user software developed by C programmers (using clean-room techniques and black-box testing) to match a spec that's defined by a fourteen-year-old commercial product. And Drupal is a modular software toolkit for the web, designed to be customized by several different audiences to suit a multitude of use cases, many of which hadn't been invented five years ago and some of which are being invented *now*. Drupal is open source. That's about all it has in common with these projects. In my earlier career, I worked in semiconductor factories where we weren't allowed to change the settings on a single knob without formal change orders, extensive experimental data, and an official review. Perhaps Drupal would be better if we used Intel's development model. Or maybe, just maybe, developing Drupal is a completely different problem from developing a microprocessor. -- mechfish -- Michael F Booth mike@michaelfbooth.com
Quoting Marcel Partap <mpartap@gmx.net>:
Hi fellow drupal devs, wanted to bring up a few points about module development for some time and i guess now that module development happens to be the hot topic of the day would be a good time.. While D6 is proving to be a great success and through contrib modules can be flexibly expanded to almost unlimited use case customizations, working with a whole bunch of modules on our site my experience is that quantity is not necessarily a good compensation for quality. Several problems just keep coming up: - modules spamming the watchdog table with E_ALL warnings - modules ignoring the style/documentation guide lines - applied insane programming(TM) techniques - undescriptive module names but by far the most serious one is - duplication (partial feature overlap with existing modules).
I like duplication overlap. In particular when that overlap provides better features than another module of like manner. There is code and then there is better code as you've noted in your first four points. The modules of importance will be upgraded by those who care. Others can pay for the upgrade of a module if they wish or take over the maintenance of that module themselves. IMO, the most serious is your second point of modules ignoring the style/documentation guide lines. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
participants (26)
-
Andrew Berry -
Anton -
Cog Rusty -
Damien Tournoud -
Daniel F. Kudwien -
David Metzler -
Domenic Santangelo -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
Ivan Sergio Borgonovo -
Khalid Baheyeldin -
Kyle Mathews -
Larry Garfield -
Laura Scott -
Marcel Partap -
Matt Chapman -
Michael F Booth -
Michael Favia -
Nancy Wichmann -
Nathaniel Catchpole -
Sam Boyer -
Stella Power -
Tao Starbow -
Thomas Zahreddin -
Victor Kane