[development] CVS HEAD, code freeze, zeitgeist

[Metzler, David]

Although I'm new to the group, I'm not new to programming (since 86), and I'm not new to open source (since 95).  I'm just jumping off the drupal cliff (adopting it as my primary development environment for a college), so although I haven't earned a strong voice, I'm really vested in the outcome of the discussion.  I thought a fresh perspective/recap might be helpful here.  Agile deveopment/project management techniques are also a passion of mine. 

Here's some questions that the group seems to be trying to answer: 

1.  Would the success of drupal be improved by a module rating system to inform administrators of the stability level? 

On this everyone agrees.  The golden repository or golden * has been proposed a solution for this too. I think this could dovetail well with the automated comment proposal too. This sounds like a feature request for the project module to me.  I think it could be a really great tool for many open source developers.   I'd suggest we might consider measuring: 

 * average bug report to patch duration 
 * number of bugs that convert to patches in released code. (that's a bad thing, yes?)
 * How quickly did the module release after core? 
 * Maybe % of features requests converted to applied patches
 * number of downloads. 
 * an ability for the project owner to override and say, "my module ain't golden". 

I don't agree with measuring the size of the community, as that doesn't always equate to stability, or value.  It actually seems to discount elegent, simple, effective solutions. 


2.  Should the status of contributed modules that should hold up the release of Drupal? 

I haven't heard anyone actually suggest that the status of any one contrib module should hold up release.  But some argue the need to have a formal mechanism to identify critical mass. I've been hearing a lot about the project module and flexinode as examples of examples of some such modules.  Some are for, some are againts. 

I think we shouldn't do this.  If such modules exist, perhaps they should be in core.  It sounds like a flexinode replacement is being slowly rolled into core.  It's not featured enough yet to be a complete replacement, I think everyone agreed on that.  I often wonder why the project module hasn't been.  It's one of the few modules that we actually as a community can't do with out, not because of how much its used, but because its used to maintain drupal. If we ever got more than two versions behind on this would we shut down the drupal.org site :).  My point in bringing this up is that project isn't really a good case study for this discussion.  It's too important, so the question about what would happen if we released with out it can't be taken seriously.  (Oh we could do it once, but then even drupal.org couldn't upgrade)  

Could anyone think of modules for which there are not core replacements in progress, but that we'd want to consider holding off a release for?  Sounds like Dries sent a suggested list once. 

3.  If so how would we decide which modules would be used as the benchmark. 

Golden repository has been proposed as a solution here.  Some are concerned that it might slow core development or discourage module development. It could work, if we decided to do it.  

I have a feeling that unless we could automate the process of deciding which modules were "gold starred", that it would be work that takes away from improving drupal.  So I'm not real hot on this.  The less process the better.  Its the "agile" way :). 

4.  If not how can we make sure that the contrib modules don't fall too far behind?
Ideas I've heard are longer freeze periods, and better outreach to people want to contribute. 

I think the freeze period length increase is a strong idea to helping this speed issue.  I also think there could be some improvements in how contributers get recruited. 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4779 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060819/375add8f/attachment-0001.bin