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