[development] Some of core to contrib?

[Jakob Petsovits]

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