Merging between unstable and experimental; changelog handl..

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.

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."


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

On Mon, Apr 09, 2007, Marc 'HE' Brockschmidt wrote:
> Loïc Minier <lool+debian@via.ecp.fr> writes:
> > 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.
> Which I think is a problem. I believe that changelog entries should only
> be merged when the related chages were merged. There is seldom more
> development on a stable (ie, uploaded to unstable) branch of a package
> than on the experimental version, so I think a useful way to handle
> this problem is to merge all changes made to the unstable version into
> the experimental version (and include the fitting changelog entries). If
> a package is moved from experimental to unstable, it should be done with
> svn mv [1].

So you want to keep experimental uploads in the unstable changelog? Or
do we edit the changelog after the svn mv to create a new unstable
version?

> I firmly believe that the changelog should only reflect development done
> on the branch that is actually uploaded, and not contain what was done
> to other branches. Remember, we do non-linear development, but
> changelogs only provide a linear way to represent changes, so we should
> document the actual line of development in the changelog of the package
> that we are uploading.

Sure, how does the proposal I made contradict the above?

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


--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org