Merging between unstable and experimental; changelog handling

[Loïc Minier <lool+debian@via.ecp.fr>]

        Hi,

 I had plenty of different discussions on the handling of merges and
 changelog entries on IRC with various people, so I want to discuss
 and/or propose the way which seems the most logical to me.  Ultimately,
 this should end up documented on the pkg-gnome web pages when someone
 finds enough motivation to.  :-P

 I don't want changelog entries to be lost as they represent actual
 uploads; hence, in the past, I've merged changelog entries between
 experimental and unstable so that all experimental and unstable uploads
 appear in the changelog of the latest version; this is sometimes weird
 as it can shows two versions doing the same set of changes when we did
 them separately.

 So merging full changelog entries between dists seems bad.

 But wouldn't we merge changelogs, and declare an experimental branch as
 to be uploaded for unstable (svn rm unstable/source && svn mv
 experimental/source unstable), we would erase any "history" in the
 changelog which wouldn't have been merged before this.

 Some people also told me that the experimental changelog entries are
 just technical details which shouldn't be displayed to the consumers of
 changelogs in unstable.


 The only way I could reconcile everything above is the proposal below:
 - merge branches, never "svn mv" them
 - create a new entry in each dist with all the new merged changes after
   each merge

 Here's an example:
 unstable/:
     foo (2.14-2) dist=unstable
         * change 2
     --
     foo (2.14-1) dist=unstable
         * change 1
     --

 experimental/:
     foo (2.18-1) dist=experimental
         * new upstream
     --
     foo (2.16-2) dist=experimental
         * change 2
     --
     foo (2.16-1) dist=experimental
         * new upstream
     --
     foo (2.14-1) dist=unstable
         * change 1
     --


 => we decide to upload 2.18:
 1) "svn merge" the experimental branch into unstable from the date of
    the branching (after 2.14-1) up to the latest version, this includes
    superfluous changes
 2) resolve conflicts and resolve changelog conflicts by creating a new
    entry:
 unstable/:
     foo (2.18-2) dist=unstable
         * new upstream
         * new upstream
     --
     foo (2.14-2) dist=unstable
         * change 2
     --
     foo (2.14-1) dist=unstable
         * change 1
     --


 => we update 2.18
 unstable/
     foo (2.18.2-1) dist=unstable
         * new stable upstream
     --
     foo (2.18-2) dist=unstable
         * new upstream
         * new upstream
     --
     foo (2.14-2) dist=unstable
         * change 2
     --
     foo (2.14-1) dist=unstable
         * change 1
     --

 => we decide to prepare 2.19
 1) "svn merge" the unstable branch from the date of the merge up to the
    latest version
 2) resolve conflicts and resolve changelog conflicts by creating a new
    entry:
 experimental/:
     foo (2.19-1) dist=experimental
         * new stable upstream
         * new development upstream
     --
     foo (2.18-1) dist=experimental
         * new upstream
     --
     foo (2.18-1) dist=experimental
         * new upstream
     --
     foo (2.16-2) dist=experimental
         * change 2
     --
     foo (2.16-1) dist=experimental
         * new upstream
     --
     foo (2.14-1) dist=unstable
         * change 1
     --


 I expect this to be painful, but I satisfies the two constraints to not
 lose changelog entries nor have superfluous changelog entries.

 What do you think?

   Bye,
-- 
Loïc Minier
"For subalterns, saying something intelligent is as risky as saying something
 stupid."