octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: policy for pushing changesets


From: Ben Abbott
Subject: Re: policy for pushing changesets
Date: Mon, 11 Apr 2011 22:14:12 -0400

On Apr 11, 2011, at 9:44 PM, John W. Eaton wrote:

> 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

I attempted to merge this Changeset.

        hg update -C default
        hg merge stable

 and encounter conflicts with the ChangeLogs. I'm given the option of ...

Choose Left
Choose Right
Choose Both (Left first)
Choose Both (Right first)
Choose Neither

I'm inclined to think "neither" is the proper choice, but thought it best to 
ask first.

Ben




reply via email to

[Prev in Thread] Current Thread [Next in Thread]