[development] Some of core to contrib?

[Alex Barth]

I am actually planning to create a 6 backport of OpenID and Aggregator  
for 7 (depending on the outcome of http://groups.drupal.org/node/21221  
and http://drupal.org/node/293318). I'd use project/openid and project/ 
aggregator for these backports.

I need to have these modules on 6 to deploy them on production sites -  
the only way to make sure stuff works. Working on HEAD without  
deploying changes in months is scary.

Current Drupal infrastructure is not conducive to these kind of  
backports, being able to keep these alternate versions for 6 in the  
same repository would be great. But I would pay for this advantage  
with the project page (crucial for communication around alternate  
versions like this) and with the packaging infrastructure of contrib.

So let me recap your suggestion, Aggregator DRUPAL-7--1 would be  
packaged with Drupal 7.x, there would be an Aggregator DRUPAL-7--2  
that would contain new features more or less mirroring HEAD.

How would Aggregator DRUPAL-7--2 be packaged? It would need a similar  
infrastructure like a Drupal contrib project, right?

Alex

On Apr 20, 2009, at 7:01 PM, Karoly Negyesi 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

Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633