[drupal-devel] Project management contribs: Bundles: grouped modules.

[Ross Kendall]

Hi Bèr,

I like your intentions to improve the way things work with modules, I 
also like the idea of well-integrated 'bundles', but I also think that 
the ideas need more development/discussion before we will have an 
appropriate solution to the problem (out-of-hand contrib modules).

A couple of points:
- I appreciate the number and diversity of modules (even ones that are 
quite similar).
- Being able to share 'special case' modules is a valuable dynamic of 
the Drupal community (even if they are not all compatible).

What I think would be good would be the creation of two classes of modules:
1. 'Official' modules - these would be first class modules that provide 
popular functionality, be well maintained, use standard ways of doing 
things, and not conflict with any other 'official' module.
2. 'Contrib' modules - various and eclectic modules that do provide some 
useful functionality, work well with the core and also all of the 
'official' modules, but are not required to work together with all of 
the other 'contrib' modules.

This would combine the best of both worlds - *Diversity*, and *Quality*

I think the core should stay 'lean and mean', then site admins (or 
'distribution' providers) can customise the functionality of their site 
by selecting from trusted 'official' modules.  Those who have particular 
special needs, can choose to develop their own modules, or make use of 
the shared 'Contrib' modules.

As I said before, I think bundles could be a good idea (if managed 
well), but I personally don't think it will solve the problem.

Other ideas to think about:
 - module rating system
 - module popularity system
 - dependency/conflict management (package management style)
 
Cheers,
Ross

(Disclaimer: ideas offered solely for the purpose of discussion)


Bèr Kessels wrote:

>Hi,
>
>Starting with the thesis: "The way contributions are managed now is not 
>suitable anymore. Esp. modules are growing out of hand, not only the amount 
>of modules, but mostly the way modules conflic,t overlap and even completely 
>duplicate one-another is a problem."
>
> We can only fix that with some effort and rearranging the way we handle 
>contribs. I do not beleive we can solve this with code, or extra features on 
>drupal.org. Allthough that might /help/, the real solution lies in management 
>of this project.
>Note that I am /not/ (yet) addressing the part where users cannot find 
>approporate modules for downloading: frankly I don't (yet) care about these 
>users: they should just look better. Once we manage the contribs better, we 
>can look into that. If it is still neccesary then.
>
>I see a couple of solutions, but I will only deal with one, here: bundles:
>
>definition:
>A bundle is a group of modules that have features in one area. A bundle is not 
>a subcalssification of single modules, but a single entity. A bundle has only 
>one project entry on drupal.org and it lives in one directory (+subdirs) in 
>CVS. It is therefore downloadable as a complete tarball only. Modules in a 
>bundle should be:
> * aware of oneanother. If A.module is anabled, B.module can hook into that, 
>or use additional features, in addition to the features A.module already 
>delivers. 
>  * reusing APIs. No duplication of code, re-use of optional .inc files. 
>  * never conflicting. enabling module A should never mean module B starts 
>spitting errors. Module B should know that it must "shut off" certain parts, 
>when module A is enabled.
> * Reusing databse tables. Currently most modules have private tables, tables 
>that even often confilct with others. Weblinks, for example, should be stored 
>in a single (set of) table(s), where all weblinks-realted modules (in the 
>weblink bundle) will store and get their info. It makes no sense if 
>relatedlinks.module stores weblinks in tableA,  weblinks.module in tableB, 
>blogmarks in tableC, flexinodes url.inc in tableD etcetc. 
>
>The e-commerce modules are a good example of this. For 4.6 we hope to have 
>weblinks into a bundle too, this would 
>
>Project management-wise a bundle would imply collaboration of a few 
>developers. These developers must communicate amoungs eachother, they should 
>use a separate directory in the sandbox CVS area as well as devide issues and 
>features amoungst eachother. 
>
>Pro: modules within same range of features can be managed in a central place. 
>Pro: modules within same range of features can be found in one central place
>PRo: modules within same range of features will work together. Together they 
>make a single and *complete* set of functions. separate managed modules (what 
>we have now) often have a lot of simil;ar features. Take for example 
>amazon_serach.module and amazon_items.module both offer some way to add 
>amazon ads to your site, both allow some amazon content to be published on 
>your site, but features differ slightly. Also, they use some moduified 3rd 
>party .incs, which are not shared, buyboth modules. Ideally we would split 
>them up and have:
>* one module that handles all ad-serving from amazon.
>* one module that handles content serving. 
>so thogether they make a complete system, instead of having to conflicting 
>modules.
>
>Con: Contributions of custommade modules is impossible/hard. If a module was 
>developed for yoursite.com only, it will most likely not fit within one of 
>the bundles. Question of course is, if we should host these modules at all. 
>Con: Second-level discussions need to take place. So some small mailinglists, 
>or even simply a list of CC-ed mailadresses are needed for each bundle. I 
>beleive this is no real problem as yet, in future some module on Drupal.org 
>could take care of this. 
>Con: It is hard to manage. esp because of the open nature of the contribs. WE 
>cannot dissallow people to contribute their custommade.module ATM, and we 
>will not be able to implement such a thing soon. Thus the bundle systems 
>would require common sense and good agreemenents between contributors. 
>Con: a user will have to download a complete bundle (lets assumne weblink 
>bundle) even if she only wants to have relatedlinks.module (which is part of 
>the weblink bundle).
>
>So, please tell me what you think of this idea, and if it is worth discussion 
>on drupalCON, or even on the lists only. 
>
>Regards,
> Bèr
>  
>