Re: triggers in dpkg, and dpkg maintenance
On Fri, 22 Feb 2008, Ian Jackson wrote:
> There is in my opinion no reason why this code should not be merged
> into sid's dpkg immediately - although there may be some merge
> conflicts by now. (I haven't been playing merge catch-up since I
> don't presently feel that my changes are going to be accepted.)
This is the only point to which I agree in your mail.
However you haven't made it easy to merge your code... you repository is a
mess to proof-read and the cleaning work that you don't want to do has
thus to be done by Guillem.
Guillem has some responsibility in the delay here but he's perfectly aware
of it. I've been nagging him a bit to merge your work and he told us that
he has been orphaning other packages to be able to work more on dpkg.
His latest plans are still to merge your triggers work for 1.14.17 AFAIK.
> During some of the discussions surrounding my return to dpkg
> development, the view was expressed that I ought to do some work to
> persuade particularly Guillem Jover of my usefulness and competence.
> I was encouraged by various members of the current dpkg maintenance
> team to pull my weight by doing some bug triage and fixing.
For other people, that was mainly me AFAIK.
> I request that the current dpkg maintainers formally reinstate me as a
> maintainer of the package, and that they agree that I should merge my
> triggers branch, and other fixes, into the main dpkg git tree so that
> it may be uploaded.
FWIW, you do have access to the repository but I would request you to be
removed from the team if you made usage of it in a way that doesn't
conform to the rules of the team. This includes having meaningful commit
logs and using private rebased branches for most of the work except when
we have a public branch where multiple persons of the team cooperate (such
as what happens with the sourcev3 branch currently).
FWIW, each commit pushed generates a mail sent to the PTS and I believe
that all main developers review changes that way (thus it's important to
have good log messages and changes committed in separate logical steps).
> I would like to see this happen without getting into bikeshedding
> about the proper use of git (and without pointless revision log
> polishing and without history-losing merges).
FWIW, IMO, either you follow the rules and you will be authorized to
commit on your own after some time, or you don't and you keep sending us
patches to merge (and you'll have to wait for someone to integrate your
work). Make your choice, invest a bit more time in preparing something
ready to be merged or wait...
I made all the path from external contributor to regular contributor and
I've been added to Uploaders recently. You can do it too I'm sure. I had
the chance to have djpig available to review my work and you're a bit more
dependant on Guillem to get started, but hopefully this won't stay a
problem for too long.
And last point, when we have problems withing the -dpkg team (and it
happens, we're only humans), we tend to resolve them by discussion on
#debian-dpkg and not by sending mails to -devel.
Le best-seller français mis à jour pour Debian Etch :