Hi Ian, 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). http://wiki.debian.org/Teams/Dpkg/GitUsage 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. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
