Re: Code reformatting

[Ian Jackson <ian@davenant.greenend.org.uk>]

Raphael Hertzog writes ("Re: Code reformatting"):
> On Wed, 12 Mar 2008, Steve Langasek wrote:
> > That's a fair criticism, but I don't think it changes the fact that making
> > style changes while there's a major branch merge outstanding is precisely
> > the wrong thing to be doing, because it directly impedes merging and causes
> > more work even if everyone agrees that the style changes are correct.
> 
> For the record, the "style changes" than Ian refers to are done on
> some preliminary parts of his trigger branch that Guillem started merging.

That is not true.

What Raphael claims are `style changes' are in fact simply that the
code has the original style.  From Raphael's point of view this is a
`change' because it reverts an earlier change.

The textually biggest difference between my branch and Guillem's is
the indent depth in three source files.  I discuss the history of how
that difference came to be here:
 http://lists.debian.org/debian-devel/2008/03/msg00401.html

The big difference between the two branches arose while I was dpkg
maintainer in Ubuntu.

Guillem made this reformatting change, and when I next merged from
Debian into Ubuntu I got a conflict.  Thinking it was a mistake, I
reverted it in the Ubuntu version (in any case, that was the easiest
way to make the Ubuntu patch apply).

I also emailed debian-dpkg to say I thought it was a mistake and filed
a bug suggesting it be reopenened.

Then ELEVEN MONTHS LATER I notice that it has gone uncorrected in
Debian's dpkg and ask again.  Then Guillem tells me it was deliberate.

By this point there are many changes in Ubuntu (including Breaks)
which are hard to merge with the reformatted code.

> So it's not blocking the integration of the trigger branch, it's the start
> of its integration!

This gives the impression that Guillem is merging my changes.  What
Guillem is in fact doing is some of the same things but with
gratuitous differences in filenames, formatting, etc.  This is likely
to result in a permanent rather than temporary fork.

Ian.