Karoly Negyesi wrote:
On Mon, Apr 20, 2009 at 7:06 AM, Bryan Ollendyke <bto108@psu.edu> wrote:
I had concerns and I shared that with the community. I had no solutions. I stil do not have. I am not sure postponing Drupal 7 even further is the solution. I agree that bottlenecks in the reviewing and applying of patches is a huge problem majorly holding up Drupal development. I suspect we need some significant structural changes to address it.
Partly I think we need to look at changes in the drivers of Drupal development. There was a time when it was mainly hobbyists, who weren't particularly tied to external timelines. No longer. The biggest amount of focused development time now comes from medium to large companies needing specific functionality within set timelines. The typical development cycle for a large project (e.g., a major site or multisite installation) is a matter of months. Development can't wait the many months or even years before a new version is ready and can't deal with the uncertainty of fluxuating timelines. So the significant work they sponsor is almost never for core, which is years ahead of what can be used. It's instead for the current usable release version. Meanwhile, with fewer resources, core goes its different direction, choosing its own solutions to many of the same problems. And so the contrib-core gap increases. Even when a corporate-sponsored project is specifically designed to contribute to core, the results can be mixed at best. Take the internationalization work CivicActions did, sponsored by Sony Music, see http://drupal.org/node/383954. We worked just as hard or harder on numerous core fixes and enhancements as we did on work in contrib. But at the end of the six or seven months, when pretty much every significant patch had been accepted and applied in dozens of contrib modules (Views, CCK, Flag, Voting API, Internationalization, Date, etc.), practically none of our core patches had got in. I conclude: 1. More than tweaks and further exhortations to just do more reviewing, we probably need to consider some major changes. 2. Any changes should increase the ease and incentive of contributing major improvements to core as part of the regular development work. Here are some concrete ideas: 1. Expand our team of core committers. Since 4.7 we have had a single maintainer per major version in addition to the permanent core committers (now reduced to one). We could consider changing this. Possible changes: a. Each core committer either becomes a permanent core committer or is maintained for two or three versions instead of one. E.g., while Angie is the primary maintainer of 7.x, some or all of Gerhard, Neil and Gabor retain the ability to accept and apply patches for HEAD. b. Two or three core committers are appointed per major release instead of just one. c. The maintainers listed at http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co are given permanent commit access to be used only in the areas they are responsible for. 2. Shorten our release cycle. Instead of trying to fit many major API changes and improvements into each major release, we instead limit ourselves to a focused few changes and a much shorter timeline. This quickens the pace of change, reducing the contrib-core gap. 3. Rather than always limiting new functionality to the new version, we accept specific, break-nothing backports in core of new functionality and APIs. E.g., we have two branches of each major version, one a feature-frozen branch (what we have now) and the other one (yes, somewhat less stable) that accepts selected new APIs and features that have been added already to HEAD. This allows contrib modules to use the new APIs in the current version. I know that all of these potential changes - and others that I hope others will come up with - would have potential pitfalls and disasters. But I think these are the sorts of discussions we should be having. We've recognized a long-standing issue. We need some creative thinking, drawing on our strengths, to consider afresh how to keep core development accessible, rewarding, and effective. Nedjo