On Mon, 28 Apr 2008 08:46:03 -0500 "Michelle Cox" <shellmultimedia@gmail.com> wrote:

On Mon, Apr 28, 2008 at 6:29 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:

...

There are things that should be considered obsolete on the drupal handbook as the OOP policy and the security policy... and a "myth" that the community seems to be proud of: Drupal is a moving target and we aren't scared to break the API.

This isn't a myth. Drupal _is_ a moving target. It sounds to me like you want to change the docs from how things are to your vision of how things should be. That would make the docs inaccurate as the policy isn't going to suddenly change because a doc page does.

As far as I know, the OOP policy hasn't changed, either, but I'm not deep enough into dev to know for sure. What's wrong with the security policy? The rest of your post is just a complaint about Drupal breaking backwards compatability and doesn't actually explain what you think is obsolete about either the OOP or security policies.

Things change even if policies don't. In fact D7 is going to use PDO, that's something that require OOP. The dev cycle was already changed and that was reflected in the docs as I pointed out in my previous email. Victor Kane made a very good comment as well. That's one of the things that is making Free Software less free than it was used to be. SimpleTest is great to help contrib too. The fact that Views and CCK (that actually are complex modules etc...) still need to be ported, the numbers I cited in the previous email etc... should be a sign that the policy should be adjusted. That doesn't mean core have to stop to be revolutionary on some aspect but that new needs should be taken into account when deciding what to change, how fast and how. A better API makes many modules obsolete and I agree that the raw number on D5 vs. D6 contrib modules is not a clean indication on the effect of fast changes in a different environment (etc... etc...). Here discussion spend a lot of time on the Docs problem http://drupal.org/node/132496 but the more the project is mature the less simple modules you'll find cos the API is better the more you'll see thousands lines modules developed. When you've to port a 400 line module it is one task, when you've to port a 5000+ lines module it is a different job. If you change 3 different parts of the API in one round, porting modules will be a harder task than if you concentrate on making one part of the API really really nice so that it won't have to be touched soon. Changes will still be radical in terms of improvement but porting may become an easier task. Even a different approach to release cycle may help... while on one side fast change is a challenge, frequent releases may help to digest and adapt to changes better... Providing plans, sketches in a prominent place so that contrib could know where changes will be focused etc... I don't think it is a good communication strategy and a good development strategy to just say things will break and we won't care. I think it is time to consider the drawback of things breaking... that doesn't mean things won't break, but that at this stage of Drupal life drawback are less negligible than they were used to be and that requires more "management", planning and a different communication strategy. I'm not pushing for a revolution. I'm showing my needs and my feelings. I'm not a leading contributor, I just submit occasional patches and sometimes I help people on the ml. My main contribution has yet to see the light if I survive to the race. I do plan to get as much involved as possible and contribute more. I don't think I'm alone. I think there are other contributors that will find less and less attracting to invest their time in learning Drupal and developing for it if core is not going to take care of these needs and the changing status and target of Drupal project. Again... there is a bit of contradiction in underlining the fact that Drupal main value is in being a framework and breaking the API without taking into account how this will impact on the users of the API. I think that having a longer support period for security is a good idea, even funding this support too. Still my point was on the fact that Drupal code base, community, usage, development etc... is changing and that should require adapting the focus too. The API is getting even more mature, so better... that means that radical changes won't be as needed as before even if there are places where the API needs large improvement etc... People did a lot of experience meanwhile, the community is larger and changes can be discussed and tested more before they are made, so it is harder to make big mistakes or be shortsighted... It should be something that is going to happen naturally, but if you follow nature in a more conscious way, the path will be smoother with more satisfaction for everyone. BTW long ago one of the things that made me chose Drupal over [fill in the blanks] was actually its outstanding security history. I have the feeling that security became even better during last year. -- Ivan Sergio Borgonovo http://www.webthatworks.it

I think I'm missing something here. Because of an issue posted against one of my modules, I was doing XHTML validation and kept getting some errors. The part that had trouble was basically a taxonomy/term output. So I then had it validate a plain taxonomy/term page and it failed. "<ul class="links inline">" is not valid where it occurs. Surely this is not real - it has to be something I'm doing wrong. What might it be? Nancy E. Wichmann, PMP

andrew morton wrote: "Without seeing the exact error I'd guess that you've got a block element inside a non-block element. If this is a core theme open an issue against it." First, I forgot to mention that this is on 5.7. Yes, it is on the Bluemarine theme. And "taxonomy/term" is about as core as you can get. Nancy E. Wichmann, PMP

I opened an issue for whatever it might be worth. http://drupal.org/node/252277 Nancy E. Wichmann, PMP

On Mon, 28 Apr 2008 10:01:04 -0700 Earl Miles <merlin@logrus.com> wrote:

Ivan Sergio Borgonovo wrote:

...

The fact that Views and CCK (that actually are complex modules etc...) still need to be ported, the numbers I cited in the previous email etc... should be a sign that the policy should be adjusted.

No. No. NO. I am really, really tired of hearing this as a

Sorry! Anyway take note of the conditional. Maybe it could sound better if it was phrased as "could be a sign" and anyway consider Views on which I admit to know nothing[1], but that I didn't take into play first, were just part of my argument. [1] that doesn't mean I'm neglecting the value of your work. That just mean I had other priorities other than learning how to use Views. -- Ivan Sergio Borgonovo http://www.webthatworks.it

On Mon, 28 Apr 2008 19:46:09 +0200 "Daniel F. Kudwien" <news@unleashedmind.com> wrote:

...

That doesn't mean core have to stop to be revolutionary on some aspect but that new needs should be taken into account when deciding what to change, how fast and how.

...

...

If you change 3 different parts of the API in one round, porting modules will be a harder task than if you concentrate on making one part of the API really really nice so that it won't have to be touched soon. Changes will still be radical in terms of improvement but porting may become an easier task.

Please correct me if I understood you wrong, but I think you're arguing for backwards compatibility in Drupal's APIs. This has been discussed several times before and the arguments are still valid: Ensuring backwards compatibility would lead to unnecessary overhead in the source code and longer development cycles.

