[development] Some of core to contrib?

[Nathaniel Catchpole]

So we discussed this a lot in irc this evening and I personally like it a lot.

It's got a lot of advantages over simply dumping poll in contrib, or
giving chx commit access to menu.inc.

1. We're not giving additional commit access to subsystems, just to
user-facing optional core modules which don't require the same levels
of expertise in patch reviews as the database layer or FAPI.
2. All issues for these modules would still show up in the core issue
queue (hopefully, somehow).
3. We wouldn't break any APIs in the official core release
4. Development still happens in HEAD, with features and bug fixes
backported to 7.x-2.x and bug fixes only backported to 7.x.1-x. That
way, for these modules at least, there's a consistent release model,
parallel to core (apart from the 2.x branch), which they all follow -
so you know you're not going to get new features or API breakage in
7.x-1.8 or anything like that, and you're guaranteed an upgrade path
(unlike trying to mimic this with a fork in contrib and forward
porting).
5. The majority of improvements to these modules (which don't rely on
API changes elsewhere in core) would be available in a release within
a month or two of getting committed to HEAD, not a year or two - which
would provide many more incentives to contribute to them.
6. The 7.x-2.x branch being used on real sites (opt-in only, not
shipped with core), means that 8.x-1.x will be ultra-stable and
subject to lots of real-world usage - no-one clicks around core any
more now we have the test bot, now they pretty much would. This means
/more/ review of changes in HEAD before a release, not less. Our core
CMS-like modules really suffer for lack of this - comment, forum,
aggregator are all in a sorry state.

7. Nothing changes for the core-required modules or anything in /includes

It'd be more work than now, but work which people would actually be
able to see the benefits of a lot quicker, meaning it'd be much easier
to build up the teams which webchick was talking about to distribute
that work - and wouldn't require a change to the core development
cycle itself.

Nat



On Tue, Apr 21, 2009 at 12:01 AM, Karoly Negyesi <karoly at negyesi.net> wrote:
> Hi,
>
> So it seems there is quite some talk about moving some of the core to
> contrib. This talk comes up from time but we did not have testing and
> now we do. And that makes a big, big difference, I tell you.
>
> So let's suppose that aggregator gets moved into contrib. Every core
> tarball still contains aggregator, the latest tag from the DRUPAL-7--1
> branch. But the aggregator people can churn out bugfixes as fast as
> they can and the tests will make sure they won't break stuff.
> Meanwhile, new features can get into DRUPAL-7--2. Every user can use
> --2 invidually, core will come with --1 still. Also, they maintain a
> DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they
> have ported aggregator and tag similarly as core does (we can punt
> some of the unstables -- I could understand that not every module gets
> DBTNG'd immediately it did not happen anyways). Let's list the
> benefits again:
>
> *) if a company is interested in a module it can grow a community
> around much easier than with core. They can both release bugfixes and
> features.
> *) core does not lose the feedback from its modules
>
> Possible problems:
>
> *) lose of maintenance
> *) additional burden on these maintainers w/ HEAD compatibility.
>
> Also, aspiring projects can opt for core inclusion (if they accept
> that a branch can not break APIs and willing to tag along with core)
> which can be much easier this way. Let's face it, there are much
> higher quality contribs than the mess called comment module so why
> not?
>
> There is the small problem of how can people using cvs update core
> now, do they need to run a cvs up for every directory? Hardly. We can
> create a 'mirror' which pulls together the commits. This is an easily
> doable (and yes I am willing to script it).
>
> Regards
>
> Karoly Negyesi
>