Merging between unstable and experimental; changelog handling
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."
Reply to: