Drupal 7 "When it's Ready"
I'm concerned about the sentiment in Dries' declaration of Drupal 7 will be released when it's ready. I know this has been hashed out before, for instance back in September with Disparity of Versions: Towards Creating a Sustainable Solution to the Disparity between Drupal Core and Contributed Modules (http://drupal.org/node/311893) (which was itself an eloquent continuation of a long-standing discussion). I still strongly believe that we're shooting ourselves in the foot when we continue to use "0 critical patches" as the sole metric of a core release. Core MUST BE informed by contrib. To do otherwise is to create a divide of development that means six to nine months of the vast majority of sites waiting on critical module updates. In the referenced thread, chx asked, "Creating a "golden" contrib has been discussed for very long. It's not clear what we would achieve and who would work on achieving that." Acquia has answered that quite well. Acquia has stepped up to fill in this need with their official "Acquia Drupal", with its list of 21 supported contributed modules. I applaud their efforts. To quote them, they address this need: "From the thousands of Drupal modules, Acquia has selected some of the most commonly used and essential community modules for building modern, social publishing websites without programming." Chx continued with "Also, the whole issue is IMO Drupal 6 specific. As Drupal 5 is such a fantastic release, people felt it's good enough to serve longer and redesigned the architecture of their modules. This is not something that will be repeated soon IMO. As the Drupal 7 cycle is made longer, the issue will smoothen itself out during the next half year." I believe that lengthening the core development cycle is an answer, but still not THE answer. The unstable releases have certainly been a boon, and it's exciting to see a few modules beginning to create unstable releases; this is core informing contrib, and webchick has really stepped up to the plate to make that happen. However, no matter the fanfare with which Drupal 7 will be released, few sites in the wild will upgrade until their required contrib modules have been upgraded to that version. Yes, Drupal 6 was exceptional in the time required before major adoption. In a nod to contrib, fields and views are going into core, which is a direct way of contrib informing core. But there will always be a new Views or CCK that takes off like wildfire, and there will often be times when adoption of a new release of core will be held up by waiting development on a new and complex contributed module. Maybe not Drupal 7, but if we don't address this concern in a systematic and thoughtful way, it will possibly happen by Drupal 8, and certainly by Drupal 9 or X. Another show-stopping factor in creating a new metric is agreement on what metric to adopt. The team that penned Disparity of Versions were intentionally agnostic to metric in their discussions. However, no matter how these golden modules would be selected, and regardless of how that could be gamed, the reality is there will always be important contributed modules that the community depends upon. We can look to Acquia and other companies to identify these modules for us. That's a good thing, and irrelevant to the discussion. In fact, if the community would step up and take responsibility for these issues, it would validate their efforts. I propose that we take the tool that was not yet available at the time of the original post. We now have a publicly available metric of modules at use in the wild. Let's just take the top 10, top 5, or even top 3 modules and call those our "golden modules". Create a new "Supported modules" that dynamically consist of these modules; that can be tweaked once we have some experience with it. Then don't release Drupal 7 until there are 0 critical issues in its queue, AND each of the Supported modules has an official release. The community already works with the modules they need to help with that effort; this gives them more incentive and validation. If a Supported module is not making sufficient progress in an acceptable amount of time, that's likely a sign that perhaps it should be removed from that tier and back into the wild of contrib, so that things are not held up unnecessarily. I strongly believe that these simple steps will make the release of Drupal 7, and each subsequent release, the best release ever. Thanks, Aaron Winborn
On Wed, Mar 4, 2009 at 11:29 AM, Aaron Winborn <winborn@advomatic.com> wrote: <great stuff> My sense (hope?) is that Drupal7 will only be released when "0 critical bugs AND drupal.org is upgraded." I think this should solve most of the problem you cite because drupal.org now and increasingly relies on many of the major modules. It may lead to some uncomfortable feelings (if we are 4 months after code freeze and no d.o upgrade in site, for example) but those uncomfortable feelings will fuel desire to work on the modules needed for d.o. That will also give time for developers of other modules. Regards, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
How about, no release until "0 critical bugs, drupal.org is upgraded, and 5 of the top 10 modules on http://drupal.org/project/usage are upgraded"? Of course, what you really want is for that metric to be met earlier in the cycle, so that some of the experience gained by upgrading drupal.org and the module can actually inform core. cheers, -tao Greg Knaddison wrote:
On Wed, Mar 4, 2009 at 11:29 AM, Aaron Winborn <winborn@advomatic.com> wrote: <great stuff>
My sense (hope?) is that Drupal7 will only be released when "0 critical bugs AND drupal.org is upgraded." I think this should solve most of the problem you cite because drupal.org now and increasingly relies on many of the major modules.
It may lead to some uncomfortable feelings (if we are 4 months after code freeze and no d.o upgrade in site, for example) but those uncomfortable feelings will fuel desire to work on the modules needed for d.o. That will also give time for developers of other modules.
Regards, Greg
I agree entirely that the expanding gap between core & contrib is a major problem, and one that seems to be underestimated by some core developers. However, I'm slightly concerned that establishing a set of golden modules in this way will stifle the evolution by natural selection that has served Drupal so well. To make the point, imagine if it had been decided that Drupal 5 was not ready for release until Flexinode was updated.... It's not so important to users that module X be available, but that feature Y be provided by some module; preferably with an upgrade path from module X, but that is secondary from a development perspective. Rather than golden modules, what we need are golden 'use cases.' Perhaps this takes the form of supported Profiles or Patterns. (I'll use the term 'profile' to mean any means of collecting modules and configurations for implementing a specific end-user functionality. I think installation profiles as currently supported by Drupal are severely lacking, having abandoned one in favor of database dumps for the time being.) It has been my experience that the lack of a D6 version for needed modules caused me to look for and find other, better solutions. Or it forced me to more closely analyze the strengths and weaknesses of the various solutions, to determine which is most worth my effort to upgrade myself. Also, I strongly suspect that it is often the case that the modules with a better underlying architecture are easiest to upgrade. A lag in upgrading a particular module may be a sign that it could be replaced by a better solution. Finally, supporting profiles instead of modules makes the system less susceptible to single points of failure. It takes less technical expertise to maintain a profile than it does to maintain a module. If I maintain the Community Events Management profile, and there's no e-mail reminder functionality available for Drupal 7, I can petition 3 or 4 different module developers to upgrade their module, or I can try to organize some developers to create a new, better one, to leverage the new DX features of Drupal 7. You may say, 'What about modules that are so generic that they are used in most any site?' I'd suggest that those are exactly the sorts of modules that should be included in Core. We're seeing this happen with CCK, and Views seems poised to follow shortly. We could even make the criteria for core eligibility more explicit: If a module is used in EVERY supported profile, then it should be moved to core in some form. (And the converse: if a module is not used by any supported profile, it should probably be removed from core.) One thing that would really help this is more street cred for profile maintainers. However about some front-page case studies for a couple profiles? Hey, Acquia, could you throw some money at a few profile maintainers to get them to really polish their profiles, or convert them into patterns & add the patterns module into your distro? All the Best, Matt http://www.NinjitsuWeb.com
Matt Chapman wrote:
I agree entirely that the expanding gap between core & contrib is a major problem, and one that seems to be underestimated by some core developers.
However, I'm slightly concerned that establishing a set of golden modules in this way will stifle the evolution by natural selection that has served Drupal so well. To make the point, imagine if it had been decided that Drupal 5 was not ready for release until Flexinode was updated.... Thank you for echoing my concerns exactly. This is a key tenet of the success of opensource. Unfortunately, i think that any attempt to define specific modules or even specific use cases (profiles) will fail in a similar fashion because the same argument applies to the use cases as each new version changes the capabilities of our platform and makes it more apt to various tasks and less apt to others.
I agree that the lag of module upgrade between 5 and 6 was undesirable but i don't think that it can be prevented with the increasing number of dependencies that are developing around important modules these days. Any attempt to do so would unwisely slow the pace of development in core and put us at a competitive disadvantage against other CMSs. Identifying the successful modules with many dependencies and incorporating them into core in an efficient matter seems to be key in preventing another lag similar to the last. With cck on its way in and views shortly behind i think that the worts may be behind us. Paradigm shifts arent easy. :) -- Michael Favia
Michael Favia wrote:
Thank you for echoing my concerns exactly. This is a key tenet of the success of opensource. Unfortunately, i think that any attempt to define specific modules or even specific use cases (profiles) will fail in a similar fashion because the same argument applies to the use cases as each new version changes the capabilities of our platform and makes it more apt to various tasks and less apt to others. Not if the selected profiles are based on popularity, and fluctuate accordingly. I.e., when the first alpha of a new Core appears, we check and see what the most used profiles are, and then the maintainers of those profiles are called upon to see to it that the functionality provided by their profiles is available at release time, or to bring on co-maintainers who can do so.
This way, Drupal's version changes are kept in line with they ways in which Drupal is actually being used. If a change prevents a major use case, I'd say we've got a serious problem. If a change breaks a major module, that's worth consideration, but in the end, it's just the nature of the moving drop. Matt NinjitsuWeb.com
Rather than venture any opinion at this point on what to do about selecting the date when Drupal 7 is "ready" I want to inject this, I think, factual[1] data point: The time it will take to update modules from Drupal 6 to Drupal 7 will be on average _longer_ than it took to update modules from Drupal 5 to Drupal 6. Because of some major rewrites of important modules like Views for Drupal 6, those modules may well updated sooner. But the API changes are vast in Drupal 7. Be aware and forewarned so as to consider the release date question with the proper perspective. -- ..chris [1] No, I do not have hard metrics to prove this assertion. I do feel very confident in my statement, having been involved in a project which updated or helped update roughly a hundred modules to D6. If there is any disagreement on the point, I hope we can discuss it in another thread so as to not sidetrack this one.
On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
But the API changes are vast in Drupal 7. Be aware and forewarned so as to consider the release date question with the proper perspective.
I agree, but we must think to a soft of "compatibility API", i think that is impossible to rewrite the world to every new Drupal release. We need a public stable API + Compatibility layer + new API Method, otherwise we've to reinvent the wheel every time. It's impossible a solution like this ? Cheers -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paolo Mainardi schrieb:
On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
But the API changes are vast in Drupal 7. Be aware and forewarned so as to consider the release date question with the proper perspective.
I agree, but we must think to a soft of "compatibility API", i think that is impossible to rewrite the world to every new Drupal release.
I take it you are new to Drupal development? We get this suggestion every time a similar discussion comes up. Luckily, every time the anser is: No.
We need a public stable API + Compatibility layer + new API Method, otherwise we've to reinvent the wheel every time.
It's impossible a solution like this ?
Pretty much, yes. A full compatibility layer would like affect performance big time and a less intrusive version is probably not worth anybody's time to write. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmvBP0ACgkQfg6TFvELooTFDQCdG6sFnWtZOCzivVjTn/2sGyDc Ew4AmgMiq3vwA68uOitvlEyoP8v7KpNX =WUlK -----END PGP SIGNATURE-----
On Wed, Mar 4, 2009 at 11:47 PM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paolo Mainardi schrieb:
On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
But the API changes are vast in Drupal 7. Be aware and forewarned so as to consider the release date question with the proper perspective.
I agree, but we must think to a soft of "compatibility API", i think that is impossible to rewrite the world to every new Drupal release.
I take it you are new to Drupal development?
Yes, i don't have contribute never to Drupal core, but i work on drupal development from a lot of time, and i've released some contribution, but this is not the point.
We get this suggestion every time a similar discussion comes up. Luckily, every time the anser is: No.
Sorry but i don't understand, why "luckily" the answer every time is no ? Pretty much, yes. A full compatibility layer would like affect
performance big time and a less intrusive version is probably not worth anybody's time to write.
But D7 not will be a less intrusive version, this is the point.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paolo Mainardi schrieb:
On Wed, Mar 4, 2009 at 11:47 PM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paolo Mainardi schrieb:
On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
But the API changes are vast in Drupal 7. Be aware and forewarned so as to consider the release date question with the proper perspective.
I agree, but we must think to a soft of "compatibility API", i think that is impossible to rewrite the world to every new Drupal release. I take it you are new to Drupal development?
Yes, i don't have contribute never to Drupal core, but i work on drupal development from a lot of time, and i've released some contribution, but this is not the point.
Maybe not.
We get this suggestion every time a similar discussion comes up. Luckily, every time the anser is: No.
Sorry but i don't understand, why "luckily" the answer every time is no ?
Because the bright people that develop Drupal have recignized that it is futile.
Pretty much, yes. A full compatibility layer would like affect performance big time and a less intrusive version is probably not worth anybody's time to write.
But D7 not will be a less intrusive version, this is the point.
"less intrusive version" was referring to the compatibility layer, not Drupal. Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and all were hailed as the end of Drupal as we know it because nobody would be able to update their modules in time, etc yadayada. We probably have had this discussions for even earlier versions but luckily I've managed to forget them. Executive summary: Compatibility layer == bad. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmvDXIACgkQfg6TFvELooRM4QCfW/f1CnAPGSRgF0/5OdGulqU3 bE8An19o7spFpg5ohbwD1AHsfI2QNytO =CpLf -----END PGP SIGNATURE-----
On Thu, Mar 5, 2009 at 12:23 AM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paolo Mainardi schrieb:
On Wed, Mar 4, 2009 at 11:47 PM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paolo Mainardi schrieb:
On Wed, Mar 4, 2009 at 11:10 PM, Chris Johnson <cxjohnson@gmail.com> wrote:
But the API changes are vast in Drupal 7. Be aware and forewarned so as to consider the release date question with the proper perspective.
I agree, but we must think to a soft of "compatibility API", i think that is impossible to rewrite the world to every new Drupal release. I take it you are new to Drupal development?
Yes, i don't have contribute never to Drupal core, but i work on drupal development from a lot of time, and i've released some contribution, but this is not the point.
Maybe not.
We get this suggestion every time a similar discussion comes up. Luckily, every time the anser is: No.
Sorry but i don't understand, why "luckily" the answer every time is no ?
Because the bright people that develop Drupal have recignized that it is futile.
Pretty much, yes. A full compatibility layer would like affect performance big time and a less intrusive version is probably not worth anybody's time to write.
But D7 not will be a less intrusive version, this is the point.
"less intrusive version" was referring to the compatibility layer, not Drupal.
Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and all were hailed as the end of Drupal as we know it because nobody would be able to update their modules in time, etc yadayada. We probably have had this discussions for even earlier versions but luckily I've managed to forget them.
Executive summary: Compatibility layer == bad.
I agree, but it's bat too rewrite from scratch every time a lot of code, like Views or CCK or Panels. Could be nicer have at least a stable API or a *drupalX-compat" plugin with older API, but bright people surely know this things better of me :) P. -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
Pretty much, yes. A full compatibility layer would like affect
performance big time and a less intrusive version is probably not worth anybody's time to write.
But D7 not will be a less intrusive version, this is the point.
"less intrusive version" was referring to the compatibility layer, not Drupal.
Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and all were hailed as the end of Drupal as we know it because nobody would be able to update their modules in time, etc yadayada. We probably have had this discussions for even earlier versions but luckily I've managed to forget them.
Executive summary: Compatibility layer == bad.
I agree, but it's bat too rewrite from scratch every time a lot of code, like Views or CCK or Panels.
Could be nicer have at least a stable API or a *drupalX-compat" plugin with older API, but bright people surely know this things better of me :)
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs between major releases, this will be the start of the end for Drupal, since it will either get bloated by a compatibility layer (more resources, slow, complexity, ...etc.), or Drupal will stagnate and no longer become a leading content management platform/application. Having said that, there is nothing stopping YOU (or others) from building a compatibility layers. Some people tried that from Drupal 4.6 to 4.7 after Form API was in core. We just don't want that to be in core. Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
P.
-- Paolo Mainardi
Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
-- 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
Come on people -- has anyone who's complaining about upgrading a module ever actually upgraded a module from one version to another? It's really not that hard -- especially with coder / deadwood. I upgraded a couple modules from Drupal 5 to 6 in only a couple of hours including testing. Deadwood automates most of the process. And to kill yet again the myth that keeps coming up again and again zombie-like -- the reason so many modules had trouble upgrading from 5 to 6 is because they were dependent on Views which took so long to upgrade not because of API changes but because it was completely rewritten over the transition. Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Wed, Mar 4, 2009 at 6:06 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
Pretty much, yes. A full compatibility layer would like affect performance big time and a less intrusive version is probably not worth anybody's time to write.
But D7 not will be a less intrusive version, this is the point.
"less intrusive version" was referring to the compatibility layer, not Drupal.
Basically, we've had similar discussions for Drupal 4.7, 5, and 6 and all were hailed as the end of Drupal as we know it because nobody would be able to update their modules in time, etc yadayada. We probably have had this discussions for even earlier versions but luckily I've managed to forget them.
Executive summary: Compatibility layer == bad.
I agree, but it's bat too rewrite from scratch every time a lot of code, like Views or CCK or Panels.
Could be nicer have at least a stable API or a *drupalX-compat" plugin with older API, but bright people surely know this things better of me :)
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs between major releases, this will be the start of the end for Drupal, since it will either get bloated by a compatibility layer (more resources, slow, complexity, ...etc.), or Drupal will stagnate and no longer become a leading content management platform/application.
Having said that, there is nothing stopping YOU (or others) from building a compatibility layers. Some people tried that from Drupal 4.6 to 4.7 after Form API was in core. We just don't want that to be in core.
Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
P.
-- Paolo Mainardi
Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
-- 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 Wed, 4 Mar 2009 20:06:14 -0500 Khalid Baheyeldin <kb@2bits.com> wrote:
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs
I think some more attention should be put on "so far". I never read a book on software development that suggest that writing from scratch is a good strategy but I admit having felt the pain of refactoring quite frequently I've read more books on how to fix the problems rather than how to get involved in a completely new set of problems ;) It could be that this is going to be part of drupal nature... since it is a tool for a still very dynamic environment where the set of problems change quite radically... but still... I wouldn't take it for granted that drupal development life-cycle and nature is going to be the same as it has been in the past. For the same reason I consider the argument of "let's stabilise the API" a legit argument as well... and it is just a matter of balance and context. I think the evolution of how fast API are going to change will follow the evolution of how much core is an application vs. a framework. I think one of the secret for success of drupal has been being halfway between a self sufficient application and a framework. This is a ideal spot for small to medium projects where you can add value with some tuning and the cost of rewriting is lower than the cost of missing a large improvement made to core. But the space for small shops is shrinking and the complexity of the overall drupal project is increasing. I wouldn't take for granted that the sweet spot is always where it used to be and factor in as much elements as I could to make a forecast. Maybe core devs belongs to "subset" of drupal community that has "its own itches", but the efforts of core to "scratch their own itches" may not be the best compromise to scratch the "collective itches" of the community that is *evolving*. I'm not saying that core devs are blind or insensible to community needs, I'm just saying that it's better to take nothing for granted and somehow this kind of discussions aren't pointless just because they are repeated. Panta rei. Orchestrating for this is one of the most valuable targets of software development especially in Open Source projects.
Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
Awesome. I've found http://drupal.org/project/deadwood That was easy. What were you referring to with "core"? Do you have any other pointers to tools, docs, secret recipe, everything that will help to port modules? I was just planning to write my own tool at least to spot changes in signatures. Are there any coding standards that could make porting easier? Core dev strategies that could make any change easier to digest? Maybe Kyle Mathews is right and we just need to try and all the tools, docs and efforts from the core team to make transitions as smooth as possible are already there... but is there some further knowledge, tool, strategy that could be deployed? Or just a linden tisane? thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On the documentation side of updating there is http://drupal.org/ update. If you are talking about modules see http://drupal.org/update/modules . Also note that, a number of module maintainers (for widely used projects) have openly said they would like to release versions of their modules when drupal 7 is released. Dries, also, said that releasing drupal 6 without drupal.org being updated to it was a mistake he doesn't want to see happen again. I would be careful about trying to legislate anything. Let's see how the community responds. It might be good to get a movement of maintainers to update their modules for drupal 7 when a good time comes for that (like after the code freeze). I think that would be better received and more likely to make a difference. On Mar 5, 2009, at 4:08 AM, Ivan Sergio Borgonovo wrote:
On Wed, 4 Mar 2009 20:06:14 -0500 Khalid Baheyeldin <kb@2bits.com> wrote:
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs
I think some more attention should be put on "so far".
I never read a book on software development that suggest that writing from scratch is a good strategy but I admit having felt the pain of refactoring quite frequently I've read more books on how to fix the problems rather than how to get involved in a completely new set of problems ;)
It could be that this is going to be part of drupal nature... since it is a tool for a still very dynamic environment where the set of problems change quite radically... but still... I wouldn't take it for granted that drupal development life-cycle and nature is going to be the same as it has been in the past. For the same reason I consider the argument of "let's stabilise the API" a legit argument as well... and it is just a matter of balance and context. I think the evolution of how fast API are going to change will follow the evolution of how much core is an application vs. a framework. I think one of the secret for success of drupal has been being halfway between a self sufficient application and a framework. This is a ideal spot for small to medium projects where you can add value with some tuning and the cost of rewriting is lower than the cost of missing a large improvement made to core. But the space for small shops is shrinking and the complexity of the overall drupal project is increasing. I wouldn't take for granted that the sweet spot is always where it used to be and factor in as much elements as I could to make a forecast. Maybe core devs belongs to "subset" of drupal community that has "its own itches", but the efforts of core to "scratch their own itches" may not be the best compromise to scratch the "collective itches" of the community that is *evolving*. I'm not saying that core devs are blind or insensible to community needs, I'm just saying that it's better to take nothing for granted and somehow this kind of discussions aren't pointless just because they are repeated.
Panta rei.
Orchestrating for this is one of the most valuable targets of software development especially in Open Source projects.
Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
Awesome. I've found http://drupal.org/project/deadwood That was easy. What were you referring to with "core"?
Do you have any other pointers to tools, docs, secret recipe, everything that will help to port modules?
I was just planning to write my own tool at least to spot changes in signatures.
Are there any coding standards that could make porting easier? Core dev strategies that could make any change easier to digest?
Maybe Kyle Mathews is right and we just need to try and all the tools, docs and efforts from the core team to make transitions as smooth as possible are already there... but is there some further knowledge, tool, strategy that could be deployed? Or just a linden tisane?
thanks
-- Ivan Sergio Borgonovo http://www.webthatworks.it
On Thu, Mar 5, 2009 at 1:16 PM, Matt Farina <matt@mattfarina.com> wrote:
On the documentation side of updating there is http://drupal.org/update. If you are talking about modules see http://drupal.org/update/modules.
Also note that, a number of module maintainers (for widely used projects) have openly said they would like to release versions of their modules when drupal 7 is released.
Indeed, the contrary, I believe that it is stable API that can make a valuable in enterprise environments. (SDL, DirectX, Carbon, Cocoa etc ...). We should begin to put these arguments on the table, backward and 'a subject that will' sooner or later be addressed.
Dries, also, said that releasing drupal 6 without drupal.org being updated to it was a mistake he doesn't want to see happen again.
Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...", because backward compatibility API doesn't exists. Could be possible have a more abstract API on top of new features, decoupling the implementation from the interface. P. -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
Dries, also, said that releasing drupal 6 without drupal.org being updated to it was a mistake he doesn't want to see happen again.
Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...", because backward compatibility API doesn't exists.
Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A 'backwards compatability API' would have had zero effect, possibly a negative effect on the Views upgrade process. Organic Groups AND Panels both rely on Views - so could only be updated fully once Views was at release candidate stage. I really wish people would familarise themselves with the issues at hand before mouthing off on this list about "we need to do this [useless thing which would have zero effect]". Even a tiny bit of research would show what the issues are, and it's not API changes in core - it's manpower helping out the commonly used modules to get upgraded. If you want to see contrib modules ready when Drupal 7 is, you can start now by providing and/or testing patches for your favourite modules to get them upgraded. There are also modules with development versions or even beta releases for Drupal 7 listed here - http://drupal.org/project/modules?filters=drupal_core:103&solrsort=title_sor... again I'm sure their maintainers wouldn't turn down patches when there's API changes in HEAD. Nat
On Thu, Mar 5, 2009 at 2:04 PM, Nathaniel Catchpole <catch56@googlemail.com>wrote:
Dries, also, said that releasing drupal 6 without drupal.org being updated to it was a mistake he doesn't want to see happen again.
Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...", because backward compatibility API doesn't exists.
Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A 'backwards compatability API' would have had zero effect, possibly a negative effect on the Views upgrade process.
My point is different, a backward compatibility API could run Views 1.x on D
5, this was the point.
I really wish people would familarise themselves with the issues at hand before mouthing off on this list about "we need to do this [useless thing which would have zero effect]". Even a tiny bit of research would show what the issues are, and it's not API changes in core - it's manpower helping out the commonly used modules to get upgraded.
Yes, it's not only "mouthing off", i'm developing with Drupal all days, i'm trying to be propositional with full respect for your work.
If you want to see contrib modules ready when Drupal 7 is, you can start now by providing and/or testing patches for your favourite modules to get them upgraded. There are also modules with development versions or even beta releases for Drupal 7 listed here - http://drupal.org/project/modules?filters=drupal_core:103&solrsort=title_sor... again I'm sure their maintainers wouldn't turn down patches when there's API changes in HEAD.
Nat
You confirm my theory, no pathces because API changes, i don't like at all, but it's the Druapl development cycle and if it's the the price to pay for a such great project. ;) -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
Paolo Mainardi wrote:
On Thu, Mar 5, 2009 at 2:04 PM, Nathaniel Catchpole <catch56@googlemail.com <mailto:catch56@googlemail.com>> wrote:
Dries, also, said that releasing drupal 6 without drupal.org <http://drupal.org> being updated to it was a mistake he doesn't want to see happen again.
Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...", because backward compatibility API doesn't exists.
Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A 'backwards compatability API' would have had zero effect, possibly a negative effect on the Views upgrade process.
My point is different, a backward compatibility API could run Views 1.x on D > 5, this was the point.
No, it can't. Drupal changed entire sub systems. Not just how the functions are called but how the data is stored and what the data signatures are. A 'backwards compatibility API' would have required KEEPING data around that would cause the system to run slowly. The performance would be a nightmare. When going from version to version, one of the advantages is that we can throw away paradigms that are unsuccessful. A backwards compatibility API requires us to keep those paradigms. Remember, an API is not just a bunch of function signatures. It is much, much deeper than that, and they would completely change the wya things have to be implemented. They would be a major burden, possibly MORE major than the effort of simply upgrading the modules to new APIs.
On Fri, Mar 6, 2009 at 5:23 AM, Earl Miles <merlin@logrus.com> wrote:
Paolo Mainardi wrote:
On Thu, Mar 5, 2009 at 2:04 PM, Nathaniel Catchpole < catch56@googlemail.com <mailto:catch56@googlemail.com>> wrote:
Dries, also, said that releasing drupal 6 without drupal.org <http://drupal.org> being updated to it was a mistake he doesn't want to see happen again.
Why it's happen ? Because big missing, "Views, OG, Panels etc...etc...", because backward compatibility API doesn't exists.
Views 2 (in Drupal 6) isn't compatable with Views 1 (in 5.x). A 'backwards compatability API' would have had zero effect, possibly a negative effect on the Views upgrade process.
My point is different, a backward compatibility API could run Views 1.x on D > 5, this was the point.
No, it can't.
Drupal changed entire sub systems. Not just how the functions are called but how the data is stored and what the data signatures are. A 'backwards compatibility API' would have required KEEPING data around that would cause the system to run slowly. The performance would be a nightmare. When going from version to version, one of the advantages is that we can throw away paradigms that are unsuccessful. A backwards compatibility API requires us to keep those paradigms.
Remember, an API is not just a bunch of function signatures. It is much, much deeper than that, and they would completely change the wya things have to be implemented.
A good API could change the implementation without changing the signatures, they not are strictly related, it's not the only practices to do the things. How is related from the data storage and API ? At API level, we don't do any assumption on how data is stored or how is the internal implementation, these are things to a lower (not API) level. I think could be possible to write a sort of more abstract general API on top of existent for expose a bunch of general "services" with Drupal versions compatilibity in mind. Could be a plugin. P. -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paolo Mainardi schrieb:
On Fri, Mar 6, 2009 at 5:23 AM, Earl Miles <merlin@logrus.com> wrote:
Remember, an API is not just a bunch of function signatures. It is much, much deeper than that, and they would completely change the wya things have to be implemented.
A good API could change the implementation without changing the signatures, they not are strictly related, it's not the only practices to do the things.
How is related from the data storage and API ? At API level, we don't do any assumption on how data is stored or how is the internal implementation, these are things to a lower (not API) level.
I think could be possible to write a sort of more abstract general API on top of existent for expose a bunch of general "services" with Drupal versions compatilibity in mind. Could be a plugin.
Yeah, but apparently nobody of the usual suspects is interested in doing your bidding. [x] Go away and come back when you've got code to show. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmw51UACgkQfg6TFvELooR4fwCeIcKs371dGktL5wA3LWPs5v1u 6m0AoKtQaxGEyzLkBRNsDQSqrGHWt7T5 =MItU -----END PGP SIGNATURE-----
On Fri, Mar 6, 2009 at 10:05 AM, Gerhard Killesreiter < gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[x] Go away and come back when you've got code to show.
Yeah, really nice, please relax Gerard. -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com
Paolo Mainardi wrote:
Yeah, really nice, please relax Gerard. Sorry for the curtness, but this isn't exactly the first time this argument has come up in the last 5 years and some people get tired of beating it to death. We have maintained a steady position that our willingness to break API on major version releases allows for more innovative work and less complex development of new features. It constitutes is one of our competitive advantages over other CMS solutions and allows us to focus our development efforts forward not backward. We fully understand the costs of following such a model and understand if it isnt something youre interested in, but nobody pulled the rug out from under you here. This is how its been and how it will be. It is a big reason that a lot of us are on this project instead of others whether we know it or not. We understand that this may scare off some enterprise customers seeking stability. We dont have stability yet and might not for along time. Your efforts and the efforts of everyone postulating the best way to release D7 would be best applied like they usually are in assistance upgrading the modules you care about :). Good luck. -mf
...and it is stated and reasoned in Drupal's mission and principles: http://drupal.org/node/65922 sun
Paolo Mainardi wrote:
On Fri, Mar 6, 2009 at 5:23 AM, Earl Miles <merlin@logrus.com <mailto:merlin@logrus.com>> wrote: nd
A good API could change the implementation without changing the signatures, they not are strictly related, it's not the only practices to do the things.
How is related from the data storage and API ? At API level, we don't do any assumption on how data is stored or how is the internal implementation, these are things to a lower (not API) level.
I think could be possible to write a sort of more abstract general API on top of existent for expose a bunch of general "services" with Drupal versions compatilibity in mind. Could be a plugin.
I'm sorry, you just told me that I'm wrong. Which is it: a) You believe I don't know what I'm talking about. b) You believe I am lying. Seriously. This is NOT just about function signatures. Drupal's API is not just a set of functions. It's about events, timing, and it is about data storage. You can *say* until you're blue in the face that these things are not true, but that will not make you right. I frankly find it distressing that people who say how easy it would be to have a backward compatibility API are people who clearly don't actually understand the codebase.
There are UNSTABLE tags for HEAD. Angie announces them here regularly so if you are using this list then you know about them. Check one out, port a module. No need to chase HEAD. By the time the code freeze comes, we can port drupal.org to D7 if this happens, write the missing tests and release in two months. We just need people not to waste their and others time on this list but crack open the editor and get coding. There are countless advantages to this even if you need to do a bit of work to port from UNSTABLE-5 to the next version, if you need arguments, just read the original issue. http://drupal.org/node/190901 Best Karoly 'chx' Negyesi
Paolo Mainardi wrote:
I think could be possible to write a sort of more abstract general API on top of existent for expose a bunch of general "services" with Drupal versions compatilibity in mind. Could be a plugin.
Earl Miles wrote:
I frankly find it distressing that people who say how easy it would be to have a backward compatibility API are people who clearly don't actually understand the codebase.
Ah, the idealism of youth, and the bitter wisdom of experience. :-) I remember making the same arguments as Paolo with people who are much smarter than me. Then I actually started writing and upgrading modules. I now know it's much easier the just upgrade the modules I actually use in the real world than to dream about a theoretical compatability layer for the benefit of the 3,950 modules I'll never need. (But it's easier still to complain and avoid real work altogether, believe me, I know.) Could Core Developer do more to make module upgrades easier for the rest of us? In theory, yes, but I'd rather they spent their time using their superior brain power to make Drupal more awesome. The rest of us can easily enough follow their excellent instructions for upgrading our modules, which are practically paint-by-numbers easy. We also get a leaner code base. It's a win-win. Drupal is moving in a direction or more and more abstraction (DB:TNG), so I predict that it will get easier and easier to upgrade modules over time. It's not like Earl and Karoly and the gang want it to be hard. Even now, I've 'upgraded' a couple modules from 5 to 6 with only one or two lines of code changed. How much more can you ask for? That said, Paolo, if you see a particular function change which could done in an equally effective way, while preserving compatibility, I'm sure a patch would be considered. The issue queue is open to everyone. Best, Matt
Not to criticize or insult anyone, but more to address a perhaps common fallacy: core developers are not necessarily "smarter" than the rest. There are some really smart people out there, both core and non-core developers, and even just non-developers. What makes core developers who they are is a combination of things. Having "superior brain power" doesn't hurt. But it includes dedication, ability to spend more time on the project, desire, demonstrated contribution, sometimes history, some luck, and no doubt more than a few other things. Thomas Edison said: "Genius is one percent inspiration and ninety-nine percent perspiration." I think that applies here. Just to reiterate -- I respect the "brain power" of all core developers -- in fact, of all contributors. Don't be intimidated into not contributing. ..chris On Sat, Mar 7, 2009 at 12:39 AM, Matt Chapman
Could Core Developer do more to make module upgrades easier for the rest of us? In theory, yes, but I'd rather they spent their time using their superior brain power to make Drupal more awesome. The rest of us can easily enough follow their excellent instructions for upgrading our modules, which are practically paint-by-numbers easy. We also get a leaner code base. It's a win-win.
On Thu, Mar 5, 2009 at 4:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it>wrote:
On Wed, 4 Mar 2009 20:06:14 -0500 Khalid Baheyeldin <kb@2bits.com> wrote:
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs
I think some more attention should be put on "so far".
I never read a book on software development that suggest that writing from scratch is a good strategy but I admit having felt the pain of refactoring quite frequently I've read more books on how to fix the problems rather than how to get involved in a completely new set of problems ;)
Most of the books are geared to corporate/commercial environment where there is a central authority directing everything, a limited pool of people resources with known skill levels to do the work, and a budget set by the business. This is open source where all the rules are broken: we have a larger pool of talent with varying skill levels, they do the work on their own as they have the time to do it, for fun or profit or both, and anyone can jump in and create patches for any project and ask for reviews. It does not have to perfect from day 1: it just has to be good enough and released early so others can refine it. I maintain/co-maintain 37+ modules (since I last checked) and it would be insane if I would have to upgrade them all. Instead, for a couple of core releases, people upgrade them as they need them and submit patches. It works wonderfully. Organized chaos! It could be that this is going to be part of drupal nature... since
it is a tool for a still very dynamic environment where the set of problems change quite radically... but still... I wouldn't take it for granted that drupal development life-cycle and nature is going to be the same as it has been in the past. For the same reason I consider the argument of "let's stabilise the API" a legit argument as well... and it is just a matter of balance and context. I think the evolution of how fast API are going to change will follow the evolution of how much core is an application vs. a framework. I think one of the secret for success of drupal has been being halfway between a self sufficient application and a framework. This is a ideal spot for small to medium projects where you can add value with some tuning and the cost of rewriting is lower than the cost of missing a large improvement made to core. But the space for small shops is shrinking and the complexity of the overall drupal project is increasing. I wouldn't take for granted that the sweet spot is always where it used to be and factor in as much elements as I could to make a forecast. Maybe core devs belongs to "subset" of drupal community that has "its own itches", but the efforts of core to "scratch their own itches" may not be the best compromise to scratch the "collective itches" of the community that is *evolving*. I'm not saying that core devs are blind or insensible to community needs, I'm just saying that it's better to take nothing for granted and somehow this kind of discussions aren't pointless just because they are repeated.
From what I explained, the "so far" is still valid, so need to change it for D7.
We always adapt and if we feel like D8 needs to change that, then we cross that bridge when we get to it.
Panta rei.
Orchestrating for this is one of the most valuable targets of software development especially in Open Source projects.
Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
Awesome. I've found http://drupal.org/project/deadwood That was easy. What were you referring to with "core"?
Typo. Should read coder: http://drupal.org/project/coder Again the best asset of Drupal is not modules, or code. It is the volunteer base. They will jump in and upgrade stuff for you as they need it.
Do you have any other pointers to tools, docs, secret recipe, everything that will help to port modules?
Help the modules you care about by submitting patches, testing patches, improving the README and other documenation.
I was just planning to write my own tool at least to spot changes in signatures.
See coder above. Help improve it if you like it.
Are there any coding standards that could make porting easier? Core dev strategies that could make any change easier to digest?
Again, coder checks a lot of that.
Maybe Kyle Mathews is right and we just need to try and all the tools, docs and efforts from the core team to make transitions as smooth as possible are already there... but is there some further knowledge, tool, strategy that could be deployed? Or just a linden tisane?
Perhaps a guide in the hand book will help: "a quick guide to upgrading modules from a previous version to a current version" with all of the above info and much more. Any volunteers?
thanks
-- Ivan Sergio Borgonovo http://www.webthatworks.it
-- 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 Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I was just planning to write my own tool at least to spot changes in signatures.
Already done. In terms of docs, it is implemented on api.drupal.org, in terms of module upgrade mistake checking, it is implemented in coder.module. Gábor
api-contrib.drupal.org would be nice... :D ----- Original Message ----- From: "Gábor Hojtsy" <gabor@hojtsy.hu> To: development@drupal.org Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready" On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I was just planning to write my own tool at least to spot changes in signatures.
Already done. In terms of docs, it is implemented on api.drupal.org, in terms of module upgrade mistake checking, it is implemented in coder.module. Gábor
Niel has this on his TODO list :) Gábor On Thu, Mar 5, 2009 at 2:06 PM, Aaron Winborn <winborn@advomatic.com> wrote:
api-contrib.drupal.org would be nice... :D
----- Original Message ----- From: "Gábor Hojtsy" <gabor@hojtsy.hu> To: development@drupal.org Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready"
On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I was just planning to write my own tool at least to spot changes in signatures.
Already done. In terms of docs, it is implemented on api.drupal.org, in terms of module upgrade mistake checking, it is implemented in coder.module.
Gábor
+100 for api-contrib.drupal.org go Niel !!! On Thu, Mar 5, 2009 at 6:36 PM, Aaron Winborn <winborn@advomatic.com> wrote:
api-contrib.drupal.org would be nice... :D
----- Original Message ----- From: "Gábor Hojtsy" <gabor@hojtsy.hu> To: development@drupal.org Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready"
On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I was just planning to write my own tool at least to spot changes in signatures.
Already done. In terms of docs, it is implemented on api.drupal.org, in terms of module upgrade mistake checking, it is implemented in coder.module.
Gábor
Aaron Winborn wrote:
api-contrib.drupal.org would be nice... :D
Sorry if this has already been pointed out. I've had a hard time keeping up with the pace of conversation today: http://api.freestylesystems.co.uk/
I would like to see Drupal shops start setting up API sites for their modules and start filing issues to solve what comes up when you have lots of code mixed in one site. We need: * Another column to add a concept of project * Integrate with update status to get the right system for each module * Add navigation so users know where they are in the site * How should searching be handled? * Report documentation coverage to the module page on Drupal.org. I'll be working on API module at the DC code sprint as one of my many projects. Find me if you want to help. -Neil On Thu, Mar 5, 2009 at 8:06 AM, Aaron Winborn <winborn@advomatic.com> wrote:
api-contrib.drupal.org would be nice... :D
----- Original Message ----- From: "Gábor Hojtsy" <gabor@hojtsy.hu> To: development@drupal.org Sent: Thursday, March 5, 2009 7:57:50 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] How to port modules? was: Drupal 7 "When it's Ready"
On Thu, Mar 5, 2009 at 10:08 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I was just planning to write my own tool at least to spot changes in signatures.
Already done. In terms of docs, it is implemented on api.drupal.org, in terms of module upgrade mistake checking, it is implemented in coder.module.
Gábor
-- Neil Drumm http://delocalizedham.com
Hi, I apologize right in front - I'm new to Drupal development (so neither to programming nor to php/webprogramming), nevertheless I want to voice some of my concerns regarding "core" vs "profiles", as the problem was mentioned in the discussion /Drupal 7 "When it's Ready"/. Matt Chapman schrieb:
You may say, 'What about modules that are so generic that they are used in most any site?' I'd suggest that those are exactly the sorts of modules that should be included in Core. We're seeing this happen with CCK, and Views seems poised to follow shortly. We could even make the criteria for core eligibility more explicit: If a module is used in EVERY supported profile, then it should be moved to core in some form. (And the converse: if a module is not used by any supported profile, it should probably be removed from core.)
One thing that would really help this is more street cred for profile maintainers. However about some front-page case studies for a couple profiles?
I am a big fan of modular development - and in my eyes modular development means: Keep core as minimal as possible and provide modules and module-packs. For Drupal this would mean: A minimal core (might include minimal CCK and Views (API), but e.g. not Blog or Forum) that is required, abd not a single optional module. Then provide some "standard profiles/usecases". Most users would download the standard profile (thus including e.g. Blog, Forum and Views UI). Replace the standard download link with a link to the standard profile. What is the difference? Core is more critical then optional modules. Thus every module-update has to be part of a core-update - while updating single non-core modules is far easier for both, the developer and the user. A minimal core thus provides the highest flexibility. You can e.g. see that in Drupal - core modules tend to develop much slower then contrib ones. This is ok, but does Drupal really need a large Core? For the average user (and even the average developer) a minimal core with a standard profile wouldn't change anything. This would change the scope of profiles, but I think it would be for the best.
It's not so important to users that module X be available, but that feature Y be provided by some module; preferably with an upgrade path from module X, but that is secondary from a development perspective.
I agree - and believe that this again is an argument in favor of "minimal core, maximal profile".
Rather than golden modules, what we need are golden 'use cases.' Perhaps this takes the form of supported Profiles or Patterns. (I'll use the term 'profile' to mean any means of collecting modules and configurations for implementing a specific end-user functionality. I think installation profiles as currently supported by Drupal are severely lacking, having abandoned one in favor of database dumps for the time being.)
I agree. Profiles would need to be changed into something more generic. In fact, an automatic download tool in combination with use-cases would solve even more problems: Use-cases (or profiles) could be downloaded/selected, and the needed modules are automatically downloaded and installed. I agree, that quite a couple of professional webmasters wouldn't use automatic downloaders out of the box - but they should be able to download needed modules by themselves, provided the use-case lists the needed modules. A use-case could e.g. be a module with requirements, but without content (define what modules you need for the given use-case, possible link them together, but provide no functionality for yourself). If a use-case needs functionality that is not defined in any module - add a corresponding module. If the functionality is only needed in the given use-case, add it to the use-case module. This would allow a much more flexible combination of use-cases/profiles, it would allow for extending use-cases (e.g. Blogpage, Reviewblog extends Blogpage, etc)
Finally, supporting profiles instead of modules makes the system less susceptible to single points of failure. It takes less technical expertise to maintain a profile than it does to maintain a module. If I maintain the Community Events Management profile, and there's no e-mail reminder functionality available for Drupal 7, I can petition 3 or 4 different module developers to upgrade their module, or I can try to organize some developers to create a new, better one, to leverage the new DX features of Drupal 7.
Again: I believe that this is an argument pro "profiles" and against "core" as it would be easier to maintain a set of use-cases/profiles with a minimal core, provided use-cases could include other use-cases. -- Mit freundlichen Grüßen / Best regards / Saludos cordiales *Sebastian Nerz* ___________________________________________ *Orestes* Eduard-Spranger-Str. 56 D-72076 Tuebingen - Deutschland Of. : +49-7071-56519-30 - Fax : +49-7071-56519-31 www.orestes-sol.com <http://www.orestes-sol.com/> s.nerz@orestes-sol.com <mailto:s.nerz@orestes-sol.com> ___________________________________________
On Wed, Mar 4, 2009 at 11:29 AM, Aaron Winborn <winborn@advomatic.com> wrote:
I'm concerned about the sentiment in Dries' declaration of Drupal 7 will be released when it's ready. I know this has been hashed out before, for instance back in September with Disparity of Versions: Towards Creating a Sustainable Solution to the Disparity between Drupal Core and Contributed Modules (http://drupal.org/node/311893) (which was itself an eloquent continuation of a long-standing discussion).
Dries did not say anything about D7 that should cause concern. He just said "when it is ready" and we can all discuss what that means. You are assuming it excludes Contrib. But even more productive IMO would be to discuss what we can do to help modules upgrade quickly. Lets not even get into the reasons why D6 Contrib adoption was slow. What documentation is needed beyond the upgrade page (screencasts, coder/deadwood, .webinars, ...). Can we provide testing infrastructure for contrib modules? Could we focus the issue queue so issues about upgrading are more easily handled?
There's a few contributors who are really into the Drupal project, but I would guess most contributors don't upgrade their modules until they have to. Until there's a D7 release, there will be no need for people to upgrade their modules, and so they won't. I know because that's what I do. I need a functionality that doesn't exist, I write the module for it, and then I contribute it back for other people who might want it. I will apply patches sent to me (and give other people CVS access), but beyond that I won't develop the module further as long as it does what I want. That means I won't port it to D7 until I need it on a D7 site ; and that won't happen until D7 is out. This is not an uncommon thing in the floss world ; KDE 4.0 comes to mind as a good example. -- ------------------------------ (to send me personal email, remove the _list from this address)
participants (22)
-
Aaron Winborn -
Anselm -
Chris Johnson -
Daniel F. Kudwien -
Dipen -
Earl Miles -
Gerhard Killesreiter -
Greg Knaddison -
Gábor Hojtsy -
Ivan Sergio Borgonovo -
Karoly Negyesi -
Khalid Baheyeldin -
Kyle Mathews -
Matt Chapman -
Matt Farina -
Michael Favia -
Moshe Weitzman -
Nathaniel Catchpole -
Neil Drumm -
Paolo Mainardi -
Sebastian Nerz -
Tao Starbow