[drupal-devel] Project management contribs: Bundles: grouped
berdrupal at tiscali.be
Fri Feb 18 14:13:44 UTC 2005
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:
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
* 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
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.
[ Bèr Kessels | Drupal services www.webschuur.com ]
More information about the drupal-devel