Correct branch for bug fixes

[John W. Eaton]

On  2-Oct-2011, Rik wrote:

| Should we be holding off on any commits to stable?  The 3.4.3-RC0 candidate
| seems to mostly work so I have been reluctant to commit anything to the
| stable branch even when it is a bug fix or just a documentation change. 
| Instead, I've been committing bug fixes to the dev branch since that will
| be the next release.
| 
| I potentially do have two useful candidate patches for 3.4.3-RC1 if we make
| such a tarball.  They both fix 'make test' errors on the MinGW platform.

I think changes to docs or tests could be applied with little risk.
If there are bug fixes, then I think it depends on the details of the
fix and bug.

If we could reduce the time between major releases to 6-9 months, then
I think we should be more selective about what goes on the stable
branch.  Currently we put a lot of bug fixes there, even some that are
not very well tested or otherwise risky.  Instead, I think we should
only be fixing problems that are known to be regressions from previous
behavior.  Then we have a better chance that each point release is
more stable than the last, even if some reported bugs are not fixed.
Meanwhile, if six months is too long to wait for a new stable release
that includes the bug fix, then we publish patches as soon as we make
them.  And there is always the option of paying for support...

jwe