dpkg semi-hijack - an announcement (also, triggers)
With this message I am unilaterally declaring myself a maintainer of
dpkg, and also declaring that Guillem is no longer a maintainer.
I have just made the hijack upload, dpkg 1.15.0, which contains
triggers support. You can find the specification in doc/ in the
source, or in /usr/share/doc/dpkg-dev/triggers.text.gz.
It is with regret that I feel I have no option but to take this step.
The problem for me is Guillem, in his role as (what Raphael sees as)
current official authority for dpkg's C code. Guillem:
* Has been blocking the entry of triggers into lenny for 6 months
* Has been blocking the entry of other bugfixes from me
(See full changelog entry below[3] for details)
* Persists in making wholesale changes which he thinks are
stylistic improvements (including both actual code changes and
reformatting) but which are in some cases actually buggy,
despite me having explained the problems with them, and asked
him to stop [1][2]
* Is blocking my consensual entry onto the team
* Has not communicated at all adequately about these issues
I have spoken at length with Raphael on IRC. We had a productive
conversation which convinced me that Raphael and I could have a
productive working relationship. We were able to resolve our
difference over future workflow, at least setting aside the fate of
the triggers branch.
However Raphael made it clear to me that he was not willing for
triggers to be committed or uploaded until Guillem had reviewed and
merged it. Not because Raphael had doubts about the code, but because
Guillem had said 6 months ago he wanted to review it and we should
give him "a few more days".
Today I have been merging triggers with current HEAD myself. I have
had to revert wrong changes by Guillem and spend hours disentangling
conflicts caused by Guillem's formatting changes. So Guillem's idea
of a merge will no doubt include reintroducing bugs and formatting
changes to meet Guillem's ideas of good style.
I conclude that Guillem must go.
Based on reviewing many of his commits, I think it will be a
manageable loss. Guillem has made some useful commits but overall I
think the effect has been negative. In the unlikely event that
Guillem is willing to work with me after this broadside, I would be
happy to review and consider his submissions.
Raphael and the other dpkg maintainers perhaps do not feel themselves
qualified to evaluate Guillem's technical skills versus my own. In
any case in the absence of action from them I will not stand by.
To everyone else who has been on the dpkg team as an Uploader or
committer:
I am happy with the contributions you have been making. I'd like to
invite you to continue to work as you have before. I do not wish to
introduce any differences of status or process, and and do not wish to
put myself in charge over you. I intend to work constructively with
you as an equal.
If you have any questions or doubts I'm going to make myself available
on #debian-dpkg on IRC.
Many people will think that I'm being arrogant and rude. However, as
a good friend of mine once said, you can be rude or wrong, but not
both. Guillem has been rude in that he has ignored my polite
representations and explanations, and he is also wrong.
Or to put it another way, I should be trusted more because:
* Guillem has been making incorrect wholesale changes despite
being told why not to do so
* I have contributed important new features like Breaks
and triggers, both of which are solid production quality
* Guillem thinks that reformatting the code in free software is
a good idea
* I wrote the program in the first place
I have tried to resolve my problems by negotiation but this has
failed. [4] Now comes the time for action.
Mechanics:
I have made an upload which merges the current git HEAD with triggers,
with a revised Uploaders field.
The new situation in alioth's main dpkg tree is:
master-new The new master tree, with triggers and everything
Please commit here if you are not Guillem
Commit only changes ready for immediate release
iwj My personal version of the master
Do not commit here, but feel free to read
master-old The old master tree from before this semi-hijack
Do not use this tree, it is very stale
Changes made based on this branch are difficult to merge
I have deleted the `master' branch ref for the moment to avoid anyone
being subjected to an unpleasant accident. Around 48 hours from this
message I intend to rename `master-new' to `master' to confirm the
situation.
If you are a naive committer and don't care very much, you might want
to hold off until the dust has settled.
Aside from the above, please carry on with your the existing working
practices.
If you have a branch which has significant conflicts when you try to
pull, please just publish it somewhere and I will do the merge for you
to bring you up to date. If you do this, please state clearly that
you don't intend for me to commit to mainline so that we avoid
mistakes.
======================================================================
REFERENCES, BACKGROUND and FURTHER DISCUSSION
[1] Guillem persistently reintroducing errors, wholesale
Here is an example of a big code change made by Guillem:
http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=4e5846ccd3dcc33504aba8ef35a8962bccfd562e
However this is wrong as I explained here:
http://lists.debian.org/debian-dpkg/2007/10/msg00200.html
I also emailed Guillem privately in August 2007 to ask that he stop
this kind of thing.
Guillem has persisted with exactly the same mistake. For example:
http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=02680ecbbbf6da2b023891a11b38ecce5346dbbd
It is one thing to make a coding mistake. Everyone makes mistakes.
It is quite another to make a widespread change, without discussion,
and which is even if it is correct and worthwhile only at best
stylistically helpful. And then, after having been told that it was
wrong, to continue requires a dogmatic belief in one's own
correctness.
[2] Reformatting changes
Guillem has been engaging in a programme of reformatting and restyling
of dpkg's code.
See for example #375711 where I submit a patch to correct what seemed
to me obviously a tab/space conversion error, but which turned out to
be deliberate. (I first asked about this on debian-dpkg the 26th of
June 2006 and there was no reply until over a month later on the 31st
of May, so that I was already committed to my triggers code being
based on the original, rather Guillem's, formatting.) See also the
examples above.
Everyone who works on free software knows that reformatting it is a
no-no. You work with the coding style that's already there.
The effect of stylistic changes is that hours are wasted on spurious
edit conflicts. Indeed what ought to have been a 30-60 minute merge
job, to bring triggers up to current head, took me three hours.
It is of course also very rude, and leads me to wonder why Guillem's
opinion of a good coding style is to be preferred to mine. The answer
as to why mine is to be preferred in this context is simple: I wrote
the code to start with.
For the avoidance of any doubt, I do not intend to carry on a
programme of reformatting. I may write a short coding style document
to try to arrange that future changes conform to what I regard as best
practice, and I may reformat small submissions (since that doesn't
cause merge conflict trouble).
I'm avoiding the substance of the coding style dispute because that's
even more of a bikeshed issue than git-rebase.
[3] Changes that have been blocked by Guillem:
These are changes that I prepared or reviewed, and which have
unaccountably not been included in mainline:
[ Ian Jackson ]
* Triggers.
* Ship triggers.text to /usr/share/doc/dpkg-dev.
* Fix formatting of a few files. Closes: #375711.
* Treat successful calls to the postinst as always making the package
installed. Reverts Brian Carlson's patch from #432893.
* Fix missing angle bracket in Swedish po file.
* postinst in cleanup iff status was good beforehand. Closes: #432893.
This is the proper fix. If the package was halfconfigured, we
don't run the postinst and that way there are no surprises.
When we do run the postinst we know that we can without fear set
the package to installed (or trig*, as the case may be).
We achieve this by not registering the cu_prerm* handlers unless the
package was >stat_halfconfigured beforehand. We have no more need
to pass the previous state into the cu_prerm* postinst invocations.
* Do not pointlessly clear reinstreq flag on postinst abort-remove.
cu_prermremove is only be called via a push_cleanup in remove.c which
is only executed if the package is at least halfconfigured so
reinstreq must be clear to start with.
* Mark reinstreq during unpack as late as possible, not before prerm.
Previously the package would be reinstreq while we deal with
conflictors' prerms and deconfiguration, but that's unnecessary.
* Implement `Breaks' properly in dselect. It works just like Conflicts.
This is correct since dselect only deals with packages being installed,
removed or placed on hold.
* Fix erroneous description of Breaks in dselect.
The description should be `breaks' as in `A breaks B' rather than
`A breaks with B' since it is B that is broken by A and not vice versa.
* Correct broken dselect logic for self-conflicting packages.
[ Egmont Koblinger ]
* lstat correct conffile path even with --root. Closes: #281057.
Previously we would incorrectly ignore --root here. The change is
dpkg-1.13.22-oom-part2.patch from Egmont's June 2006 message to the
bug report, adjusted to fit without the part1 patch.
[4] Why not ask the Technical Committee to rule ?
The TC has not shown great dynamism in recent months. I have tried
quite hard as a TC member to get various questions that were put to
the TC decided, and the results have not been encouraging.
In any case, asking the TC about this at this stage would probably
take at least a month or more. This would make it that much harder
for other packages' maintainers to make good use of triggers in lenny.
It would also allow Guillem to continue making his undesirable
wholesale edits in the meantime.
Finally, of course, I am on the Technical Committee. For me to appeal
this dispute to it in this way would seem too much like me using it as
a personal bludgeon.
--
Ian Jackson, at home. Local/personal: ijackson@chiark.greenend.org.uk
ian@davenant.greenend.org.uk http://www.chiark.greenend.org.uk/~ijackson/
Problems mailing me ? Send postmaster@chiark the bounce (bypasses the blocks).
Reply to: