Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
On Thu, 2012-02-02 at 19:19:49 +0100, Stefano Zacchiroli wrote: [5] http://lists.debian.org/debian-dpkg/2011/10/msg00060.html [ I replied to that now. ] Your wording is indeed more appropriate, but it's also incomplete. In Debian nobody could be held responsible for not completing some work in a given time frame; nor could anybody be forced to work for the Project. At the same time, the inability to complete some work should not be used to block the work of others. Let's call this stalling. I believe you've been stalling --- with NACKs first and now with an NMU revert --- the work of a co-maintainer of yours and also of the entire Project, who is trying to reach a legitimate release goal. I'm convinced that such an attitude actively harms Debian and as such should not be tolerated. That's why I've asked for tech-ctte technical judgement on your decision to postpone the upload in wait of full code review. If by stalling you mean, having to work on an unpleasant, distressful and annoying environment, when supposedly doing it for fun, while still managing to motivate myself enough to make progress by doing design, implementation, review and cleanup work; not merging code I deem technically not acceptable, regardless of the provenance (for which I don't think I've ever discriminated on, as can be seen from the amount of unmerged branches on my own repo, because they are not ready yet...) on a project like dpkg, which has far reaching repercusion compatibility wise, where we might have to live with issues forever or where package maintainers might need to do useless fixup work due to the consequences of those issues, on the whole distribution, then I guess, sure, guilty as charged... guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
Package: tech-ctte
Severity: serious
Dear members of the Technical Committee,
I hereby submit to your attention the dpkg multi-arch conflict.
I believe the issue is well-known, so I describe it only briefly below;
feel free to ask if you need more information.
A multi-arch [1] enabled version of dpkg has been available for quite a
while. Its inclusion in the archive has been one of the early Wheezy
release goals. Since many months now, the upload of such a version of
dpkg has been held back due to repeated NACK-s by one of the dpkg
co-maintainers (Guillem Jover, Cc-ed), based on his desire to do a full
code review of the multi-arch implementation, which has written by the
other dpkg co-maintainer (Raphael Hertzog, Cc-ed as well).
[1] http://wiki.debian.org/ReleaseGoals/MultiArch
The desire to do a full code review is good, but Guillem doesn't seem to
be able to complete the review in a reasonable time frame. Since many
months now, the delay of the upload is a cause of worry for the release
team [2] and other project members. The situation has escalated to the
point that another developer (Cyril Brulebois) has done a dpkg NMU a
couple of days ago [3]; the NMU has been promptly reverted by Guillem
[4].
[2] http://lists.debian.org/debian-dpkg/2011/10/msg00050.html
[3] http://lists.debian.org/debian-dpkg/2012/01/msg00049.html
[4] http://lists.debian.org/debian-dpkg/2012/02/msg0.html
As DPL, I'm worried about two aspects of this issue:
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
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.
I therefore bring before you the issue of whether:
- one of the dpkg co-maintainers has the right to block indefinitely a
dpkg upload, in wait of full code review of the multi-arch code;
- or rather if the other co-maintainer has the right to override his
NACKs and go ahead with uploads that would allow project-wide testing
of the dpkg multi-arch implementation.
Many thanks in advance for your help,
Cheers.
PS I've to point out that timing on this issue is, unfortunately,
critical. The Wheezy freeze is close and according to the release
team we're already late wrt the ideal upload date for dpkg. The delay
is not tech-ctte's fault, of course, but please understand that a
long decision time on your part would be a de facto decision. I'd
appreciate if you could reach a decision on this in a timely manner.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
On Thu, 2012-02-02 at 10:08:13 +0100, Stefano Zacchiroli wrote: I hereby submit to your attention the dpkg multi-arch conflict. I believe the issue is well-known, so I describe it only briefly below; feel free to ask if you need more information. *Siight*... A multi-arch [1] enabled version of dpkg has been available for quite a while. Its inclusion in the archive has been one of the early Wheezy release goals. Since many months now, the upload of such a version of dpkg has been held back due to repeated NACK-s by one of the dpkg co-maintainers (Guillem Jover, Cc-ed), based on his desire to do a full code review of the multi-arch implementation, which has written by the other dpkg co-maintainer (Raphael Hertzog, Cc-ed as well). [1] http://wiki.debian.org/ReleaseGoals/MultiArch The desire to do a full code review is good, but Guillem doesn't seem to be able to complete the review in a reasonable time frame. 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. Since many months now, the delay of the upload is a cause of worry for the release team [2] and other project members. The situation has escalated to the point that another developer (Cyril Brulebois) has done a dpkg NMU a couple of days ago [3]; the NMU has been promptly reverted by Guillem [4]. 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. 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? if for example explicit and clear notice would have been given about the implementation to possibly still change before an upload to unstable. 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. As DPL, I'm worried about two aspects of this issue: 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: http://dpkg.alioth.debian.org/stats/ In any case I disagree with most of what is written on that mail, and it's one of the reasons that has made me sad about the direction Debian is taking. 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... In any case a multi-arch enabled dpkg will not miss wheezy. But I have kept finding extremely annoying, demotivating and a drain of fun at various times when working on Debian for the past last year or so... regards, guillem -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120202155953.ga23...@gaara.hadrons.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
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/msg6.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
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
On Thu, 2 Feb 2012 16:59:53 +0100, Guillem Jover guil...@debian.org wrote: In any case a multi-arch enabled dpkg will not miss wheezy.=20 Guillem, Are you really in a position to declare this? The release team as previously said [0] directly to you that they were looking for an upload in Octoboer in order to ensure this release goal was met. Forgive me if I've missed some other discussion about this, but since we are now months beyond this, are we expecting the freeze date to be moved to accomodate? Or has somehting else changed? stew [0] http://lists.debian.org/debian-dpkg/2011/10/msg00050.html pgpflFWpYYRmS.pgp Description: PGP signature
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
On Thu, Feb 02, 2012 at 04:59:53PM +0100, Guillem Jover wrote:
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.
Fair enough, you're right, not acting is not quite correct in this
case. I apologize for my inappropriate use of that expression.
Your wording is indeed more appropriate, but it's also incomplete. In
Debian nobody could be held responsible for not completing some work in
a given time frame; nor could anybody be forced to work for the Project.
At the same time, the inability to complete some work should not be used
to block the work of others. Let's call this stalling.
I believe you've been stalling --- with NACKs first and now with an NMU
revert --- the work of a co-maintainer of yours and also of the entire
Project, who is trying to reach a legitimate release goal.
I'm convinced that such an attitude actively harms Debian and as such
should not be tolerated. That's why I've asked for tech-ctte technical
judgement on your decision to postpone the upload in wait of full code
review.
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:
FWIW, I do not particularly enjoy all this either; in fact, I hate it.
But given all other attempts have failed, I felt it was needed. And it
was now or never.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#658341: upload of multi-arch enabled dpkg (in time for wheezy)
Coin, I remember working along with you on Debian/Hurd, and don't have any bad souvenirs, so i'm a bit astonished to find you in this situation. I found Cyril's attitude, and one of the release-team mails to be extremely annoying, coming up with demands and threats, instead of I heard many times that you didn't communicate much or at all (not to speak about public statements i could not see by myself), so i'm not surprised after several months people are beginning to be scared about the release (especially in the release team) and, maybe, overreacted a bit. http://dpkg.alioth.debian.org/stats/ I fail to understand why people should read VCS stats or logs to hear about your progress, considering the commit count is clearly irrelevant and one might not have the knowledge and time to read all the stuff. Why didn't you use d-d-a to give news about the project, and ask for reviews and help btw? It really seems to me you didn't trust your fellow developers, which is quite sad. If you were not able to work on this with buxy, maybe another could have helped you. In any case a multi-arch enabled dpkg will not miss wheezy. But I have kept finding extremely annoying, demotivating and a drain of fun at various times when working on Debian for the past last year or so... Even with all the code reviews of the world, you can't be sure your design will be perfect and will meet future needs. If it happens to be a failure, this code can still be deactivated before the release and the extra control fields / package reorganization won't hurt. Now that many probably have installed KiBi's package to have a look, you have at your disposal a big bunch of witting guinea pigs and maybe several able to proofread the code, so i really really hope you won't let us down (despite the disagreement). And let's have a bear some day :-). -- Marc Dequènes (Duck) pgpqYJtpduGdC.pgp Description: PGP Digital Signature