I didn't say ensuring backward compatibility I wrote going beyond the "we won't care phase" to a "we will take it into account". Furthermore the fact that it has been discussed in the past doesn't mean that it can't be discussed now as implicitly Dries seems to suggest: "I feel that preserving the ability to constantly innovate is of higher importance, *at the present time at least*, than preserving backward compatibility." DB API, menu API are good examples. DB API is not mature enough to think it can be left as it is. Drupal is more mature, more diffused, more more... it is changing, also thanks to the previous policy. But well you can't apply the same recipe to new ingredients and the balance between return from fast change and stability is naturally moving towards stability... for many reasons... accompanying the process consciously will make it smoother. That doesn't mean APIs are engraved into stones... it just mean that changes should be managed in a way to take into account the changing status of the project and the needs of the users. Again... big shops may still find manageable those API changes, smaller shops may find it hard... but smaller shops contribute to Drupal too, they are a resource as well... and missing some planning for smoothing API changes will especially damage the one that are developing complex modules that have a long development time. Giving a more guided pressure on contrib may end up in keeping up the good continuous stream of quality modules that require more time to be ported than the 300 lines stuff and gaining market share as well. Actually the support cycle went from 6-12 months to 12-24 months in the last year. We have SimpleTests... that will have an impact on release cycle phases too. It could be an option to have "shorter" release cycles with smaller changes in the API, or there could be a policy to concentrate the efforts on fewer but better API changes so that every single aspect of the API will change less frequently but more radically... etc... Seriously, I'm not here for a religious war and I do see gray shades, not just black or white. -- Ivan Sergio Borgonovo http://www.webthatworks.it

On Mon, 28 Apr 2008 11:57:44 -0700 "Neil Drumm" <drumm@delocalizedham.com> wrote:

On Mon, Apr 28, 2008 at 9:30 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:

...

On Mon, 28 Apr 2008 08:46:03 -0500 Providing plans, sketches in a prominent place so that contrib could know where changes will be focused etc...

This is already happening in the issue queue.

It doesn't work for me. I don't want and I can't get so involved in Drupal core dev. It is over my possibility. There is drupal core, contrib, themers, users... etc... etc... I give great value to all the people contributing to Drupal... especially the ones that spend 20h/week (paid or not), but still Drupal is an eco-system. I may not be suited to this eco-system. Let me at least understand it. If you've to get involved into drupal core development and follow the issue queue to know which API are going to be touched or it will come as a surprise you may expect that it doesn't work for some people that still write code as you may expect that a DBA have different interests, competence, time schedule etc... than a python dev. Nevertheless a good app will require the collaboration of a DBA and a python dev.

...

I don't think it is a good communication strategy and a good development strategy to just say things will break and we won't care.

We do care. Look at how much work goes into any major, or minor, API change before saying we don't care.

Then you've to rephrase one of the documents that is one of the manifest of Drupal.

When 10-20 people participate in writing and reviewing major changes, plenty of diverse perspectives are taken into account. If someone says "this isn't worth the API change" or "we can get an equivalent improvement without the API change," and can back up their argument, then their ideas certainly will be taken seriously.

I'd go a step further. I'd say: should we change this right now or should we wait we've enough resources to change it in a way that we won't have to change it again the next release cycle. I know that Free Software is driven by needs but that doesn't automagically make development rational or avoid clashing needs or avoid the need of compromises. Again... I'd like to point out that even contrib is more mature and there are modules that will require more effort than changing 30 lines to port them and that they support investments and that contrib and core are different and they may need to harmonize targets on a medium term horizon even if they have a common long term horizon. Not every contrib have to be involved in core dev to have a word on it, and the more the contrib part is complex the more the contrib authors won't have time to get involved into core dev, still contrib is growing in value. I'd like to avoid this things pass unnoticed because people don't see crowds of contrib getting involved into core.

I appreciate your contributions, no matter what size, along with everyone else's contributions. I have heard the whole "slow down the API changes" discussion many times before.

But... you're going to hear it again... since the future is not the past and the more the API mature etc... the balance will have to change.

Development is "slowing down." Release cycles used to be 6 months, lately they have been yearly. The introduction of tests in the 7.x cycle will either slow down or improve the quality of changes.

I noticed.

Community self-regulation is working.

OK... I'm part of the self-regulation ;)

...

I think that having a longer support period for security is a good idea, even funding this support too.

Supporting long-term security releases without other bug fixes is a bad idea. I do not want to reject good patches, which people have spent time on, because a release series is unsupported and then go and make a security release anyway.

What's the problem? Provided there are resources (sponsors?) what's wrong with having just security fixes. I'm really dealing with projects that spans several months of pure development. Jumping on a dev release is risky (you need a stable API and you can't afford to fight with bugs) if you're a small shop. The stable release won't last enough.

Before I would consider maintaining 5.x beyond the planned timespan, paid or not, I would need to see a well-thought-out analysis of how it would affect the community as a whole, and agreement from the security team, core branch maintainers, and community. A few people saying they want something, which they are not personally helping with, is simply not sufficient.

Absolutely.

...

It should be something that is going to happen naturally, but if you follow nature in a more conscious way, the path will be smoother with more satisfaction for everyone.

I am honestly not quite sure what you are substantively asking for.

Considering that not all development in drupal is taking place into drupal core and that not all contrib may show up there.

Should we go to our best contributors, who are out there improving the core APIs, and ask them to slow down and think about what they are doing, or rearrange their work schedule? Maybe add some paperwork to the front of any major task? I don't think so. They

Should we go to the contrib crowd that are adding valuable modules and ask them if they prefer to add new features to their work or spend their time porting their modules?

are doing great work. I have not heard major complaints from anyone who has actually used the updated install/update, form, content type, menu, database, or theme APIs. These are all changed for good reasons and the process generally works.

Don't apply what was the past to what may be the future. I admit I may have been naive trying to evaluate the effect of fast moving API just counting contrib *files* for 5.X and 6.X but it may be worth to evaluate the effects, estimate the costs as Victor Kane proposed and do a pool across contrib and weight their response according to popularity and complexity of the modules. I've a reasonably large project I'll have to port from 5 to 6 or 7 depends on when it will be finished... I'll see if things are better than expected but I'm frightened to death.

Should we change our release schedule? We are already making the schedule test-coverage-dependent. Is this change no good? Do you have a better plan?

Did you miss I already pointed out all the things that are already going in that direction?

Should we tell our branch maintainers, security team, and other contributors, to spend more time on older versions? If so, then other things will have to go, probably other Drupal contributions. I had hoped to be updating api.drupal.org this morning, but instead I am writing out a well-thought-out email about my job as branch maintainer. Sorry, now I have to either change my evening plans or everyone has to wait until tomorrow.

Do not think that was not well-though-out and didn't require time that I could use for something else. -- Ivan Sergio Borgonovo http://www.webthatworks.it

On Mon, 28 Apr 2008 14:48:53 -0700 Earl Miles <merlin@logrus.com> wrote:

Ivan Sergio Borgonovo wrote:

...

It doesn't work for me. I don't want and I can't get so involved in Drupal core dev. It is over my possibility.

Drupal is a meritocracy. In general, those who do very much resent being told what to do by those who don't do. If you are firmly in the camp of don't do, that also puts you in the camp of "doesn't get to tell the rest of us what to do."

