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

[Bèr Kessels]

Op vrijdag 18 februari 2005 15:56, schreef 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).

That diversity is nice. But ATM that diversiti leads to a large diversity of 
not-finshed and not-perfect modules. Why cant we have one good set, instead 
of four unfinished ones? Answer is easy: because after scratching your itch, 
you are done, and the module is "dumped" in contribs. But other will have 
other itches. I am suggesting we stop scratching, and invent a "jar of 
crême" (i.e implement a management system) that will solve the itches too. 
Because scratching might help for that moment against the itch, that itch 
itself wont be solved. 

So: I dislike the model of diversity a lot. I know it is a common OSS problem. 
But without clear structures and management a lot of work is duplicated, even 
more work/time is wasted etc.

> - Being able to share 'special case' modules is a valuable dynamic of
> the Drupal community (even if they are not all compatible).
Yes true, but does that need to be on drupal.org? maybe, but in a sandbox or 
separate area, it should not be part of official downloads 
Will special cases be maintained? most prolly No ,because the itch is 
scratched.
 How many special cases actually ever make it into maintained modules? Harddly 
any, nearly all the spacial cases are old, broken and must be removed after a 
new release. Its those nen-special case modules that survive.

> What I think would be good would be the creation of two classes of modules:
> 1. 'Official' modules
> 2. 'Contrib' modules 
Can be combined perfectly.

> 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.

We should keep core out of this. This regards only contribs. Lets not aim too 
high. We will deal with core later, if ever.

> 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
-1. This will really not solve:
 * maintainability.
 * duplication of effort, APIs, code and features.
 * amoutn of modules contributed.
It will *only* show what modules are more popular, /if/ it will show us 
anything at all. How often do you base your choise of a module on popularity. 
I never did, and never will. Based on quality, yes.

>  - module popularity system
See above: -1, since It does not solve the issues we are discussing here. 

>  - dependency/conflict management (package management style)
Yes, but that is aiming very high. I do not beleive this will get in soon, if 
ever at all. 

Regards,
 Bèr
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]