[development] CVS HEAD, code freeze, zeitgeist

Larry Garfield larry at garfieldtech.com
Sun Aug 20 01:07:30 UTC 2006


On Saturday 19 August 2006 16:17, Bèr Kessels wrote:

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

Right then, I'm going to jump back into this can of worms I reopened...

First, to clarify (as it seemed there was a bit of confusion earlier on), I 
was talking about flagging modules, not developers.  Although I do recall 
Chad and I once spending a few hours toying with the idea of a goldstar 
module of sorts as a gag, like a year ago. :-)

I think Ber's picking up on the underlying message I'm trying to get at here.  
Drupal without contrib is an incomplete blogging system.  Core itself has an 
emphasis on a WordPress++/phpBB type site, but even then is missing a few 
features.  Any of the really interesting things that separate Drupal from 
those sorts of apps requires using contrib.  The Drupal Ecosystem includes 
large swaths of contrib.

I do not believe that placing, say, ecommerce in the same swath as NodeReview 
(an example I use because it's my own module, so I know it's not a major one 
nor can I offend anyone else <g>) does Drupal users, developers, or support 
people any favors.  

Dries points out that there are two issues involved here: Directing users 
toward modules that are worth their time and directing developers toward 
modules that need TLC.  He's right, but I believe those lists overlap 
dramatically.

How we determine which modules are "Special", both for users and developers, 
is open for debate.  I don't think that either a "Dries orders by fiat" 
or "Whatever gets most votes/downloads/closed issues in the project module" 
method will be adequate.  	But whatever the method, we need some way to 
clearly break down contrib and separate the wheat from the chafe, so to 
speak.  

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson


More information about the development mailing list