So you'd say that an engineer doesn't have the right of proper medical care cos he is not a doctor and doctors don't have the right to use cars cos they are not engineers? I'd say that demand and offer of a proper API go together. As much as Drupal becomes more mature the group of people in contrib will diverge from the group of people in core, and I'd consider this good on many sides. I'm not accusing anyone of making Drupal crap cos it is a moving target. This is what is perceived by many... and not just cos the documentation plainly say so. If what you keep on saying is that you can have an impact on core just if you're a core dev... well I'm going to switch to another framework. But we keep on reasoning on hyperbole and it looks it doesn't help. You'd adjust your communication now for what you're planning tomorrow, cos the people deciding if they are willing to invest in a 10K lines module they would like to know what will happen tomorrow. And I don't think anyone is willing to scare off someone that is going to write a 10K line module just because he doesn't get involved in core dev. And anyway it seems that core decisions are made among a 10-20 people. I'd like to know the experience of people behind ubercart or ecommerce, i18n, views, panels... -- Ivan Sergio Borgonovo http://www.webthatworks.it

On Mon, 28 Apr 2008 17:35:35 -0700 "Steven Peck" <sepeck@gmail.com> wrote:

...

And I don't think anyone is willing to scare off someone that is going to write a 10K line module just because he doesn't get involved in core dev. And anyway it seems that core decisions are made among a 10-20 people.

See now, what is this? This is one of those 'what if' emotional blackmail/threat things that are false justifications for arguments. What if someone... was willing to save us if we did as we were told? What if someone... would invest in Drupal if only we gave up 'something' or change 'something else'

This is not a black mail. I already made a 8000+ line investment in Drupal, I hope it will be out of the gates in the coming weeks. There will still be some rough edges since some parts have been highly customized for a specific situations and it may not be ready for public consumption as soon as it is released. I plan to make it publicly available under GPL no later than 1 week from when it will reach production. But considering I wrote it as an investment it should be enough elastic to be made even more general in the parts where due to timing constraint I had to chose a less general path. I still think that it would be a good thing the more Drupal get mature the less contrib modules have to be involved in core. Earls is the author of 2 important modules that actually would take great advantage from core changes. Other modules may prefer "decoupling". I've heard you already made some pool and that the idea of keeping Drupal API so fluid is still welcome. Still this topic resurface regularly. May I say that the 5.X -> 6.X -> 7.0 looks like a rough path at least for me? Larry said that the cost of upgrade is nearly 60% of the cost of building things up and that most of its clients can't afford it. With a 2 years life span and a cost of upgrade of 60% you're going to have a hard time to write modules of thousands lines. Still I'd consider modules of several thousands line valuable for the overall Drupal project. Actually I'd consider such module more valuable because few people take the risk of such a long term investment. Now... isn't it the time to lower that cost just managing upgrades differently? Are you saying that welcome contribution are just the one of smaller modules of few lines that see the light in a week and the one that take place in core? That anyone that has no time to send more than a few patches to core since he is busy to write a 10K line module has no words on core dev life cycle? If we just vote with our direct contribution. Once I'll finish my module I'll vote with my non contribution and switch to something else since if you insist in this wall against wall and calling names, it doesn't look the place where I can make long term investments. Again... I know there are people in core that know how to write code and how to design it. I know there are people that have the right skill to understand software management and planning. Even Dries wrote *at present time*... when did he wrote that? 2 years ago? more than 2 years ago? As a contrib developer and occasional contributor to drupal code I'm expressing my need to lower that percentage and I feel that my need is in line with the reached maturity of Drupal. I don't think it is not in line with natural life cycle of any project getting more mature and I don't think I'm an isolated case. Is Drupal market place the one for 2 years web sites? A sort of RAD for small sites? This market place has its dignity too. Or is it willing to become a RAD for something more complex where you can put a larger investment in. I forecast I'll have a hard time to port my work to 6 or to 7. I may be wrong, but I'm concerned and I'm asking do you think that the coming versions will take into account the cost of upgrades more than now? Is it mature and complex enough that API don't have to be changed twice in a row for the same functionality, so that changes for each releases will impact just few aspect so that can be easier managed during an upgrade cycle? Maybe radical but circumscribed changes so to be more manageable? Is there any interest in lowering that cost percentage so people will see flourish contrib projects that span more than few hundreds lines or are times still not mature enough? I know that lowering the cost of upgrades may have an impact on development speed... but well resources aren't illimitate for any project... it is just a matter of deciding where they give the best ROI. Does it sound not respectful? -- Ivan Sergio Borgonovo http://www.webthatworks.it

I am someone who nearly had a heart attack when I first found out about this tendency to just drop / change stuff in core api. My background is enterprise development so this really did not sit well with me at all and nearly made me back out of our decision to bet the bank on Drupal. But we stuck with it and now, while I fully understand your view Ivan I must disagree. To be clear, my view is a commercial one as the owner of a company who makes money from Drupal via consulting and running our own Drupal sites, not one of a developer or drupal purist! Overtime the vast majority of software "bloats" by its very nature and if you don't allocate time to revisit software on a semi regular basis it becomes a mass of spagetti as a result of "tactical" fix's and changes, which complicates development and slows it down. The real commercial question for me is whether is more efficient to regularly have to go back and revisit code in order to update it or whethers its better to live with a reduced workrate that exacerbates over time for all developers (our own and the community). The answer is simple, commercially its better that developers have to revisit old code on a semi regular basis. As they inevitably improve the way it was written as they have gotten better as developers over time and in a lot of cases their knowledge of drupal has significantly improved. The other massive benefit is that when they revisit it they will see oppurtunities to tie in with new modules. At one point CCK and Views were new modules, a lot of people did a lot of work to make sure when they updated for d5 that their modules played nicely with these and we all benefitted. The end result is that as long as you build your processes around the fact that it can and will change you end up with a more efficient internal development environment. As long as you take a longer term view, there is a net commercial gain as a result of improved software, more rapid adoption of new more advanced methods/modules and more rapid delivery to clients. My 2c. Fin -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jakob Petsovits Sent: 29 April 2008 11:24 To: development@drupal.org Subject: Re: [development] RFC: drupal as a moving target On Tuesday, 29. April 2008, Ivan Sergio Borgonovo wrote:

Is it mature and complex enough that API don't have to be changed twice in a row for the same functionality, so that changes for each releases will impact just few aspect so that can be easier managed during an upgrade cycle?

