[development] RFC: drupal as a moving target

[Ivan Sergio Borgonovo]

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

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