libquicktime-transition now

[Loïc Minier]

On Fri, Jul 06, 2007, Fabian Greffrath wrote:
> I am pretty sure that all those issues were fixed upstream in the
> meantime. Please note that there are 3 upstream versions (0.9.8,
> 0.9.9, 0.9.10 -> 1.0.0) between the packages in unstable and
> experimental.

 Currently, the BTS thinks you have fixed some bugs in the unstable
 branch of the package, but when we'll switch to the experimental
 branch, the changelog entries for the versions the BTS knew about will
 be missing, so the BTS will consider you have switched branch and will
 consider the bugs not fixed.

 The Debian bugs should have been closed in experimental too, when the
 relevant upstream release was prepared.

> I don't know what is the usual behaviour in such a case. 
> Maybe merge the changelogs and order them by date?

 One way is to consider all the changes you made in experimental as a
 big patch which you merge in a new unstable changelog entry, for
 example if you uploaded to unstable:

 unstable v1.0-2
   * change 2
 unstable v1.0-1
   * change 1
 unstable v0.9-1
   ...

 and to experimental:
 experimental v1.1-2
   * change 4
 experimental v1.1-1
   * change 3
 unstable v1.0-1
   * change 1

 Then you can svn merge the changes in the experimental branch to the
 unstable branch, fix the conflicts, and merge the changelog entries
 into:
 unstable v1.1-3:
   * merge changes from experimental
     - change 3
     - change 4
 unstable v1.0-2
   * change 2
 unstable v1.0-1
   * change 1

 This is cumbersome with SVN.

 Another way to do the change is to take the experimental branch to
 unstable, i.e. simply:
 unstable v1.1-3
   * upload to unstable
 experimental v1.1-2
   * change 4
 experimental v1.1-1
   * change 3
 unstable v1.0-1
   * change 1

 This is what I was about to do (and which I usually do) because it
 keeps a fine grained SVN history, while in the case of the SVN merge,
 you compress the history in experimental into a single commit.

 But in the second case, you have to ensure that you did not forget
 anything from the unstable branch when you overwrite it.  This is
 usually a simple matter of comparing whether all changes in the
 debian/changelog of the experimental branches are a superset of the
 changes in the unstable branch.  This is usually made simple to check
 when you either make fixes to experimental alone or to experimental
 first and then to unstable, and with the same changelog entry.


 I hope the above is clear; I've pointed that the very first change in
 unstable (a bug closing one) is not mentionned in experimental.  You
 should check, for all changes in unstable since branching, whether the
 change is present or required in experimental or make it.

 If you forgot to close a bug with a change in experimental, close the
 bug manually by mailing -done with the corresponding experimental
 version.

 (The above assumes you want the second technique.)


 Concerning changelog entries, I was an advocate of merging changelog
 entries for the purpose to document history, but this is wrong; you
 shouldn't do this; adding changelog entries would be lying about the
 real history of uploads a code branch really saw, even if it might be
 correct about the uploads a distribution saw.

-- 
Loïc Minier