Guillem Jover writes ("Re: dpkg semi-hijack - an announcement (also,
triggers)"):
> I'd like to clarify few more things, which have been brough up the past
> few days. Even if I don't usually accept open invitations to flamefests
> (re the OP).
Guillem emerges! At last!
The key claim Guillem makes is this:
> The missing changelog entries are actually minor compared to the rest
> of the problems with the branch.
>
> The branch has never been in an acceptable state, it needs cleanup,
He explains what he means by `cleanup' by listing a series of things
that are allegedly wrong with my triggers branch:
> On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote:
> > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying
> > his triggers patch dependent on:
> >
> > - reversion to two space indenting
The history of this change is as follows:
* At some point, without any kind of discussion, Guillem
unilaterally reformats several files to 8-character indents.
* On the *26th of June 2006* I noticed this because it caused
an unnecessary merge conflict while I was trying to do a merge
between the Ubuntu and Debian versions of dpkg.
* I thought it was a mistake because surely no-one would
deliberately change the indent depth in an existing piece of free
software. (A plausible mechanism for the mistake involves an
editor with tab-width set to 2; these kind of things do happen
occasionally.)
* I therefore posted saying to debian-dpkg that this loooked like a
mistake. I also filed a bug, #375711, with a patch to revert the
change.
* On the *30th of May 2007* I got the same merge conflict again in a
later merge. My bug report had gone unanswered. By this point
there is a considerable body of changes in Ubuntu which ought to
be merged into Debian, all of which have the original formatting
as I requested in my bug report.
* So I post to debian-dpkg again and Guillem tells me it was
deliberate.
Since then I have been trying to do as little work as possible. I did
the triggers based on the Ubuntu branch (with the original 2-space
indent) because that was less work since the plan was to deploy it in
Ubuntu first.
Since then it has been a constant source of friction, obviously.
I note that my bug report #375711 hasn't even been closed !
I will admit that my pride has been sorely injured too. I don't
necessarily expect that to be particularly convincing. But this kind
of behaviour from Guillem is just not on.
> - reversion of unrelated commits
> > - having explicit casts to (char*) of NULL in order to support
> > some non-Debian architectures
These two are the same complaint. I note that the dpkg team are quite
happy to add patches to support other operating systems:
76877c6f670321ffdff5f35e879ae1f07a335a46 is a fix which makes dpkg
(a) conform to standards and (b) work on Solaris, but is not necessary
on Linus.
I also reverted one other commit which made a semantic change which I
considered a mistake. After some discussion, new semantics were
agreed and implemented in my branch.
> > - a policy of bulk conversion of intentation style, instead of
> > the current policy of gradual conversion from two-space to
> > four-space
No, my policy is NO CHANGES TO INDENTATION STYLE OR OTHER STYLISTIC
MATTERS
> - having unrelated features/changes in the same branch
> - having the commits not split into logical parts
> > - having the git log not be bisectable or particularly meaningful
> > except historically
This is revlog polishing. Ie a waste of time.
There were no changes in those branches which are not textually
interrelated with triggers and therefore best merged first.
Of course now I have a `master' branch which contains everything.
Historical information is of course the point of revision logs.
> > - having Ian be part of the dpkg team
This is a complete red herring. I only did this in my branch when I
forked after other approaches have failed.
I have of course been discussing the special-purpose triggers branch
that I prepared in August and which I updated to be a fast-forward
from mainline in October. That is what the team should have just
taken.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
