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

[Ross Kendall]

Hi Bèr,

I think you slightly misunderstood my suggestions.  Basically my ideas 
was just the same as Károly.

1. well controlled set of modules, listed for download with Drupal.
2. 'wild' modules, that are listed elsewhere.

I just feel that if you try to control /everything/ to much, it stifles 
creativity, and people loose interest.  So the answer, control a set, 
and let the rest free.  Like I said, the best of /both/ worlds.

It is easy to criticise all the half-finished modules, however this is 
where the ideas get worked out, and they end up being the basis for what 
/is/ kept and made 'standard'.

more comments in message below...

Bèr Kessels wrote:

>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.
>  
>
I think is possible to have /both/ the diversity /and/ 'one good set', 
why not?

>  
>
>>- 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 
>  
>
What I meant by my suggestion /is/ to put them in a different place. So 
I agree.

>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.
>
>  
>
This is normal, not a problem.  They do help start the process of 
development towards a more general solution. Even if they do not last 
forever, they do solve an immediate problem for some people.

When you have a deadline to develop a website, there is no time to 
develop such elegant general solutions.  Sometimes a 'quick fix' is the 
right way.

>>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.
>  
>
Not sure what you mean?  I was trying to say that I think it's a good 
idea for them to be separate.

>  
>
>>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.
>
>  
>
I was not suggesting anything should be different with the core.  I like 
the way the core is.

>>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.
>
>  
>
Just for the non-official contrib modules, not for the high quality 
integrated modules.  You can't tell me that you do not use the ratings 
on sourceforge.net to help you find software.

>> - module popularity system
>>    
>>
>See above: -1, since It does not solve the issues we are discussing here. 
>  
>
As above, I think it's a good idea.  But as you say, it's a separate 
thing to worry about.

>  
>
>> - 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. 
>  
>
I just gave the last 3 ideas as future ideas, to help with thinking 
differently about the approach.

>Regards,
> Bèr
>  
>
Regards,
Ross