octave-maintainers
[Top][All Lists]
Advanced

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

Re: Stable branch for documentation changes


From: John W. Eaton
Subject: Re: Stable branch for documentation changes
Date: Tue, 19 Apr 2011 09:27:27 -0400

On 19-Apr-2011, Ben Abbott wrote:

| On Apr 19, 2011, at 12:54 AM, Jordi GutiƩrrez Hermoso wrote:
| 
| > On 18 April 2011 18:29, Rik <address@hidden> wrote:
| >> Just a reminder that documentation changes usually belong on the stable
| >> branch.  I've seen two changesets (12617:fb2e14a276d2, 12610:bdf694af4aa5)
| >> which are on default, but should probably be transplanted to stable.
| > 
| > Oops, sorry, my bad for one of those. I hadn't even considered that
| > documentation fixes should go on stable. I do suppose they can't
| > possibly break anything critical. Do we have consensus on this? Doc
| > fixes except for new features go on stable?
| > 
| > - Jordi G. H.
| 
| jwe, mentioned the policy here
| 
|       
http://octave.1599824.n4.nabble.com/policy-for-pushing-changesets-td3443512.html
| 
| ... and earlier on the thread below (Apr 07, 2011; 11:28am).
| 
|       
http://octave.1599824.n4.nabble.com/Re-Bug-tracker-and-transplants-td3421123.html
| 
| The other changeset was mine, I think.

I think it is also worth emphasizing the point I was trying to make
with

  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. 

It is important to remember that the stable branch should always be
tending toward more reliable.  Just because there is a bug report
doesn't mean that it must be fixed on stable.  If a fix is risky or
likely only affects a few people, or is really a feature request, then
it can probably go on default and become available at the next major
release.  This policy is likely better for the majority of users who
expect each stable point release to work better than the last.
Furthermore, the fix that is applied to default is always there for the
person reporting the problem to apply to their copy of Octave, or they
can build from the default branch.  If that is beyond their ability,
then they can always pay someone to build a custom version of Octave
for them that includes the fixes they need.

jwe


reply via email to

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