Ivan, I feel your pain, I'm having a hard time with porting my modules in time as well (in addition to "new features" work). The problem does exist. However, what I miss from your mails is a constructive proposal how to make it better. Even now, the APIs are not changed for the fun of it but always come with a significant improvement. You request that the core devs take care not to change stuff *without a good reason*, but that's what they do already. So the question is if you want to have the APIs freezed even if there would be a good reason to change them, and *that* is what the policy applies to. Do you want to have some of those APIs freezed as well? Possible answers: "No, because they do indeed make Drupal better, even if it causes more effort on upgrading." In that case, we're at the status quo, and the discussion is over. "Yes, because the cost of upgrading is more important than the cleanest possible Drupal core." In that case, you disagree with the community (including me), and we expect you to make concrete proposals which type of API changes should be frozen under which exact circumstances, and present compelling arguments why that is better than the status quo. You argued that Drupal is becoming stable and mature enough to freeze some aspects of the API. If that is the case, I believe that no more API changes will be written up for these areas, and the problem will be solving itself in time. However, I believe that Drupal has still years to go until it reaches that state of maturity, and that each API change causes more good than harm in the end. If you believe that some of the changes from Drupal 5 to 6 caused more harm (in terms of slowing the upgrade process) than good (in terms of consistency, long-time maintainability and important features), then by all means, "show us the code". Which changes would better have been left out in your opinion? I'm keen on seeing examples from you, because the process can only be changed if we recognize what actually went wrong. If you can't find good examples, then this whole discussion is moot because there's nothing to complain about. Regards, Jakob

Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:

I appreciate Ernie suggestion about wrappers around the API... that's just one more way to put the weight in the equation. Could it be a transition solution? What is the cost in term of performances? etc...

That would depend on the PHP and MySql versions. I notice little to no performance hit because I wrap the Drupal API into my own API with PHP 5 and MySql 5.0.21. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

On Tue, 29 Apr 2008 14:40:47 +0200, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:

On Tue, 29 Apr 2008 12:24:00 +0200 Jakob Petsovits <jpetso@gmx.at> wrote:

...

Ivan, I feel your pain, I'm having a hard time with porting my modules in time as well (in addition to "new features" work). The problem does exist.

However, what I miss from your mails is a constructive proposal how to make it better. Even now, the APIs are not changed for the fun of it but always come with a significant improvement. You request that the core devs take care not to change stuff *without a good reason*, but that's what they do already.

It depends on the weights you put in the equation.

...

In that case, you disagree with the community (including me), and we expect you to make concrete proposals which type of API changes should be frozen under which exact circumstances, and present compelling arguments why that is better than the status quo.

I think the DB API is a good example. Beware I'm not criticizing the current work. I love it. Maybe when D6 DB API was planned that was the best thing to do. Now we will see another change of DB API. D7 DB API does really look as a good candidate to be frizzed for at least 2 releases if not more if all the efforts needed will be put into getting it right. Should this change be accompanied by another FAPI change? Should the DB and FAPI change be accompanied by cosmetic changes to other 10 helper functions? I think that shouldn't happen for D8.

What D6 database changes? I can think of only 2 off hand; the utility function for doing WHERE IN clauses safely (which is backward-compatible) and the removal of db_num_rows(), which doesn't work across all databases, which is why it was removed. The current database work is the first major overhaul of the database layer since I've been involved in Drupal (a little over 2.5 years now). And yes, I am hoping that it is the last major overhaul for several more years; if we have to completely overhaul the API level again, it means I screwed up somewhere. :-( The D6 menu API was the first time the menu API had any serious changes in that period, too. We're just now discussing changing the Filter system for the first time since, uh, 4.5? Earlier? The node system has changed fairly little overall, which is part of the problem with it. The D6 FAPI is, at the API level, not a total rewrite, just a cleanup with a few extra features. Taxonomy hasn't really changed since... 2003? :-) Comments, do those *ever* change? The user system is so old and unchanged it's scary. It's not like Drupal is an entirely new CMS every version. Some of the APIs there are quite old and stable, perhaps too old and stable in many cases. As Earl noted, what's holding up contrib for D6 isn't massive changes to core. It's that a half-dozen key contrib modules all decided to do major architectural redesigns at the same time as their D6 upgrade when they were changing APIs anyway. (Views, Panels, CCK, ImageAPI/ImageCache/ImageField, etc.) That's the hold up, not core, and that's not something that core development can even really control, even if it wanted to.

I already put my time and money on seeing this happen. And I took the risk on developing a quite complex module on Drupal. It will be hard to afford an upgrade once at the current state of affairs, it will be unmanageable to sustain a second upgrade at the current estimated cost. I'll survive back-porting sec patches to 5 so that the cost will be spread over a longer period. I rely on very few contrib modules so that will be feasible. But meanwhile I think my project will continue to grow... once it will reach 20K lines of code it will be of comparable size to Drupal...

Perhaps this is a bit controversial to say, but I'll say it anyway. If you're writing contrib modules that reach 20K lines of code, then either: 1) You need to refactor it into a suite of modules that are easier to manage and upgrade, which would be better code anyway. 2) You need to stop and just piece together existing modules in a smart way instead of rewriting several wheels. 3) You are Earl Miles and you're writing Panels 3. So unless you're Earl Miles, a 20K module is a sign that you're doing something wrong in the first place. --Larry Garfield

On Tue, 29 Apr 2008 18:32:19 +0200 Gerhard Killesreiter <gerhard@killesreiter.de> wrote:

Maybe we could introduce a code of conduct for contrib authors to not do major overhauls when a new version is due. Ie if I maintain a module for D6 and D7 comes out, I port it straight away to a D7-1 version and then start a rewrite as D7-2.

The PostgreSQL Project actually has guidelines as to what can be considered contrib. So this isn't unheard of. An example of this might be: Anyone can create a Drupal community project, but if you want to be an "Official Drupal module" your module must meet certain standards. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

If anything this suggests another approach: if Views and/or CCK don't get as much into core as we'd like for D7, then perhaps we should consider either of them not being ported to D7 a release critical bug for D7 core too, and not release without them.

On Tue, Apr 29, 2008 at 3:09 PM, Earl Cooley III <shiva@io.com> wrote:

catch wrote:

...

If anything this suggests another approach: if Views and/or CCK don't get as much into core as we'd like for D7, then perhaps we should consider either of them not being ported to D7 a release critical bug for D7 core too, and not release without them.

Based on downloads, it should be possible to select a list of the most popular contributed modules for which this would be a good thing.

-- Earl Cooley III (shiva@io.com) The "Other" Earl

