[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