[development] RFC: drupal as a moving target

[Ivan Sergio Borgonovo]

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

> On Mon, Apr 28, 2008 at 6:29 AM, Ivan Sergio Borgonovo
> <mail at 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