[development] CVS HEAD, code freeze, zeitgeist

[Bèr Kessels]

Op zaterdag 19 augustus 2006 21:13, schreef 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 am sure after this mail that has changed :) Welcome!

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

Good points!

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

Also very true. This is my main reason to vote for goldstarred: They would be 
starred by real people, but based on facts other then simply its popularity. 

Popularity/downloads say something about a project's ability to 
a) fill a gap/niche.
b) market itself.
It tells us nothing about quality. If this was not the case, then Windows 
would not have its monopoly ;)

> 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 am sorry about making people think this. I think flexinode is far, far from 
a module that should hold up any freezes. I used flexinode as an example, 
because:
a) It had a completely horrible transition to 4.7. I took over management 
because it went unmaintained for a period in which people tagged it 4.7 (the 
whole system, including files that were not touched since before 4.5), added 
hacked in, people added features that introduced critical bugs etc. But 
no-one was co-ordinating and working towards a solid 4.7 release.
b) It has been between one of our most popular modules (in download stats). 
JonBob has told numerous times he never really expected this, and that he 
really did not design the module for such wide use. Its current quality is 
low, yet it fills a gap, and somehow marketed itself well. People want it, 
use it, regardless of its current state.

I really hope that I will manage a smoother transition to 4.8 for flexinode :)

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

I think that is the main reason why Dries's proposal for more visible stats 
are what most people seem to like.

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

A lot of people bring forward the idea that "a popular module will attract 
improvement anyway". This may, or may not be true. But I haven't seen proof 
for any of these.

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

Is there anyone with stats, or who remembers when people started to upgrade in 
the last freeze? I have a strong feeling most upgrades started only weeks 
after the actual release. A longer freeze might then only delay the moment 
people start upgrading.

Bèr