Yes, we used to have this issue where contributed module maintainers could be bothered to track core development so complained about no/little notice for a window to update their modules. So a public alpha and beta period of several weeks was initiated in the hopes that the contributed module maintainers would port their modules during this time frame. Core is core. There is no 'gold repository' for contributed modules. (Yet another repeated variation on this debate) The specific issues this cycle with Views and CCK were already discussed and making rules for what may be a one time thing seems silly when Drupal 7 isn't even in freeze. Code freeze for Drupal 7 would be the time to reconsider but honestly, the best thing to do is use this time to get that desired functionality into core. Code sooner then later. Steven Peck -sepeck http://www.blkmtn.org http://drupal.org/project/Modules Quote: Contributed (contrib) modules are plugins for Drupal that extend, build or enhance Drupal core functionality. Use matching versions (modules released for Drupal 5.x will not work for Drupal 6.x). Contributed modules are not part of Drupal core releases and may or may not have optimized code/functionality. If a module solves your needs please consider joining forces and helping the maintainer.

I had my tongue slightly in my cheek while typing that, but still. The intent behind that specific point was that I'd like to see golden contrib (which exists in practice whether or not we call it that or have any visible sign of it on Drupal.org) get a lot more issue queue attention than it currently does. More testing and reviewing (and submitting) of patches, more people tracking the lists to put down bogus/duplicate bug reports and answer support requests, etc. etc. I have no illusions about this happening immediately - there's a shortage of core patch reviews as it is, but it's happened a bit with Views/CCK/Panels/Imagefield/Imagecache and there's a lot of potential there for it to continue and develop. If there was a general feeling (not a new rule) that we can't do a full release without x and y modules, then some of the help that's ready to be welcomed with open arms might be more forthcoming. Additionally, the process of porting these modules uncovers core bugs (or more often unforeseen deficiencies which are harder to test for) every so often, and that would be happening during beta rather than after .0 I don't have particularly strong views on this (except that it's worth discussing), but, in the back of my mind there's a longer term idea for somehow having HEAD ports of a few modules maintained, fully simpletested, alongside core, so we can see exactly what breaks and how during the release cycle as patches land (this long term idea stolen almost verbatim and without permission from Douglas Hubler at the testing BOF). We have this to an extent with Poll and Profile etc., but without simpletests it's been easy for them to stay broken for quite a long time without anyone noticing - not to mention they're not going to be exposing the same deficiences.

Steven Peck wrote:

the best thing to do is use this time to get that desired functionality into core.

Well in this case the people best placed to do that are busy porting those same modules to Drupal 6. I have high hopes for a longer code thaw, am alpha/beta testing CCK and views ports, and will one of the first in line to review any core patches that arrive in the queue, but for example, I can see Panels and Nodequeue becoming as central to many sites and dependent contrib modules in D6, as CCK and Views became in 5.x, so this is really more of a general argument than about CCK and Views specifically (and sorry to pick on Earl's modules but it's his own fault for coming up with them).

On Tue, Apr 29, 2008 at 9:32 AM, Simon Hobbs <simon@emspace.com.au> wrote:

We really need a D5 appreciation club for those who /choose/ not to upgrade. When I reach Level 9 in http://kingdomofloathing.com I am going to start that very clan.

sime

I already started it! So count me in! See my blog post: "And now for something completely different: Drupal - the quiet revolution" http://awebfactory.com.ar/node/296 In all seriousness, I think a couple of things are becoming very clear in this very illuminating and interesting thread (some very courageous people, although there is a lot of negation and euphoria going on): 1. Without Drupal "users" Drupal would not be the success it is today. They are working hard every day for a living, making sites for people. 2. Without Drupal "core coders" Drupal would not be the success it is today. They are working very hard every day making Drupal 7. 3. These two groups need to listen to each other closely, and plan, and keep the synergy going the best they can. It's all good, given the general crisis going on all around. 4. My own opinion in terms of recommendations for users: Drupal has a very long development cycle, similar to Debian, if you can see beyond the hype (necessary hype in order to compete, to posture so as to try to avoid the fallout from the world crisis, I guess, but hype nonetheless: widgets, anyone?). The truth of the matter is: Drupal 5.x was a big milestone. Drupal 7 will be the next one. So, use 5.x for production, then plan for a major upgrade to Drupal 7 in about a year. Drupal 6.x will be a very rocky road (very necessary for this to happen, some important refactoring going on, module updates might not play nice with production data, core and module updates might not play nice at all with use of core and contrib API's, nor should they: this is an experimental version) a rocky road towards the stable and "real MacCoy" version Drupal 7: as someone said, the Drupal "LTS" release. The main trouble we have for Drupal 5.x a year from now will be security releases, and the backwardness of jQuery update, which correctly assumed Drupal 6 would take care of business, but in light of things, that may need an evaluation: we should work together to get both of these things done. And remember, a year from now, Drupal 7 will almost be ready, and will not take so long to become stable, since the cck and views rewrites are going on now, it will just be a matter of porting. 5. A word to "core developers": I applaud the tremendous courage to do a complete rewrite on cck and views, which will both fit in in spectacular fashion with panels 2 and nodequeue and services and media mover and... the list goes on..... to make an absolutely blockbuster CMS and web application framework. It is well worth waiting a year for. I only wish I had more time to help directly, but my destiny right now is to use Drupal and help others who are using Drupal. That is also a form of testing. And we will be testing all of this like crazy, us parasitical working stiffs who actually use Drupal to make a living, we will be testing this like crazy as we prepare our upgrades from 5.x - {6.x} - 7.x The only real question of concern is whether all of this effort can survive the current world crisis, but even I have to admit that is off topic. But it is on topic when a lot of assumptions are made about ascending curves. 7. And we must all take into account, that Drupal 8-9 will have to go through another serious refactoring to stay alive, to take care of the code debt which is accumulating all the while and only partially offset by the stable, great and beautiful Drupal 7. But by then all of us will be more mature :) I think that if we look at it this way, then the picture starts to fit together and we can stop feeling so frustrated with each other! Practically everyone on this discussion thread has contributed awesomely to piece together a clearer picture. This is not a repetition of previous new release cycles at all. Victor Kane http://awebfactory.com.ar

On Tue, 29 Apr 2008 09:38:13 -0700 "Steven Peck" <sepeck@gmail.com> wrote:

...

This is not a black mail. I already made a 8000+ line investment in Drupal, I hope it will be out of the gates in the coming weeks.

Sure it is. You brought it up as an example with the implied I will take my toys and go home and that people would blink. I realize you

As much as "we are the doers" you're not.

Not really. If you are not involved, then you don't get a vote or influence. Really. There are times in the 4.7 -> 5.x cycle and also the 5.x -> 6.x where I did not have time to pay attention to the issue queue and as a result core module behavior and/or other decisions were made that I did not like/agree with. That's all right, they worked out but because I did not have time to be involved, I did not get to vote in those cases. People did not stop and send me an email to solicit my opinion on things, they discussed and arrived at a solution.

