policy for pushing changesets

[John W. Eaton]

On 11-Apr-2011, Ben Abbott wrote:

| John/Rik,
| 
| Going forward, what is the policy regarding pushing changes to the stable and 
default branches?

I posted the following info, but it was in a thread called "Release
3.4.1".  I should have started a new thread.

  [...] we can start using the new rules for commits to stable and
  default:

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

  In any case, if you are unsure of what to do for a particular patch,
  ask before committing the change.

| For example, what should be done with the getappdata changeset?
| 
|       https://savannah.gnu.org/bugs/?33012

If it fixes a bug and doesn't introduce a binary incompatibility
(changes to .m files usually can't cause trouble that way) and it is
not a risky change, then apply it to stable.

Thanks,

jwe