[development] RFC: drupal as a moving target

[Neil Drumm]

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.

>  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.

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 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.

I am the 5.x branch maintainer. At the height of development, I spent
approximately 20 hours per week, sometimes more, reviewing patches,
while putting patches I wanted to write on hold, keeping a day-job
building Drupal sites, and sometimes skipping social things.

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.

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.
Community self-regulation is working.

>  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.

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.

>  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.

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 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.

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?

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.

-- 
Neil Drumm
http://delocalizedham.com