I understand the problem and I'm aware of the time it takes to take the responsibility to listen everyone even if they are busy doing something else. That's why I posted an email asking what is and what I should expect it will be the "policy" on cost of upgrades.

It doesn't take that much work to pay attention to the issue tracker and trends. It doesn't take that much time to occasionally pull something down and test it. And that time you spend is so infinitely valuable and results in some seriously important dividends. It gets another set of eyes on code/changes. It gets

It takes time to learn. At this moment it was faster to ask rather than getting involved at the level I'd like and you're saying.

The cost is time. And we return to; "Open Source doesn't cost less, it costs different."

Once you put everything in the bill, it costs less.

...

If we just vote with our direct contribution. Once I'll finish my module I'll vote with my non contribution and switch to something else since if you insist in this wall against wall and calling names, it doesn't look the place where I can make long term investments.

See now we return to 'take my toys elsewhere subtext'. If you decide to work/contribute to a different project then that's what you decide to do. It would be unfortunate, but it's also a natural life cycle behavior thing too.

Exactly. That's why I was asking. I paint future scenario. I could be wrong... but still I've to make forecasts.

And excuse you? I do not believe I called you names in any of the emails I sent and am seriously annoyed at your implication that I did so.

I was not referring particularly to you.

How is it still not relevant or true today? Drupal is more that seven years old and still following it's founding principals and mission. As it has gained in complexity it has slowed down in releases but that is a sign of it's maturity and the larger number and nature of contributors. There are also a lot of new and

Well, as I said things are following a natural path.

relevant technologies still out there that people are wanting to integrate into Drupal. The web is not yet mature.

Yep but you don't rely on a feature or technology that's not there already.

...

As a contrib developer and occasional contributor to drupal code I'm expressing my need to lower that percentage and I feel that my need is in line with the reached maturity of Drupal. I don't think it is not in line with natural life cycle of any project getting more mature and I don't think I'm an isolated case.

It is slowing down, just doesn't seem to be slow enough to address your concerns.

If there will be some interests on providing extended security support at least as a test... I've some hopes that things will calm enough once D8 will be out. Larry wrote: «"Looking hard" is a lot of work, both technical and manpower. That's the point I was making. We can reduce the amount of work with some careful planning, technological solutions, and/or money.» I was wondering when it will be the time of "careful planning"... BTW I still haven't reached the 20K lines mark. I'm around 8000+ and the overall stuff is split in 3 "core" modules and some plug-in modules, but there are dependencies that are there and can't disappear by magic. So I won't be able to port A, B and C but not D and see everything work. It seems I won't be touched by the new D6 DB API... I'm just going to ignore the changes, I'll ignore D7 API cos I won't be ready and I'll enjoy D8 API that may take something that may make all that code more DB agnostic. Still if Larry estimates a 60% costs on upgrade how can he sustain that the change in the API was negligible? Where do you see the costs in upgrading? -- Ivan Sergio Borgonovo http://www.webthatworks.it

Ivan Sergio Borgonovo wrote:

On Mon, 28 Apr 2008 14:48:53 -0700 Earl Miles <merlin@logrus.com> wrote:

...

Ivan Sergio Borgonovo wrote:

...

It doesn't work for me. I don't want and I can't get so involved in Drupal core dev. It is over my possibility.

...

Drupal is a meritocracy. In general, those who do very much resent being told what to do by those who don't do. If you are firmly in the camp of don't do, that also puts you in the camp of "doesn't get to tell the rest of us what to do."

So you'd say that an engineer doesn't have the right of proper medical care cos he is not a doctor and doctors don't have the right to use cars cos they are not engineers?

I would say that there's nothing even remotely similar in either of those situations. 1) doctors and engineers are selling their services, 2) doctors are in a path that deals with people's lives, 3) so are engineers, 4) both are under many government regulations. In fact, if your doctor believes there is nothing wrong with your appendix, and you ask for your appendix to be taken out, I'm pretty sure the answer will be "No," and after awhile it will be "Get out of my office."

And I don't think anyone is willing to scare off someone that is going to write a 10K line module just because he doesn't get involved in core dev. And anyway it seems that core decisions are made among a 10-20 people.

Sure, you're going to write a 10,000 line module but your inability to keep track of core ensures that this is going to be 10,000 lines of code that will have a high likelihood of not working. See next comment:

I'd like to know the experience of people behind ubercart or ecommerce, i18n, views, panels...

