[development] How to post bug reports and patches

[Ivan Sergio Borgonovo]

On Fri, 31 Oct 2008 11:36:35 -0400
Angela Byron <drupal-devel at webchick.net> wrote:

> If you have better ideas on how to manage the process more
> efficiently, obviously we'd love to hear them.

Does anyone has some numbers about reviewers, maintainers and
"patchers" behaviour?

- Do most people prefer to submit/review patches to stable
versions rather than development version?

- Do maintainer respond quicker to patches submitted for the
development version?

- What is the average number of patches/review for each developer?

I'm going to assume that:
1) proposed patches to stable are more than development
2) patchers are much more than reviewer
3) patches to development are committed faster

Am I right?

I think:
1) happens because people find easier to "live" on a stable release
and they are writing a patch for a reasonably static code base that
won't make their patch obsolete easily. And there is no chance that
less than 20 maintainers can keep up with all the proposed patches
before a new UNSTABLE hits the street.
BTW I take this chances to say UNSTABLE releases are a very welcome
addition. Thanks!!!

2) happens because a) it's more fun to write code than reviewing it
b) it takes more responsibility to say "it works" than "it works for
me".

3) It takes less responsibility to commit to a development version
and... it is more fun. After all if you're a maintainer what's the
fun of taking the responsibility of applying a patch to a problem
that: is a feature but expose you to the risk of breaking something
or is a fix to a bug you didn't experience?

While a development version will always have its drawback maybe
making easier to build up a development/testing environment and
letting people understand where the "steering committee" and the
development is going would help increasing the numbers of people
getting involved in the new releases.
A more detailed guide on "how to put up your testing environment for
Drupal development" would help. That should take into account that
development version is a moving target and suggest how to cope with
it. I think learning how to cope with Drupal development branch is
particularly important for a project like Drupal since it is used to
make "great leap forward". That includes how to get information on
what's going on. That's a place where DVCS may help...

Reviewers live in limbo.
Their work is important but there is no filter and there is no
credit. Everybody can be a reviewer.
In spite of increasing the number of reviewers I'd decrease them but
give them more trust, credit and power.
Patch queues frequently becomes very long democratic discussions...
but very long... maybe there are too few BDFL.
A voting system or just counting how many people are subscribed to
an issue may give an idea to reviewers what are the hottest issues.
I'd say that counting how many people are subscribed to an issue is
a better thermometer. If you don't even want to be informed about
what's going on for an issue I wouldn't say you're really interested.

Somehow if the responsibility to commit to a stable version would be
more shared across trustworthy credited people, maintainers may
commit more frequently to stable.

I think the project is missing "middle management". "Middle
management" will also increase feedback to patcher. Even if their
patch won't reach core at least there will be someone more
"authoritative" explaining why.

Ups this post was waiting in my draft queue... but it looks as a bad
copy of what Larry just wrote...

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it