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

[Bèr Kessels]

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
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]