As the author of 2 of the 5 modules you named (convenient, that), let me tell you my experience: If core is broken in some way that directly impacts my modules, I fix it. When it turns out that core's theming isn't quite up to the task of handling something as dynamic as Views, I wrote a new theming layer. I submit patches and if they affect Views, I put in the patch "This affects Views" and I find that my patches get rather a lot of attention. Because, you see, it turns out the core maintainers care about Views, which is funny because most of the core maintainers don't even use it. But they are aware that most of Drupal's users do. My experience porting Views from 4.6 to 4.7 was pretty rough, but the result of the port was that I had a better product. I didn't have to port Views from 4.7 to 5; I had users that really wanted it, and so a group of people put together a patch for me, and Drupal 5 had a working Views in pretty short order. I did not port Views from 5 to 6, because I wanted to rewrite it. After 3 major core versions and several years of Views in the field, some of the early design decisions I made were being really constrictive. I've spent a good 5 months of my life working full time on Views 2, and IMO it's an absolutely amazing module. It's going to make Drupal better, and the fact that it has singlehandedly made most of the Drupal community wait for Drupal 6 is a small price to pay for the amount of goodness that the community is going to get. And Views is one of those modules that has a ripple effect. If you really follow contrib, you'll find that most of the really important modules have some tie in to Views; even if it's a simple handing off of data to Views, but others -- CCK comes to mind -- rely on Views to be truly fully functional. So Views' delays have caused contrib to come to a standstill. Now that Views 2 is in beta, I think that's all about to change. Would I like the people working on core to spend a little more time on 6? Heck yea. Am I going to try and demand they do that? Heck...well, ok, I actually have a little bit. [Note: it's only been minorly effective]. On the other hand, and this gets back to my original point, I can get away with this. Why? Drupal is a meritocracy. I have contributed. I continue to contribute. In a meritocracy, it's very important to keep the contributors happy. If the contributors are unhappy, they won't contribute. Drupal, as an open source project, lives and dies on the contributions of its users. That is the true price of open source software. And right now, the contributors of Drupal feel that we have a model that works. And to be fair, I believe that some of the things you're asking for are going to come to pass, but I don't think they'll happen because of these conversations on the development list. I think they'll happen because the people contributing are going to have their needs shifting, and as the needs shift, the nature of their contributions will shift. But always remember, when you tell the Drupal community that it, or the people in it, should do something, you're telling people who volunteer their time, their code, their documentation, their marketing efforts, or just their time offering support to other users. These people are giving up a lot. For free. Of *course* they don't take kindly to demands.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Earl Miles schrieb:

Ivan Sergio Borgonovo wrote:

...

It doesn't work for me. I don't want and I can't get so involved in Drupal core dev. It is over my possibility.

Drupal is a meritocracy. In general, those who do very much resent being told what to do by those who don't do. If you are firmly in the camp of don't do, that also puts you in the camp of "doesn't get to tell the rest of us what to do."

Nicely said. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIFmxhfg6TFvELooQRAq1wAKC/5T2Scs2ROpI3kTN9Ki2FPwNFdQCgt+yH tvKs8jqyl3aRAyYtyu82ZzI= =k9hz -----END PGP SIGNATURE-----

On Monday 28 April 2008, Neil Drumm wrote:

Before I would consider maintaining 5.x beyond the planned timespan, paid or not, I would need to see a well-thought-out analysis of how it would affect the community as a whole, and agreement from the security team, core branch maintainers, and community. A few people saying they want something, which they are not personally helping with, is simply not sufficient.

I'm going to ignore most of the debate on this thread as off-topic (I am not saying the quoted portion above is, as I think it's quite on-topic), but will offer the following perspectives: <consultant hat> Most of the clients we work with don't have the budget for a 1- or 2-year upgrade cycle. We estimate that a port of a medium to large site from one version to the next costs about 60% of the cost of the original build. (We haven't done many, though, so I welcome input from other consulting shops on what their average costs for an upgrade are.) That's out of the budget of many of the clients we work with, who are not-for-profits of one form or another. For that reason, we recommend that they skip versions, but that still leaves them with, as someone else pointed out, a period of unsupportedness. For most of my clients, a 3-year cycle is within budget. Frequently after 3 years they need to revamp the site anyway, which means we'd do a site rebuild on the latest version. Given a roughly 1 year dev cycle, that would mean supporting 2 versions back instead of just one. As Niel, Moshe, and others pointed out, though, there is a non-trivial cost to that. There are a couple of things we can do to help make that feasible: 1) Fund a security team or security team lead. This could be through the DA, or some angel company, or some other mechanism I can't think of at the moment. 2) More automated testing will, hopefully, reduce the number of bugs and security holes we have in the first place, which should make long-term maintenance easier. Read: If you want longer-term stable support, go help with testing! 3) During GHOP one of the tasks I proposed was a review of penetration testing tools, which resulted in a very extensive writeup that is, I believe, still sitting in the issue queue. Penetration testing is the security equivalent of unit testing; automate trying to break a program to find holes sooner rather than later. Like unit testing, it can have immense long-term savings both in time and in break-in costs. I don't know if the security team has done anything with that yet (I am not on the security team), but if we can make penetration testing part of our routine that should reduce the long-term cost of maintenance. Security team folks, has anything happened with that, and if not, is there anything the rest of us can do to help? 4) Tracking contrib is a decidedly non-small task, and one that gets larger by about 4 modules a day, I estimate. Perhaps we could pair that down, thanks to more recent developments in project management? For instance, state that the sec team will only track contribs that have a published release node for a given version, so a contrib owner can deprecate his own module for D5 before D5 itself is, at which point the security team does as well? Or go a step further and only track modules that have a proper stable release node? (One more reason to not use modules that don't have stable releases.) Would that make life easier, or introduce too much of a security hole? All of the above possibilities come down to "make long-term maintenance easier so we can have more long-term maintenance" (or at least less strain on our long-term maintainers, and I freely admit that I am not a role model in that regard). So if we want longer-term maintenance, which I think is a good thing, we need to make long-term maintenance easier. Let's do that. </consultant hat> <developer hat> Ivan does raise a valid point about Drupal's stance on OOP. Much of it is based on "PHP 4 OOP sucks anway", which as of D7 is no longer a consideration. Perhaps we do need to update that document to reflect 3-4 years of further development and the introduction of PHP 5? (Not to say "yay, OOP!" but to at least be less negative about OOP in general.) </developer hat> <community hat> I am going to borrow the spotlight for a moment to say a huge thank you to all of those people who do spend inordinate amounts of time not just writing but maintaining huge tracts of code; leading module maintainers, release managers, the security team, etc. Without them, Drupal would be so much pile of useless, buggy code. Guys (and gals!), you rock! </community hat> -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Tuesday 29 April 2008, Joshua D. Drake wrote:

Larry Garfield wrote:

...

On Monday 28 April 2008, Neil Drumm wrote:

I believe the solution to this problem is to look at mature open source projects and how they handle their development model.

PostgreSQL Apache Debian FreeBSD

These are long standing, mature, well maintained and respected open source projects.

Everyone of them has a long support cycle.

Drupal is indeed a quickly moving target, frankly because of its immaturity. I think that the community may want to take a long hard look at version 7 being a real LTS release.

Sincerely,

Joshua D. Drake

"Looking hard" is a lot of work, both technical and manpower. That's the point I was making. We can reduce the amount of work with some careful planning, technological solutions, and/or money. Thank you for volunteering to provide those! :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Mon, 28 Apr 2008 22:17:03 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote:

I believe the solution to this problem is to look at mature open source projects and how they handle their development model.

Could it be a starting to have a release cycle where functions in spite of disappearing are marked "deprecated" and disappear in a later release? I know this will make harder to support security patches but at least it should not make the release work harder. Maybe even marking functions as "volatile" as a sign there is a plan to change them will give a chance to dev to mark places that may change in the coming release and modify them easier. I'd say that marking them as "volatile" even if it is just a clue of what's planned and may not happen in a future release would be very helpful. -- Ivan Sergio Borgonovo http://www.webthatworks.it

Could it be a starting to have a release cycle where functions in spite of disappearing are marked "deprecated" and disappear in a later release?

I have not entered this thread, but enough is enough. An API is not a heap of functions. It's database storage, in memory data storage and operations defined over them. Can you imagine the amount of code that would be required to create the $_menu data structure available in Drupal 4.5-5 to make the menu system backwards compatible? No, you can't because you are not participating in anything going forward, just blustering on this list on and on, draining precious development resources and not adding anything. Prove me wrong! Review patches and then you will see that we are not breaking backwards compatibility because we want to hurt someone or some group. Instead, we are working day and night, relentless to make Drupal better and then all people can bleat is "but, but backwards compatibility".

Quoting Karoly Negyesi <karoly@negyesi.net>:

...

Could it be a starting to have a release cycle where functions in spite of disappearing are marked "deprecated" and disappear in a later release?

I have not entered this thread, but enough is enough.

I agree, enough is enough.

An API is not a heap of functions. It's database storage, in memory data storage and operations defined over them. Can you imagine the amount of code that would be required to create the $_menu data structure available in Drupal 4.5-5 to make the menu system backwards compatible? No, you can't because you are not participating in anything going forward, just blustering on this list on and on, draining precious development resources and not adding anything. Prove me wrong! Review patches and then you will see that we are not breaking backwards compatibility because we want to hurt someone or some group. Instead, we are working day and night, relentless to make Drupal better and then all people can bleat is "but, but backwards compatibility".

Backwards support is the responsibility of the Drupal core user (and I mean those who develop using core). <?php $version = split('.', VERSION); switch ($version[0]) { case '6': do_version_6_things(); break; case '5': do_version_5_things(); break; case '4': switch ($version[1]) { case '7': do_version_4_7_things(); break; case '6': do_version_4_6_things(); break; } break; } ?> I don't know that I would want to use your contribution but if you care about backwards support; that support is your responsibility. It is true for a major portion of the information industry. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

On Mon, Apr 28, 2008 at 9:30 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:

Here discussion spend a lot of time on the Docs problem

http://drupal.org/node/132496 but the more the project is mature the less simple modules you'll find cos the API is better the more you'll see thousands lines modules developed. -- Ivan Sergio Borgonovo http://www.webthatworks.it

Actually that thread spent a lot of time complaining with multiple people claiming that they were owed and refusing to participate. Also it was pretty much a non-issue. It is also a fundamental mis-understanding of Drupal historically and of open source in general. The code has been consistently self documented and there have been major drives to improve and backfill gaps in the last two years. The database schema is now fully documented with a mechanism to maintain this documentation going forward. Change is driven by the active development community. It is the only way it happens. This is not new. This is how it works. In order to 'slow' everyone down you'd have to stop everyone contributing. People contribute for a variety of reasons. 1. It's an interesting puzzle. 2. The present way bothers them and there is a better mouse trap 3. The present way needs improvement for real world solutions 4. It serves someone's needs 5. Build karma 6. Learn something neat 7. It feels good to participate in a community and help people Note, nowhere is 'sell this product'. There are other open source products with a commercial model. Many of them are successful, some started out with this commercial model in mind. These commercial types of open source products also serve to confuse people. Drupal is Open Source. It is also over seven years old. Over because it was released in 2001 as version 1 but had a community around it before then. Historically, you don't sell Drupal per se. You sell your ability to solve your (customers) needs and that happens that the best vehicle is Drupal. Historically the list and forums are littered with posts just like your email. People think it's time to 'slow down' for 'some various reasons of their own' without understanding the actual volume and workload involved because it's largely invisible to them. To clarify some things, I wrote many of those 'policies'. I wrote them because the question kept coming up and I was tired of answering it. I didn't determine policy, I solicited feedback from many people on early versions of the document (years ago) and clarified what the community custom was among the developers. A lot of this is what was actually happening at the time and what was a 'reasonable' expectation would be. People were complaining that "they didn't know". So, now it is documented. People do not have the excuse that "they didn't know". It was determined that this was reasonable based on the burden on various volunteers willingness to do this. I frankly don't see what has changed except that it's time for someone to try and slow the project down to conform to their needs again. Historical hallmarks of Drupal 1. Does not have an expectation of code backwards compatibility, just data preservation. 2. Rapid release (note, this has actually slowed down over the years which you can validate through the Change logs) which is a more natural method to achieve this goal then some random artificial one. 3. This very discussion gets raised every 6 - 9 months 4. Things go on as before. With each release Drupal will always be 'more mature'. There will hopefully not be a point in the next few years were it won't be that way. But we cannot predict which web technologies will be on the rise in the next year. Which technologies, capabilities will be coming to the fore that we want to provide core api's for? Will it be the next taxonomy, javascript, open id?

Giving a more guided pressure on contrib may end up in keeping up the good continuous stream of quality modules that require more time to be ported than the 300 lines stuff and gaining market share as well.

Let's manage change to make a few people have significantly more work (and burn them out and overwhelm them more) to 'control' contrib is not a solution. In my opinion, the vast overwhelming benefits that mostly free range contrib is sign of a very healthy eco-system. Yes, it can be confusing and overwhelming and that is unfortunate but it is also a wealth of diverse ideas and solutions and many of them survive and build little mini-communities around them that is also healthy. --------------- Now, this next bit is my little personal philosophy. --------------- Drupal is _not_ a company. It is not a business. It is a community that produces code. It was not started as a business and I was not attracted to it because it was a business. It does have businesses that surround and support it but they evolved to leverage and take advantage of it. Drupal did not arise out of a desire to make a company money. As an amorphous entity it is not about gaining market share. It is a community that is passionate about building relevant tools that help them solve their needs on the Internet. It is about improving that code and experience for themselves and each other. Being able to solve your needs and leverage others skills who have solved their needs in a way that unexpectedly benefits you. So the only way to know and understand Drupal is to be involved. Be involved in code contributions, reviews, documentation, support help. This gets you familiar with the code, the current methodologies and best practices that have evolved. The trends and directions. It gets you a seat at the community cafeteria tables. You can change tables, focus on something else, pull tables together. But you have to be involved to understand things. this is not about being a 'big shop', this is not about being a business. If Drupal becomes about being a 'business', I will take my chair and go home. I don't do this to support your needs, I do this to support mine. That I do it with the community in a way that others also benefit is good because I learn from other people sharing solutions to their needs and that can bring even more people and diverse talents and skills in. But ultimately, we all do it because it solves our own needs. I don't care about _your_ immense costs and you do not give me any reason to care either. That is another non-argument raised before yet we continue to speed adoption. Open Source does _not_ cost less, it costs different. If you do not prepare your client/customer/company for that reality, then you are doing your client/customer/company a dis-service. This is also _not_ any different then most/many commercial products that you pay licensing costs for. Your costs aren't giving me money to pay my bills and frankly, I have managed to upgrade my 10 sites and support several friends on theirs fairly consistently by myself for several years now. They aren't fancy but they are mine. They solve my needs. And they solve my friends needs. If a business looking to use Drupal can't live with that, then they probably should use something else. Steven Peck -sepeck http://drupal.org/mission http://drupal.org/principles http://drupal.org/best-practices ---- Plan for the future. You should revisit and reevaluate your site each time there is a major version release of Drupal. This does not mean you have to upgrade it, but you should evaluate and plan for an upgrade approximately each 12-24 months.