Re: Bug tracker and transplants

[John W. Eaton]

On  1-Apr-2011, Jordi Gutiérrez Hermoso wrote:

| On 1 April 2011 14:06, Rik <address@hidden> wrote:
| > On 04/01/2011 10:00 AM, address@hidden wrote:
| >> This just got fixed by Rik with a hg change set, which I assume
| >> applies to devel sources, and now it's not on the tracker. But I guess
| >> that it's not fixed in stable, and if it's no longer on the tracker.
| >> One of the reasons I posted here was to serve as a reminder for stable
| >> (same goes for the ols.m patch the other day). I don't understand how
| >> the tracker works for bugs against devel and stable, does one need to
| >> make two separate reports?

No, there is no need to make two separate reports.  Unless we change
what we are doing, then what will happen with the 2.4.x release series
is that I will go through the patches applied to the default branch
and choose those which should be applied to the stable branch.

| > As far as I understand it, the version field is extra information, like the
| > operating system, that helps to narrow down where a bug might lie.  I don't
| > think it's being used in the way you suggest (to track which bugs need to
| > be transplanted).
| 
| Would I be entirely too repetitive if I insist that it would be better
| to avoid these problems by patching on stable and merging the patches
| onto default?

Well, you are pretty repetitive about this topic...

But you are probably also right about what we should be doing.

Before we can switch to doing what you suggest, I would like to
understand what will happen in the following cases:

  * What criteria should be used to decide when a patch should be
    applied to the stable branch?  I would prefer a conservative
    approach that does not destabilize the stable branch.  So I think
    we should only be fixing bugs on the stable branch, and then we
    should be careful to only fix problems when they can be done
    without sacrificing binary compatibility for the current release
    series.

  * What do we do if someone applies a patch to the stable branch that
    should not have been applied?  Do we just use "hg backout" to
    remove it from the branch?  If this happens before a merge and the
    change should have been applied to the unstable development branch
    only, then should it be applied after the "hg backout" or should
    the branches be merged, then

  * What is the right thing to do if someone applies a patch to the
    unstable development branch and it should also be applied to the
    default branch instead?  Don't you have to transplant in this
    case and duplicate the change on the stable branch?

  * How often should the stable branch be merged with the development
    branch?  After every change to stable?

  * What happens when the two branches diverge enough that merges
    almost always have significant conflicts?

  * How are releases made?  Are they created on the development
    branch, or is the development branch merged to stable at some
    point, or what?  If the development branch is merged to stable, I
    imagine there would be a lot of conflicts if the development
    branch introduced some significant refactoring.

jwe