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
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@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
This sounds like it would also have the knock-on effect of making it easier for more/different modules to get included in core over time, which I think many people are also keen on. Is that part of the consideration? seems like with this process we could conceivably have a "experimental" couple of modules included in each version to test their suitability for core. (like the tokens module or similar) I am not sure I followed the necessary cvs tag work flow completely, but I'm sure you're discussed the details and the overview sounds good. Would this mean that we would get a packaging script for install profiles? Side note - several people are commenting that comment.module is quite poor. Is there an alternative that people are using that I'm not aware of? It works for me usually.
On Tue, Apr 21, 2009 at 12:43 AM, Ryan Cross <drupal@ryancross.com> wrote:
This sounds like it would also have the knock-on effect of making it easier for more/different modules to get included in core over time, which I think many people are also keen on.
I think it'd make it easier to move modules in and out of core yes. With token specifically that'd be unlikely to be a module in Drupal core - it'd probably be part of system.module since everything else would need to use it. Views also would have to move into core proper since we'd want to use it for administrative pages etc. - so it's not a model that'd work for everything, and generally not for 'cool API-providing modules we want to see in core'. The only reason I'd suggest it for things like comment and forum is they don't provide far-reaching APIs.
I am not sure I followed the necessary cvs tag work flow completely, but I'm sure you're discussed the details and the overview sounds good. Would this mean that we would get a packaging script for install profiles?
We didn't discuss this in any depth, just the overview.
Side note - several people are commenting that comment.module is quite poor. Is there an alternative that people are using that I'm not aware of? It works for me usually.
comment.module works for most things, but the code, APIs, architecture and a few very annoying long-running bugs haven't changed much since Drupal 4.something. For the basic job of attaching comments to nodes it's completely fine, but it's not what it should be. For example you can't attach fields to comments in Drupal 7 yet, and no-one has started work on a patch. More on that general area here: http://groups.drupal.org/node/18705 - and no I'm not aware of any viable contrib alternatives except nodecomment. Nat
I am not sure I followed the necessary cvs tag work flow completely, but I'm sure you're discussed the details and the overview sounds good. Would this mean that we would get a packaging script for install profiles? We didn't discuss this in any depth, just the overview.
Absolutely not. Writing the packaging script for every install profile out there is a colossal task, it needs profile changes (I need Panels3...) too. We are talking of one install profile here, the Drupal core install profile. I have not looked at the code but surely Drupal is already special cased from contrib, it's another repo, different tag structure so it'd not be that big a change and once again, it's a change I am willing to contribute to. Once again, the way I imagine this, there would be a repository merged together from core and these core-contrib hybrid modules and you can check out from there. The fundamental difference between merely giving people commit access to specific parts of core is the ability for them to develop a DRUPAL-7--2 alongside the DRUPAL-8--1 version if they so want (and I believe they will want to). This makes it possible to have (some of the) aggregator features from D8 on a D7 install without having the whole site on D8. If the question is, but then why would anyone want to upgrade to D8, there will still be huge under the hood changes (DBTNG, registry) which you will want to have. NK
let me try to explain it with an example if I understand your request correctly. module version core-hybrid: aggregator-7.x-1.x = drupal 7.x contrib: aggregator-7.x-2.x and above core-hybrid: aggregator-8.x-1.x = drupal 8.x contrib: aggregator-8.x-2.x and above Yes, sounds good, one small step in the right direction, I support this idea.. I think it is a similar model how Acquia choose module versions, just much more strict.. one thing which I do not understand is what happens with the modules, which have files in the "includes" directory, like the menu module with menu.inc. I guess it won't be possible to change (improve) the menu.inc file in menu-7.x-2.x, but of course there would be a larger pressure on core committers if something really have to be changed in those include files for the new module versions..
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
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
Any attempt to move Foo module 7.x-1.x from core into contrib to allow for a co-existing 7.x-2.x requires to have module dependencies based on minor versions first. The alternative is to drop most of the module system and replace it with plugins (CTools). ;) sun
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.
Right. That's what I wanted to use, too.
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.
See, that's why I campaign for this change.
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.
That entirely depends on the maintainer. Core would come with DRUPAL-7--1 and then what the maintainer does with the project is her/his own doing -- the only two restrictions are that DRUPAL-7--1 should only get bugfixes and DRUPAL-8--1 needs to tag along with HEAD. What you do with DRUPAL-7--2 and/or DRUPAL-7--3 is absolutely your call.
How would Aggregator DRUPAL-7--2 be packaged? It would need a similar infrastructure like a Drupal contrib project, right?
It would be just a package exactly like any other. Already, if I am not mistaken, if you put a module of the same name in sites/all/modules then it will win over the core modules. If that's not so anymore, it'll be too easy to change. Regards NK
On Apr 21, 2009, at 10:58 AM, Karoly Negyesi wrote:
How would Aggregator DRUPAL-7--2 be packaged? It would need a similar infrastructure like a Drupal contrib project, right?
It would be just a package exactly like any other. Already, if I am not mistaken, if you put a module of the same name in sites/all/modules then it will win over the core modules. If that's not so anymore, it'll be too easy to change.
Packaging in the sense of packaging scripts on drupal.org. I. e. where would I send people to download a tarball of the aggregator DRUPAL-7--2 version?
Regards
NK
Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633
Karoly Negyesi schrieb:
Packaging in the sense of packaging scripts on drupal.org. I. e. where would I send people to download a tarball of the aggregator DRUPAL-7--2 version?
project/aggregator.
who would search there? Most people will never use a DRUPAL-X--2 version, as they simply don't know about it - except if you provide them via update-status, where it annoys the people who want their 'stable' core as shipped. This would imho lead to frustration of the foo.module's maintainer as all the new features he developed have to be a) forward-ported for HEAD of drupal b) maintained for current drupal, with a low user-base. I think it's better for these modules, that, if they *are* stable in a x.y-2.x release and this release contains the same features as the x.y-1.x release (shipped with core) did is deployed to all sites with this module through drupal's update mechanism. Cornelius
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it. And the idea here is not that we encourage everyone running Drupal core to upgrade to the -2.x versions of these modules - it's that they're available for those who need the extra features they provide. So if they end up with a few hundred or couple of thousand users instead of 80,000 (not that all core sites are running aggregator or poll anyway), that's completely fine. Better than the < 1000 people who install Drupal 7 before it gets to beta and rely on the testbot to pretend to use these modules otherwise. Nat On Tue, Apr 21, 2009 at 4:23 PM, Karoly Negyesi <karoly@negyesi.net> wrote:
who would search there?
The same who searches for cck/views/etc. Not to mention we can add links, handbook pages etc etc to explain the situation.
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
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). Additionally, system module's updates would need to be properly split up into .install files of the respective modules or they'll run unintentionally (i.e. twice for straight back-ports of stuff in HEAD). sun
On Apr 21, 2009, at 12:30 PM, Daniel F. Kudwien wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
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. Any 'fork' in contrib with the same name as a Drupal core module only worries me in so far as it's using up valuable namespace for exactly doing that.
Additionally, system module's updates would need to be properly split up into .install files of the respective modules or they'll run unintentionally (i.e. twice for straight back-ports of stuff in HEAD).
sun
Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Barth schrieb:
On Apr 21, 2009, at 12:30 PM, Daniel F. Kudwien wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
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.
Any 'fork' in contrib with the same name as a Drupal core module only worries me in so far as it's using up valuable namespace for exactly doing that.
I think that this would be rather confusing for joe average user and request that you leave the core namespaces alone. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuCuEACgkQfg6TFvELooRn9QCfcJG8+eBDKholM76kcmRGutIj XaUAn0MMOy9sDLrgkYstGi7wppAokSa5 =NE10 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerhard Killesreiter schrieb:
Alex Barth schrieb:
On Apr 21, 2009, at 12:30 PM, Daniel F. Kudwien wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it. 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.
Any 'fork' in contrib with the same name as a Drupal core module only worries me in so far as it's using up valuable namespace for exactly doing that.
I think that this would be rather confusing for joe average user and request that you leave the core namespaces alone.
Let me illustrate the "why". I am in the process of writing a slightly changed version of the dblog module. Most of the changes will be in the .install file. While I do think my changes are a good idea, others might disagree. It is one of the patches where Dries was more stubborn than me after all (http://drupal.org/node/78503, for the interested reader). Now, should I really call this dblog and use the 6--2 branch? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuvTwACgkQfg6TFvELooRFqwCZAfNgHTy/c76CK12e1/WVQAC4 AVoAoJoM5w6gYUTAwfmmqlyapHgytC6x =4SxK -----END PGP SIGNATURE-----
Gerhard Killesreiter schrieb:
Let me illustrate the "why".
I am in the process of writing a slightly changed version of the dblog module. Most of the changes will be in the .install file.
While I do think my changes are a good idea, others might disagree. It is one of the patches where Dries was more stubborn than me after all (http://drupal.org/node/78503, for the interested reader).
Now, should I really call this dblog and use the 6--2 branch
Alex is only talking about backporting patches which are actually in Drupal 7 already (as far as I know), so assuming that patch gets refreshed and committed, why not? A module with an issue queue is better than people clamouring for 'can I have a D6 version of this patch plz' on fixed issues in the core queue which are never going to get a straight backport in core itself. However I think using the actual namespace for the module does bring up some issues (hook_update_N() and just general potential confusion) - so we could consider aggregator_backport and dblog_backport or something instead (or at least really, really clear and standard descriptions on project pages). Another example where this is has happened already is tracker2 (which runs on Drupal.org) - although the issue it fixes is still a critical bug in HEAD and hasn't been updated in a while - hence why I think a 2.x branch of core modules is a good idea - it saves having to manually apply patches, fork, or reinvent the wheel - all of which has happened with aggregator, tracker, comment and others to various levels of success and confusion. Nat
Quoting Nathaniel Catchpole <catch56@googlemail.com>:
However I think using the actual namespace for the module does bring up some issues (hook_update_N() and just general potential confusion) - so we could consider aggregator_backport and dblog_backport or something instead (or at least really, really clear and standard descriptions on project pages).
I would rather see a different directory named backports than filling up contrib creating yet another confusion point to entry level people. Really this isn't fit for the contrib modules. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Quoting Gerhard Killesreiter <gerhard@killesreiter.de>:
Now, should I really call this dblog and use the 6--2 branch?
I know your question is rhetorical so I'll give a rhetorical answer of hell no. It's not even a backport. It is dblog-gerhard-style. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Conceptually, I view Drupal as shown in this illustration: http://i43.tinypic.com/2zqfll1.jpg Core is really 3 things -- the lowest level subsystems and abstractions providing APIs, the required glue and UI modules wrapped around them, and the current CMS-oriented modules included with core. It would be nice, in my view, to minimize the amount of "required" code to build a site with Drupal. The more there are specific use case modules which are tightly coupled in core, the more it gets in the way of developing flexible sites and supporting flexible APIs. ..chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Johnson schrieb:
Conceptually, I view Drupal as shown in this illustration: http://i43.tinypic.com/2zqfll1.jpg
Core is really 3 things -- the lowest level subsystems and abstractions providing APIs, the required glue and UI modules wrapped around them, and the current CMS-oriented modules included with core.
It would be nice, in my view, to minimize the amount of "required" code to build a site with Drupal.
This is already work in progress. Even block.module will be optional in D7.
The more there are specific use case modules which are tightly coupled in core, the more it gets in the way of developing flexible sites and supporting flexible APIs.
None of the modules that have been recommended for removal from core are really tightly coupled and hardly get in the way at all if you don't need them. CHeers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuSBoACgkQfg6TFvELooQQIwCfR2YEwCznDD5vHiBNetMTpmXY rZgAoIVGGuWyWHfGyE77x+A/mVqEGE2W =/SQ5 -----END PGP SIGNATURE-----
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
On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
This is not so simple. The gain for Alex would be that he can work on DRUPAL-7--1 while core is open with much more freedom. here, let me state this: would the quality of the code of aggregator be less high than the core standards? maybe. but, it already is way below. These only-by-history core module are already not core quality so let them develop more freely. We are looking for responsible maintainers so I am sure they wont degrade into a stinking pile of debris.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karoly Negyesi schrieb:
On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
This is not so simple. The gain for Alex would be that he can work on DRUPAL-7--1 while core is open with much more freedom.
here, let me state this: would the quality of the code of aggregator be less high than the core standards? maybe. but, it already is way below.
How do you reach this judgement?
These only-by-history core module are already not core quality so let them develop more freely. We are looking for responsible maintainers so I am sure they wont degrade into a stinking pile of debris.
I use aggregator on drupal.org and the only feature I miss is to exclude specific posts from a feed. Anything added beyond that would constitute cruft in my pov. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuDCQACgkQfg6TFvELooSkmQCfZLKnb2g+prgW/dGLY6hbsL/b mgQAn2BHMlOpJqQ87o+kFunEDk6w4zOt =o4Ss -----END PGP SIGNATURE-----
Well, just to be clear, my biggest issue with core aggregator has long been that it is not an API, so you cannot call most aggregator functions outside of the context of the core module. This is a problem when trying to extend its functionality, and why FeedAPI (and the push for FeedAPI in core) was created. Killes, since I know you have used MySite, take a look at the kludge I had to write to allow users to add feeds there -- aggregator in core should support that feature (e.g. non-admins adding feeds to a collection), but did not (and probably still does not). So I think that supports the statement that aggregator code is "below" the node module, for instance. Should we add new features to aggregator? Maybe not. But it needs an architecture overhaul. One that is better done in contrib, as it turns out. - Ken On Tue, Apr 21, 2009 at 2:10 PM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Karoly Negyesi schrieb:
On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
This is not so simple. The gain for Alex would be that he can work on DRUPAL-7--1 while core is open with much more freedom.
here, let me state this: would the quality of the code of aggregator be less high than the core standards? maybe. but, it already is way below.
How do you reach this judgement?
These only-by-history core module are already not core quality so let them develop more freely. We are looking for responsible maintainers so I am sure they wont degrade into a stinking pile of debris.
I use aggregator on drupal.org and the only feature I miss is to exclude specific posts from a feed.
Anything added beyond that would constitute cruft in my pov.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknuDCQACgkQfg6TFvELooSkmQCfZLKnb2g+prgW/dGLY6hbsL/b mgQAn2BHMlOpJqQ87o+kFunEDk6w4zOt =o4Ss -----END PGP SIGNATURE-----
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ken Rickard schrieb:
Well, just to be clear, my biggest issue with core aggregator has long been that it is not an API, so you cannot call most aggregator functions outside of the context of the core module. This is a problem when trying to extend its functionality, and why FeedAPI (and the push for FeedAPI in core) was created.
I can't understand why somebody remotely cares about such ephemeral things as feeds. :p
Killes, since I know you have used MySite, take a look at the kludge I had to write to allow users to add feeds there -- aggregator in
Frankly: Mysite was full of cludges at the time I used it (over a year ago).
core should support that feature (e.g. non-admins adding feeds to a collection), but did not (and probably still does not).
So I think that supports the statement that aggregator code is "below" the node module, for instance.
Should we add new features to aggregator? Maybe not. But it needs an architecture overhaul.
Ok, it you can make it more API-like while not bloating it too much, I can live with that.
One that is better done in contrib, as it turns out.
Still not sure I buy that. How should a core committer review the resulting patch? It will be a "take all or leave it" thing. And I think that the result might be "leave it". Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknuMzAACgkQfg6TFvELooQyeACff1yIVZZW8wJM4HdjU3k/M+f2 5W8AoI3kC0Q/RbVcOG3Nz993lQb5wfpB =kFnL -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
Should we add new features to aggregator? Maybe not. But it needs an architecture overhaul.
Ok, it you can make it more API-like while not bloating it too much, I can live with that.
One that is better done in contrib, as it turns out.
Still not sure I buy that. How should a core committer review the resulting patch? It will be a "take all or leave it" thing. And I think that the result might be "leave it".
Which brings us back to my earlier comment about roadmaps and submaintainers who can be trusted to implement them without the core maintainers having to take the time to sweat over every single flipping line in every single flipping patch, and because people know that they can't make decisions about implementation because every single line can be second guessed and vetoed by just two very busy people, so the patch stalls waiting for feedback from them that doesn't come because they're reviewing 15 other patches. Part of the problem with a shortage of reviewers is that there's a very small number of reviewers who, well, matter. :-) And there's an increasing amount of code they have to deal with. --Larry Garfield
I'll take full blame for having started this whole thing even though chx was the first to post it. I brought up being able to have more influence over core modules between major releases because of previously encountered instances of "Features don't get implemented outside of a major release, eg D7 will have new features but D6 will always be about bug fixes." In particular, I mentioned the aggregator module and the inability to change the sort order of the feeds. I am in full support of anything that will make Drupal more attractive to the general masses. Being able to add features between major releases is something that I think would do this. It would help to attract people to core since they would then have the knowledge that a patch might actually have a chance of being accepted in the next two months instead of the next two years. Maintaining stability is a huge thing, more than supporting my little request. This also means that anyone who takes on maintainership of a core module would need to be willing to commit to keeping the code in line with core standards. I think those persons, including myself, who are making this request and recommendation are willing to do that. And if we're not, then we shouldn't be making such a request.
On Tue, Apr 21, 2009 at 4:41 PM, Ken Rickard <agentrickard@gmail.com> wrote:
Well, just to be clear, my biggest issue with core aggregator has long been that it is not an API, so you cannot call most aggregator functions outside of the context of the core module. This is a problem when trying to extend its functionality, and why FeedAPI (and the push for FeedAPI in core) was created.
And the FeedAPI code has been working it's way into the agregator module: http://drupal.org/node/303930 andrew
On Apr 21, 2009, at 4:41 PM, Ken Rickard wrote:
Should we add new features to aggregator? Maybe not. But it needs an architecture overhaul. One that is better done in contrib, as it turns out.
Agree, we needed to start aggregator API improvements in contrib, it gave us the freedom to dabble and learn quick. The result is FeedAPI, you've been part of that as the mentor of the initial FeedAPI project in GSoC 07. Looking at FeedAPI you will be able to tell that we were still learning what it takes to build an API for feed aggregation. We're now about to apply the best approaches to core aggregator: http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted=&pa... []= 1 &status []= 16 &status []= 8 &status []= 13 &status []=14&status[]=15&status[]=2&version[]=7.x&component[]=aggregator.module I invite everybody to review :-) PS: the long link up there? that's a bookmark in my browser :P
- Ken
On Tue, Apr 21, 2009 at 2:10 PM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Karoly Negyesi schrieb:
On Tue, Apr 21, 2009 at 8:38 AM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
Looks like we could try to do this without changing HEAD development at all - if Alex starts with OpenID and Aggregator 2.x branches in contrib, then anyone who wants to could do the same for the other optional core modules. Then if it works we could look at better infrastructure around it.
This is not so simple. The gain for Alex would be that he can work on DRUPAL-7--1 while core is open with much more freedom.
here, let me state this: would the quality of the code of aggregator be less high than the core standards? maybe. but, it already is way below.
How do you reach this judgement?
These only-by-history core module are already not core quality so let them develop more freely. We are looking for responsible maintainers so I am sure they wont degrade into a stinking pile of debris.
I use aggregator on drupal.org and the only feature I miss is to exclude specific posts from a feed.
Anything added beyond that would constitute cruft in my pov.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknuDCQACgkQfg6TFvELooSkmQCfZLKnb2g+prgW/dGLY6hbsL/b mgQAn2BHMlOpJqQ87o+kFunEDk6w4zOt =o4Ss -----END PGP SIGNATURE-----
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633
Cornelius wrote:
Karoly Negyesi schrieb:
Packaging in the sense of packaging scripts on drupal.org. I. e. where would I send people to download a tarball of the aggregator DRUPAL-7--2 version?
project/aggregator.
who would search there? Most people will never use a DRUPAL-X--2 version, as they simply don't know about it - except if you provide them via update-status, where it annoys the people who want their 'stable' core as shipped. This would imho lead to frustration of the foo.module's maintainer as all the new features he developed have to be a) forward-ported for HEAD of drupal b) maintained for current drupal, with a low user-base. I think it's better for these modules, that, if they *are* stable in a x.y-2.x release and this release contains the same features as the x.y-1.x release (shipped with core) did is deployed to all sites with this module through drupal's update mechanism. Cornelius
the update status may list (core-hybrid module) project/aggregator-7.x-2.x as "Also available" as it does with any contrib module, and it does not force you to update. I do not see the problem here.
It would be just a package exactly like any other. Already, if I am not mistaken, if you put a module of the same name in sites/all/modules then it will win over the core modules. If that's not so anymore, it'll be too easy to change.
Regards NK ---------------- I believe this is true as I just did it on a Acquia site that had some of their package in a subdirectory of /modules (non-core contrib). However I wound up with conflicts somewhere as some parts of the theme no longer worked. I fixed it by downloading all the Acquia approved modules to /sites/all/modules and deleting the Acquia versions. I have no idea if theirs were vanilla off contrib or if they had tweeked them. I did not do a careful experiment to find out exactly what caused the problem (problem was the theme config page did not save its results to the database so it had no effect). I think what Acquia is doing is a precursor of some of the discussion here. So this is a warning that there be dragons there.
Quoting Karoly Negyesi <karoly@negyesi.net>:
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.
Maybe a different twist to contrib but rather these optional core provided modules residing in CVS as drupal/modules they reside in CVS as drupal-optional/modules? The drupal-optional modules would take on the same level of core review but cvs commit could be handled slightly different. Then the discussion is what contrib module becomes a drupal-optional module or what drupal-optional module do we want to drop support for and move to contrib. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
I'm confused about one point here. I must confess that although I don't have a lot of experience with Test driven development, I've done some of it and am familiar with the concepts. Are we sure that drupal.org provides automated testing infrastructure for contrib? I don't quite understand how that works given the possibilites of module conflicts and dependencies. If you say it works and can point to an example of a test driven contrib supported by d.o, I'll happily withdraw this concern, but I've always assumed that contrib test driven development couldn't happen, but that contrib providers would need their own infrastructure. Although my own module list of contrib to remove doesn't include comments or aggregator, I'm certainly ok with seeing contrib's removed from core, but I think there's value in having a small set of useful simple modules track with core and therefor get tests run for it (assuming I'm right about testing support). Dave On Apr 20, 2009, at 4: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
participants (17)
-
Alex Barth -
andrew morton -
Chris Johnson -
Cornelius -
Csuthy Balint -
Daniel F. Kudwien -
Darth Clue -
David Metzler -
Earnie Boyd -
Gerhard Killesreiter -
Jakob Petsovits -
Karoly Negyesi -
Ken Rickard -
larry＠garfieldtech.com -
Nathaniel Catchpole -
Ryan Cross -
Walt Daniels