Guidelines for choosing between Stable/Default for code commits

[Rik]

7/14/11

John,

I'm wondering about the guidelines for choosing between the two branches
for code commits.  You published some guidelines in an e-mail when the
repository first split.  They are:

>  * Bug fixes that do not introduce binary incompatibility in the
>     current release series and improvements in documentation for the
>     current release should be applied to the stable branch.
>
>   * All other changes (code refactoring, new functions, new features,
>     or documentation for them, and everything else) should go on the
>     default branch.
>
>   * The stable branch will be merged with the default branch.  This
>     can happen any time.  If you make a change that is likely to
>     generate conflicts, it might be best if you perform the merge
>     since you will probably be in the best position to determine how
>     to resolve the conflict as you will know the intent of your patch.
>
> So unless you are fixing a bug or updating documentation that applies
> to the current stable release, yous should be working with default.
> We should be relatively conservative about what changes go on stable
> so that stable becomes more reliable over time.  The stable branch is
> not the place for large or risky changes.  If necessary, we can always
> transplant changes from default to stable.

The question was brought about by this bug and changeset
(https://savannah.gnu.org/bugs/?33456).  I verified the patch and committed
it to the default branch.  The gist of the patch is replacing is.get() with
is.read() which has a side effect of not setting is.eof() until attempting
to read beyond the end of file.

I realize that I didn't check it on to the stable branch because I was
applying some extra criteria.  In effect, I also look at the difficulty of
the patch and the potential for side effects.  Thus, a simple bug fix such
as adding an extra semicolon would get committed to the stable branch.  But
a fix like this, where I can't necessarily bound whether other functions
will be affected, I was reluctant to commit to stable.

I guess a larger issue is how stable we want the "stable" branch to be.  Is
it, in effect, a long-term release and won't change for ~3 years or until
the next major release (3.6) except for documentation and segfault-inducing
bugs?  If that is the case, is there something in between for users like
the regular 6 month releases of Ubuntu?  Should there be snapshots of the
development branch at regualar intervals?

The bug in question, not being able to read function handles in Octave's
very own binary format, seems important enough that user's shouldn't have
to wait 3 years for a fix but there are workarounds like using text format
so it doesn't necessarily need to be on the stable branch.

--Rik