RFC: Candidate 'premium' modules
Premium modules are those that are: a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers. Candidate modules: ---------- actions casetracker cck ecommerce event flexi* i18n image og project sections (when it is done) subscription trackback views voting api If it doesn't find its way into core, this list should also include a JS and XML API. Any modules being used on Drupal.org (simplenews etc.) will also need to be included. Conversely, any of these modules should be safely usable on drupal.org. ---------- Unsure about the following: workflow Access control modules : taxonomy_access/na_arbitrator? HTML editors? links module? Media/gallery modules ---------- Critical themes and translations should also be added to the list. Thanks, -K
On Tue, 16 May 2006 02:30:02 +0200, Karthik <narakasura@gmail.com> wrote:
Premium modules are those that are:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
Candidate modules: ---------- ecommerce i18n
First of all, I do not do contrib. But still, I know a few somewhat and these two can be b) but not a). No way. i18n is too closely coupled to core to port it to a new version before release.
Op dinsdag 16 mei 2006 02:46, schreef Karoly Negyesi:
No way. i18n is too closely coupled to core to port it to a new version before release.
Good idea Karthik. And we should really not let the decicion on "criticalness" lie in technical issues. if i18n is "critical" then it is critical. Wheter or not it is hard to maintain or to port, is not a reason for marking it not critical! But indeed. We need more details: why is something critcal. Who decides. Who decides who can maintain critical modules. Bèr
Bèr Kessels wrote:
But indeed. We need more details: why is something critcal. Who decides. Who decides who can maintain critical modules.
This list of modules - does it mark a change in the "raison d'ètre" of Drupal? I mean - if Drupal is there for some developers to "scratch their itch" - they must have developed one hell of an itch lately. If some Contrib modules are so critical to release, that a release can't be made until they're updated isn't that because there are sites that need these modules to be updated? If they are so critical - then aren't they actually core? At least the way core was seen in earlier releases? Or are they simply part of coming "distributions" that take these modules as part of a special purpose "package"? And would that not mean that Drupal could indeed be released first - as core - (with many or few modules inside core) - and the distributions could follow - with all the cool sets of modules? I just ask. 2 very small c from Gunnar
On 15-May-06, at 8:30 PM, Karthik wrote:
Premium modules are those that are:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
How do we keep track of which these are? Who decides? trackback, e.g. is afaik currently unmaintained... etc. I do, however, think that somehow giving folks an idea of which modules are worth trying before others is a good one. But this sounds like a sticky situation at best... tread lightly.
On May 15, 2006, at 8:26 PM, James Walker wrote:
On 15-May-06, at 8:30 PM, Karthik wrote:
Premium modules are those that are:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
How do we keep track of which these are? Who decides? trackback, e.g. is afaik currently unmaintained... etc.
I do, however, think that somehow giving folks an idea of which modules are worth trying before others is a good one. But this sounds like a sticky situation at best... tread lightly.
I am more interested in application-specific Drupal bundles and bundle maintainers. For example, we could have a forum-centric bundle, a blog-centric bundle, and a brochure-ware bundle. But bundles could easily become forks, in which I am not interested.
On 16 May 2006, at 03:26, James Walker wrote:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
How do we keep track of which these are? Who decides? trackback, e.g. is afaik currently unmaintained... etc.
I do, however, think that somehow giving folks an idea of which modules are worth trying before others is a good one. But this sounds like a sticky situation at best... tread lightly.
We've discussed this a dozen times -- like most of the things we're talking about nowadays. We'll use "usage patterns" to determine what the important modules are. Automatically sorting modules by popularity is something we're working on. Clearly, this will save us a lot of trouble. ;) -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 16 May 2006, at 03:26, James Walker wrote:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
How do we keep track of which these are? Who decides? trackback, e.g. is afaik currently unmaintained... etc.
I do, however, think that somehow giving folks an idea of which modules are worth trying before others is a good one. But this sounds like a sticky situation at best... tread lightly.
We've discussed this a dozen times -- like most of the things we're talking about nowadays. We'll use "usage patterns" to determine what the important modules are. Automatically sorting modules by popularity is something we're working on. Clearly, this will save us a lot of trouble. ;)
This should be relatively easy now that we have dedicated downloads stats or modules. Currently, the chart is as follows: tinymce-4.7.0.tar.gz 3052 image-4.7.0.tar.gz 2958 img_assist-4.7.0 1633 event-4.7.0 1575 meta-4.7.0 1572 friendselectric-4.7.0 1565 gallery-4.7.0 1480 drupal-4.6.6 1450 acidfree-4.7.0 1436 antique_modern-4.7.0 1308 niftyCorners-4.7.0 1195 de-4.7.0 1143 category-4.7.0 1101 phptemplate-cvs 1091 front-4.7.0 1048 fancy-4.7.0 1037 print-4.7.0 999 box_grey-4.7.0 972 cck-4.7.0 966 controlpanel-4.7.0 958 adsense-4.7.0 927 For comparison: drupal-4.7.0 25851 Three conclusions: 4.6 isn't all that popular anymore (or rather: people who have it won't need to download it anymore, new people chose 4.7). Niftyness/graphical stuff is high on the agenda, and: Why are there so few German developers when the de translation is so popular? Cheers, Gerhard
On 16 May 2006, at 10:02 AM, Dries Buytaert wrote:
We've discussed this a dozen times -- like most of the things we're talking about nowadays. We'll use "usage patterns" to determine what the important modules are. Automatically sorting modules by popularity is something we're working on. Clearly, this will save us a lot of trouble. ;) Didn't we add 'report back' functionality recently.
I recall that discussion in the run (crawl) up to 4.7. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 16 May 2006, at 10:49, Adrian Rossouw wrote:
On 16 May 2006, at 10:02 AM, Dries Buytaert wrote:
We've discussed this a dozen times -- like most of the things we're talking about nowadays. We'll use "usage patterns" to determine what the important modules are. Automatically sorting modules by popularity is something we're working on. Clearly, this will save us a lot of trouble. ;)
Didn't we add 'report back' functionality recently.
Exactly. Any Drupal 4.7 site can be configured to 'call home' and report back a list of the enabled themes and modules. Like that, we can see what modules are actually being used (rather than just being downloaded). By combining this information with download statistics, we can get a pretty good idea of what (i) the popular modules are and (ii) what modules are known to work with Drupal 4.7. This eliminates guessing, and most of all, the endless discussions inherent to that. -- Dries Buytaert :: http://www.buytaert.net/
Karthik wrote:
Premium modules are those that are:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
I actually talked this over with chx in the IRC, and said I'd send my thoughts on it to the list, and then didn't do that part. Mea culpa. Here's my theory: Scratch a). Can't call them release critical, because you can't have someone falling asleep at the wheel hold up things for everyone else. That said, b and c are important. But it's more than just b and c. So here's my version of the proposal. Drupal High Profile Modules =========================== 1) People close to Drupal, which is a rapidly evolving group of people that will likely have members leave and join but will generally be readily identifiable will take responsibility for code reviewing these modules, particularly in terms of security and ensuring that they are safe to run with Drupal. 2) These modules will be readily identifiable on drupal.org as these modules, and users can download them with an extra level of comfort knowing that a central part of the community has tested these modules. 3) These modules will serve as examples for other contrib modules to emulate. 4) The security team will treat security reports against these modules seriously, and will be willing to patch these modules and write security announcements when these modules are found to have security defects. This doesn't require much code, really; it does require a process wherein people who are trusted do code reviews against the candidate modules, and that the results of those reviews are taken seriously. It requires that commits against these modules are followed by Drupal developers, looking for mistakes. And it requires that the Drupal project module have a better release process so that these modules can have real versioned releases, like Drupal itself has. Modules will be chosen to be in this category based upon quality of code and a general sense of widespread use. A good indicator of whether a module should be considered for this role is the number of downloads / searches on the module. This indicates a level of interest. But it is only one factor; bad code won't fix itself, and this proposal doesn't require any of the Drupal developers to go fix other people's modules, except for security issues. And even then, the security team's role may be to remove the module from the list and say "This module is dangerous, we can no longer recommend its use."
On May 15, 2006, at 10:24 PM, Earl Miles wrote:
And it requires that the Drupal project module have a better release process so that these modules can have real versioned releases, like Drupal itself has.
now that the CVS access control is done(*), this is high on my list of drupal.org infrastructure improvements for the project.module. if anyone has a lead on sponsorship for this work, please let me know. thanks, -derek (*) if you care, please review http://drupal.org/node/ 62994#comment-98801. i think it's a much better UI for the "CVS access" tab. see http://drupal.org/files/issues/cvs_access_new- ui-3.png for a screenshot. it's still an auto-complete field, even though safari 2.0 is no longer showing the little circle...
I actually talked this over with chx in the IRC, and said I'd send my thoughts on it to the list, and then didn't do that part. Mea culpa.
Here's my theory:
Scratch a). Can't call them release critical, because you can't have someone falling asleep at the wheel hold up things for everyone else. That said, b and c are important. But it's more than just b and c.
The Drupal developer community is not exactly a perfect society - it is anything but. I honestly do not believe that any of the points outlined will actually succeed unless these modules are deemed release-critical. It is a practical requirement. IMO, this will just not work otherwise (call me a cynic). Falling asleep at the wheel should/can be remedied quickly and effectively. There is no perfect solution, but if these modules have multiple maintainers (thanks Derek :) , such occurences can be minimised. I personally don't see this being much of an issue except for modules like Project where there's a dearth of volunteers. Consequently, modules like Project, i18n and so on will IMO benefit immensely from such a system. But generally, as the modules in question are popular, there should (hopefully) be no shortage of contributors.
So here's my version of the proposal. +1 for the rest.
Let's try and get this out (release-critical or not) with a trimmed list of modules first and have endless debates on the importance of any modules at a later date. Thanks, -K
Karthik wrote:
Premium modules are those that are:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date. b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
I don't think having some classification of modules would be bad, but I strongly disagree about delaying Drupal core releases waiting for non-core modules to be completed. It's actually the other way around, sometimes we need a finished stable core to have the modules updated -also because we don't have a module versioning system which can handle module versions besides the version numbers in Drupal core. So, in my case I've been holding back the module release until I'm sure I can tag it 4.7 and it wont have to be updated 2 days after that to fix some pending critical bugs... I don't think it should be a real problem if you have to wait for a few weeks to have all the modules you need updated. There may be other people who can use that released core with other modules, and why should they wait for a module they don't need? The way to handle module collections is -again, I've talked about this before- distributions. So, I.e. someone can set up an eCommerce distribution which will be based on this of that version of core, or maybe a 'multilingual Drupal' distribution... But about modules and development either they are core or not. And that's all we need to know for a Drupal core release. It would be even better if the core -and the modules it has to wait for- was smaller, so we could update the other contrib modules before. Cheers, Jose
On 15-May-06, at 5:30 PM, Karthik wrote:
Premium modules are those that are:
a) release-critical - A new version of Drupal cannot be released unless these are up-to-date.
Not going to happen. We *have* to decouple contrib from core, otherwise we create an expectation that that entire universe of modules will be carried along by us, the developers, automatically....a kind of tragedy of the commons, where the expectation will be set without necessarily any support. If you DO want to have a release critical aspect, then make a distribution, as CivicSpace does.
b) quality controlled - these will be 'core modules' in all but name. c) well maintained - HEAD, current release and previous release should all be maintained preferably by a number of maintainers.
This are not controlled in any way by the Drupal community. Pretty much, economic factors will determine this (I spoke about this at length with David Geilhufe of CivicSpace the other day). I think we can get there by each publicly supporting (code or financial) which modules we (as individuals, dev shops, consultants, etc.) believe to be critical and need to be of consistently high quality. For what it's worth, here's what we're thinking for a "Drupal Base" * core * views * viewfeed * image * img_assist * tinymce I think this is a useful discussion in getting peoples' views on modules (albeit somewhat non-development), so below are my notes on your list. -1 indicates I don't believe it's ready to be a premium module today, +1 indicates I think it should be a premium module.
actions
-1. Evolving. Lots of interesting functionality, perhaps part of a higher end "big enterprise" set of use cases.
casetracker
-1. Evolving, not quite there yet.
cck
+1. More complex use cases. Don't necessarily want to overuse this in contrast to, e.g., page, blog, event, image.
ecommerce
+1. Specific use cases. Good candidate for a Drupal Ecom install profile.
event
+1. Needs refactoring -- turn it into a calendar "view" to display CCK and event-enabled content.
flexi*
-1. I understand that lots of people have used this in the past. CCK is the clear path forward, I for one am uninterested
i18n
+1. Should be headed towards core and/or a Drupal i18n install profile.
image
+1. Move image.inc into core, have image.module be somewhat minimal.
og
+1. It already is a premium module, modulo some of its recent very rapid development which has led to some instability.
project
Neutral. I understand its supreme importance for drupal.org, I have seen little evidence of use outside of drupal.org.
sections (when it is done)
-1. Has this ever had an official release? taxonomy_theme seems like a very good, robust solution here.
subscription
Neutral. I'm still unhappy with what is happening here.
trackback
-1. Can we say spam? Appropriate for a Drupal for Bloggers install profile.
views
+1. Fast track for core for some components. It already is a premium module.
voting api
Neutral. Good functionality
I think this is a useful discussion in getting peoples' views on modules (albeit somewhat non-development), so below are my notes on your list. -1 indicates I don't believe it's ready to be a premium module today, +1 indicates I think it should be a premium module.
actions
-1. Evolving. Lots of interesting functionality, perhaps part of a higher end "big enterprise" set of use cases.
casetracker
-1. Evolving, not quite there yet.
cck
+1. More complex use cases. Don't necessarily want to overuse this in contrast to, e.g., page, blog, event, image.
ecommerce
+1. Specific use cases. Good candidate for a Drupal Ecom install profile.
event
+1. Needs refactoring -- turn it into a calendar "view" to display CCK and event-enabled content.
flexi*
-1. I understand that lots of people have used this in the past. CCK is the clear path forward, I for one am uninterested
i18n
+1. Should be headed towards core and/or a Drupal i18n install profile.
image
+1. Move image.inc into core, have image.module be somewhat minimal.
og
+1. It already is a premium module, modulo some of its recent very rapid development which has led to some instability.
project
Neutral. I understand its supreme importance for drupal.org, I have seen little evidence of use outside of drupal.org.
sections (when it is done)
-1. Has this ever had an official release? taxonomy_theme seems like a very good, robust solution here.
subscription
Neutral. I'm still unhappy with what is happening here.
trackback
-1. Can we say spam? Appropriate for a Drupal for Bloggers install profile.
views
+1. Fast track for core for some components. It already is a premium module.
voting api
Neutral. Good functionality
I support Boris' rating. It pretty much matches my own. I'd like to see parts of CCK, views, actions, subscription, i18ln and image in core though. None of these modules are ready for core, and until then, I'm not willing to carry their weight. I do, however, encourage the authors of these modules to try and get a minimal version of their modules included in core. I'd be happy to work with you/them on this. -- Dries Buytaert :: http://www.buytaert.net/
-----Original Message----- From: Boris Mann [mailto:boris@bryght.com]
voting api
Neutral. Good functionality
I'd say -1 on VotingAPI. The modules built on top of it may be essential for certain kinds of sites -- community and portal sites for example -- but it's too heavy to shove into core given how many people just don't need what it offers. It belongs in a broader class of 'API modules,' I think. In particular, its integration with views and actions is still in flux, and needs a lot more development before it's 'fully baked.' --Jeff
On 5/16/06, Jeff Eaton <jeff@viapositiva.net> wrote:
-----Original Message----- From: Boris Mann [mailto:boris@bryght.com]
voting api
Neutral. Good functionality
I'd say -1 on VotingAPI. The modules built on top of it may be essential for certain kinds of sites -- community and portal sites for example -- but it's too heavy to shove into core given how many people just don't need what it offers. It belongs in a broader class of 'API modules,' I think.
These weren't "should it be in core" ratings, but rather, are these "premium" modules. In particular, its integration with views and actions is still in flux,
and needs a lot more development before it's 'fully baked.'
Yep...which I didn't explicitly state, but that was what took the +1 to neutral (today). -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 5/16/06, Boris Mann <boris@bryght.com> wrote:
trackback
-1. Can we say spam?
Truly. If I turn trackbacks on, I get 5 or so in an hour, 50 or so in a day. Not the module's fault, but it's exactly as useful as an open mail relay. -1
Earl Dunovant wrote:
On 5/16/06, *Boris Mann* <boris@bryght.com <mailto:boris@bryght.com>> wrote: > trackback
-1. Can we say spam? Truly. If I turn trackbacks on, I get 5 or so in an hour, 50 or so in a day. Not the module's fault, but it's exactly as useful as an open mail relay.
Not core, I agree, but that's really the least of my issues with trackback. IMHO trackbacks are comments and should be stored accordingly, for example. Which reminds me, I've been meaning to get a module for Akismet together for weeks now. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
participants (17)
-
Adrian Rossouw -
Boris Mann -
Bèr Kessels -
Derek Wright -
Dries Buytaert -
Earl Dunovant -
Earl Miles -
Gerhard Killesreiter -
Gunnar Langemark -
James Walker -
Jeff Eaton -
John Handelaar -
Jose A. Reyero -
Karoly Negyesi -
Karthik -
Konstantin Käfer -
Nic Ivy