This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH]: Fix move and add code generation for 68HC12


On Sun, 4 Mar 2001, Stephane Carrez wrote:

> There is no reason not to have them on the mainline.
> 
> I was wondering whether it would be possible, at some time, to re-inject
> changes in 3.0 branch to the mainline, in some automated way.

It isn't generally appropriate to do things in that order.  If a change
meets the 3.0 branch criteria and is low risk it should go on mainline and
branch simultaneously.  If it may be appropriate for the branch but runs a
risk of destabilising the branch, it should go first on the mainline, and
later on the branch if it seems to be appropriate and stable; the branch
isn't a testing ground for the mainline, but rather the other way round.  
It's best for changes to go to both simultaneously (if appropriate for
both and safe) to avoid them getting lost to later releases.

I think changes are only appropriate for branch only if one of

* They relate to the branch / release version only, or to differences
between releases and mainline (e.g. version numbers, --disable-checking on
branch, fixes to code present only on branch and removed on mainline).

* They are a more conservative fix/kludge for something being fixed in a
cleaner but more risky way on the mainline.

In principle, the mainline should never have regressions or missing
features relative to the previous release / release branch.  While it
isn't easy to ensure this on all platforms at all times, ensuring that all
changes go to the mainline, and possibly also to the branch at the same
time, helps.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]