[development] Reviewing patches and making decisions

[Earnie Boyd]

Quoting Chris Johnson <cxjohnson at gmail.com>:

> On Wed, Nov 5, 2008 at 10:01 AM, Nathaniel Catchpole
>
>> Exactly, and we're talking about core patches. Most active contrib
>> development is happening in Drupal 6, I generally don't see many patches
>> posted for Drupal 4.7 versions of contrib modules, or even Drupal 5
>> depending on which module it is.
>
>
> We were?  (talking about core patches?)
>
> I don't see that in this thread.  We were talking about all patches,
> as far as I could tell.
>

Until today, I've been talking about core patches.

> The arguments are indeed very different for core and contrib.
>

Indeed they are and the mechanism for contrib isn't the same nor as 
strong a force as core either.

> I was positing primarily about contrib, since that's where most of the
> need is.  Still, there is a problem with core issue queues
> languishing, too.

There are patches for core that are months, years old.  Yes, they 
languish because no one tests and marks RTBC.  So, naturally there are 
contrib patches that are also old.  But those are more maintainer time 
related.  However if those interested in a contrib patch reviewed and 
tested it then maybe the maintainer would be more willing to commit it.

> I can't remember the last time I posted a patch to
> core; it's become too hard for me to contribute meaningful new core
> code and get attention to it.
>

Is that due to lack of reviewers?  It seems people think there is a 
vast set of developers for core, that just isn't true.  There are a few 
that know the ins and outs of core by heart but you only need a hand 
full of fingers to count those.  Find a bug submit a patch, hope for a 
reviewer, don't be offended by any action of any reviewer, press 
forward and patch.

Earnie  http://r-feed.com
  Make a Drupal difference and review core patches.