Re: Commit access to the new git ? Uploader status ?
Hi,
On Tue, 2007-07-17 at 17:45:39 +0100, Ian Jackson wrote:
> Frank Lichtenheld writes ("[long] Dpkg Team Organisation/Status"):
> > TODO:
> > Ian and Guillem (and maybe others) need to solve their disagreements
> > about coding style in the C part of dpkg
>
> I agree that we need to come to a conclusion about this. But there
> are some general principles involved which aren't specific to dpkg so
> I think debian-devel would be the right venue. I'll post there when I
> have a moment.
I'm unsure what those general principles would be that make debian-devel
that venue, but I'm curious to see that mail anyway, and I'd love to
reach a conclusion on this, as well.
> Guillem Jover writes ("Re: Commit access to the new git ? Uploader
> status ?"):
> > [re Breaks:]
> >
> > Some weeks ago I started considering applying them anyway, although
> > by reverting the formatting changes (which I think should be done
> > regardless, otherwise the diff gets quite messy).
I've applied all pending patches from you, I also fixed some internal
style inconsistencies on those patches. I've to comment on the
Maintainer mangling one, though.
> The patch I sent in #375711 is purely the reversion of something that
> is clearly an earlier mistake. The only change I made there is to
> return the indent width from actual tabs implying 8-column-per-indent
> to the 2-column-per-indent which is used in all of the rest of the C
> and C++ code in the whole of dpkg and which was used in previous
> versions of these very same files.
Ok, so I went for the middle ground. I applied the part of the patch
that was unifying the style for src/archives.c, but not the ones that
were switching complete files (those were also incomplete and producing
a mixed style anyway, as it was not fixing non-tabbed indentation). At
least now the files should be more or less self-consistent (even if they
are generally not, in fact).
> Surely it is clear that the change in those files (and the relevant
> part of src/archives.c) compared to earlier versions (cf 1.4.0 for
> example) is just a mistake caused by erroneous editor settings or
> tab/space conversion ?
I actually think those changes were done on purpose, as a progressive
transition to a different coding style. But let's define the new style
and then we can make the whole code base consistent.
regards,
guillem
Reply to: