On Thu, 02 Feb 2012, Guillem Jover wrote: > Obviously part of this delay is my fault as the active blocking agent, > the one maintaining its C code base, but the trigger has been internal > working style discrepancies between Raphaël and me, which we have > discussed privately several times, and for which I don't feel it's > appropriate to talk about here, at this time.
I leave this up to you, but I would love to see this resolved, too. The fact that you put yourself as "the one maintaining its C code base" does not leave much room for anyone else to help you in this task. While I can understand that the "working style discrepancies" do not motivate you to train me... but right now there's nobody else willing to work on the C codebase and the few persons who tried in the past ended up moving away due to lack of guidance from the dpkg side. And this is worrying because you can't scale any further. > I found Cyril's attitude, and one of the release-team mails to be > extremely annoying, coming up with demands and threats, instead of > possible disscussion and proposals. If you were replying (in a timely manner) to (difficult) mails instead of just ignoring them, then we could have constructive discussions and proposals. > I think I might have been amenable to a possible upload to experimental, > if approached reasonably, which I don't remember anyone doing at any > point? I have certainly suggested you to make an upload to experimental to let people test while you were continuning your review. On IRC while you were still there but also by mail, for example here: http://lists.debian.org/debian-dpkg/2011/09/msg00006.html It was also in the original draft for the d-d-a mail: “The next version (1.16.2) will be the one introducing multiarch support and shall be uploaded to experimental in the hopefully not-too-distant future.” ... which you changed into (highlight mine): “The next version (1.16.2) _should_ be the one introducing multiarch support and _will probably_ be uploaded to experimental in the hopefully not-too-distant future.” It's also roughly the plan that I announced in http://lists.debian.org/debian-dpkg/2011/10/msg00052.html and that you NACKed. And I don't count the number of times where people (me included) have requested a "plan/schedule" from you. A proper answer from your part could well have been, “I don't know exactly but maybe we can do an experimental upload to let early testers play with it provided that I'm still free to do implementation changes before the unstable release”. That way you relieve some of the pression that annoy you... > During all this time, people has been saying how the code base was fine > and ready for mergeing, and trying to rush things out, but I've not seen > any of those people do any kind of code review at *all*? when it has been > demonstrated subsequently that the code had issues, bugs and more > importantly at that design ones. Obviously that those reviews would have > been more useful than the continuous complains, would only depend on their > quality, but I'd expect them to be way more useful in any possible way. I won't deny that your review improved the codebase and improved the design. But really none of the issues were real showstoppers that were intenable and that couldn't be fixed between the merge and Wheezy's release. > > a) The risk of legitimating the fact that by not acting a developer can > > block indefinitely the work of other developers (and possibly of the > > entire project when working on a rather far reaching release goal); > > I've elaborated more on this subject 3 months ago in [5]. > > > > [5] http://lists.debian.org/debian-dpkg/2011/10/msg00060.html > > Not acting!? I can accept not acting fast enough as people might like, > but not the former. I hate to have to do this, and to be honest I find > it petty, but my acting can be seen here, obviously not all related to > multi-arch, but quite many have been, just not in an obvious way: I agree that "not acting" was not really appropriate here. But the end result is the same. You have not show any willingness to work towards a more aggressive schedule... even when you had offers of help from me that you could have leveraged given that your own schedule did not allow for quicker progress. > > b) The risk of a negative impact on project morale if---due to the > > reason above rather than a legitimate technical reason---we will miss > > the Wheezy multi-arch release goal. > > Er, wow, I thought it was clear enough, given my review findings that > there's technical reasons why the branch was and is not ok... Can you share the technical reasons why it's still not OK? Since I wrote most of the code, I would be happy to fix what needs to be fixed. But you never responded to any of my help offers and you have never shared the results of your review publicly. > In any case a multi-arch enabled dpkg will not miss wheezy. This might be true but for multi-arch to be useful, you need more than dpkg. You need lots of packages converted and for this Debian developers must be able to play with multiarch packages. Which they won't be able to do if it's released 1 month before the freeze. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
