On Tuesday 21 April 2009, Alex Barth wrote:
No insults, but we don't really want to start wild forks of core modules with arbitrary maintainers and features in contrib. If we just do that, the quality of those forks won't differ from any other contrib module, and I would not see nor understand why those forks can't use a different module namespace (like any other module that thinks it can do better).
I'd call it a backport. The same namespace makes it much easier to maintain the backport. The incentive for keeping the backport up to Drupal core standard is that its very reason-to-be is validating changes being made to HEAD and using these changes in the current release version.
So the "new" plan is not to actually *move* stuff to contrib and let feature development happen there, but to only provide features in contrib that already made it into core. Sounds like a workable plan. Short pro/contra recap: + Same core-worthy standard for new code, no reliance of the "backport maintainer" to do the job as well as Dries does + No problems with getting code merged back into core for Drupal N+1 + No problems with upgrade paths, unless... well, whatever - solvable + Solves the "little incentive to work on core" issue, because the backport will be available in contrib soon + Integrates seamlessly with the current infrastructure + No worries about the module dying in contrib + Less effort backporting new features than forwardporting and constantly syncing with core - Important patches might get blocked by languishing in the core issue queue, can only be solved through a non-trivial number of maintainers/reviewers - ...actually, I can't currently think of any more real disadvantages. I think this is a great model to follow. The only requirement for success seems to be that the speed of feature development aligns with core for the "backport maintainer". When the developer needs lots of new features in a limited timeframe that are not interesting for core (or subject of heated discussions, say, "feed items as nodes") then unhappiness will still arise. But that's just peanuts, compared to the benefits. Also, I find it interesting that the same model is actually already practiced by Simpletest in contrib. -- Jakob's usual 3 cents