1. -!- This excerpt has been edited by thb to group candidate responses
  2. <@don_armstrong> that concludes the first part of the debate, we'll take a 5 minute break so I can run around the lab here
  3. <@don_armstrong> While I'm running around, I'd like to reiterate how the second part of the debate will work; it'll basically be controlled chaos (as opposed to the uncontrolled chaos in the third part)
  4. <@don_armstrong> I'll ask a question, the panelists will indicate to me in the candidate backchannel that they wish to respond;
  5. <@don_armstrong> I will recognize them like the following:
  6. <@don_armstrong> recognize don_armstrong
  7. <@don_armstrong> they will then have 1.5 minutes to speak (or 5 messagse) whichever is lesser.
  8. <@don_armstrong> I will then recognize the next candidate, who will have the same limit
  9. <@don_armstrong> we will entertain rebuttals, again indicated through the backchannel.
  10. <@don_armstrong> throughout this, the candidates will be voiced, so they'll be cooperating with me to keep the chaos to some appropriately chaotic level
  11. -!- mode/#debian-dpl-debate [+v BillAllombert] by don_armstrong
  12. -!- mode/#debian-dpl-debate [+v SteveMcIntyre] by don_armstrong
  13. -!- mode/#debian-dpl-debate [+v AriPollak] by don_armstrong
  14. -!- mode/#debian-dpl-debate [+v AnthonyTowns] by don_armstrong
  15. -!- mode/#debian-dpl-debate [+v TedWalther] by don_armstrong
  16. -!- mode/#debian-dpl-debate [+v JeroenVW] by don_armstrong
  17. -!- mode/#debian-dpl-debate [+v AndreasSchuldei] by don_armstrong
  18. <@don_armstrong> ok; the candidates are ready, so we're going to start with the first question
  19. <+TedWalther> vim. definitely.
  20. <@don_armstrong> Q: There are some open issues in Debian, like multiarch and non-free kernel modules that seem to get bogged down due to the fact that there is no real consensus and thus neither proponents nor opponents manage to force the issue. Do you feel a DPL should take a more active role in identifying or even setting the project standpoint and making sure it is implemented within a reasonable timeframe?
  21. <@don_armstrong> Furthermore, how would you help this process to occur
  22. <+TedWalther> if the DPL has time, he should use his role to help the project arrive at a consensus. But at the end of the day, it is the kernel team that will make those hard decisions.
  23. <@don_armstrong> TedWalther: please don't respond unless you've been recognized.
  24. <+TedWalther> what is this, Roberts Rules of Order?
  25. -!- mode/#debian-dpl-debate [-v TedWalther] by don_armstrong
  26. <@don_armstrong> recognize SteveMcIntyre
  27. <+SteveMcIntyre> the DPL generally doesn't try to set technical policy, and I see that as a good thing
  28. <+SteveMcIntyre> by all means calling on the dpl to try and push technical discussions will help
  29. <@don_armstrong> sorry, my bad.
  30. <@don_armstrong> recognize AnthonyTowns
  31. <+AnthonyTowns> I don't think "forcing" the issue is a good thing, or having the DPL "set the project standpoint"; but having the DPL lead discussions, and try to make sure that the various options are clearly presented and refined is important,
  32. <+AnthonyTowns> as is making sure that we come to /some/ decision, even if that's "we don't know enough yet, let's investigate ____ ____ and ____ further, and then decide"
  33. <@don_armstrong> recognize BillAllombert
  34. <+BillAllombert> Most of the time the issue is that there are several workable solutions. The DPL can play a role by gathering everybody opinion and lead them to a consensus solution. This is especially important if it involves non-DEbian entities.
  35. <@don_armstrong> go ahead JeroenVW
  36. <+JeroenVW> For an idea to get implemented, one or more people need to actually be willing to work on those isssues
  37. <+JeroenVW> if nobody is interested to put time in it, it won't work
  38. <+JeroenVW> however, the DPL can help working out what direction to take
  39. <+JeroenVW> and getting the right people to talk to eachother
  40. <+JeroenVW> or perhaps, suggest an interesing, previously unthought of, direction
  41. -!- mode/#debian-dpl-debate [+v TedWalther] by don_armstrong
  42. <@don_armstrong> go ahead TedWalther
  43. <+TedWalther> If the DPL has time, he should use his role to help the project arrive
  44. <+TedWalther> at a consensus. But at the end of the day, it is the kernel team that
  45. <+TedWalther> will make those hard decisions. The most I can do as DPL is put
  46. <+TedWalther> forward a GR to modify Policy, which the kernel team will then have to
  47. <+TedWalther> follow. Changing Policy is not trivial, even for a DPL.
  48. <@don_armstrong> go ahead AndreasSchuldei
  49. <+AndreasSchuldei> The DPL is in this case just a normal developer, with a higher soap-box. People are more likely to listen to him and will perhaps decide to following his attempts of moderation.
  50. <+AndreasSchuldei> I would try to get people to talk about hard topics like these at DebConfs, for example, where there is time and plenty of bandwidth to do so and less chance of missunderstanding.
  51. <+AndreasSchuldei> Actually that is what happend at previous DebConfs, when Martin talked about kernel drivers and firmware during dinner, for example, and asked for more discussion and patientce with each other.
  52. <@don_armstrong> What are your thoughts on the proposed code of conduct?
  53. <@don_armstrong> hrm.. question is ill phrased apparently; lets replace it.
  54. <@don_armstrong> or rather, lets continue, since people want to answer.
  55. <@don_armstrong> recognize JeroenVW
  56. <@don_armstrong> (sorry for being slightly discombobulated here)
  57. <+JeroenVW> There is a debian community guidelines in the works by Enrico Zini. However, this is not intended as Code of Conduct, and it should not be used as a rule, but as a set of guidelines
  58. <+JeroenVW> I think that's very valueable to have, and I will definitely work on getting it recognized
  59. <+JeroenVW> However, I also believe we need to change our Code of Conduct somewhat, like what's now on lists.d.o. It should be reasonable moderate though, to not kill discussion and certainly not for it to be used as a stick to beat people with
  60. <+AndreasSchuldei> recognize
  61. <@don_armstrong> recognize AndreasSchuldei
  62. <+AndreasSchuldei> The code of conduct is a minimalistic and easily applicable measure to determine weather or not my behaviour in the debian context is ok. It is important that as many as possible know about and agree uppon this measure.
  63. <+AndreasSchuldei> I think it is quite important that we agree on this kind of guidelines. It should be possible to be able and stop and check if i should really go forward with this mail or just delete it before sending it. It should also be possible to point someone else in a friendly way to the code or conduct and suggest to others that they should check their own behaviour.
  64. <+AndreasSchuldei> For it to gain more influence on the debian community it is necessary that it becomes widely known and more and more accepted. Perhaps we should pass a GR to ratify it, similar as our constituion. The purpose is not to have a stick to beat someone with but to have a commonly accepted guideline for orientation.
  65. <+AndreasSchuldei> I am sure that we need this kind of measure and corrective to improve our working climate. If elected, one important task will be to inform people about it and raise awareness of it.
  66. <@don_armstrong> recognize TedWalther
  67. <+TedWalther> I am not aware of any proposed "Code of Conduct". But I believe all
  68. <+TedWalther> developers should have to read through the short, pithy book of
  69. <+TedWalther> etiquette I mentioned earlier on the debian-vote mailing list called
  70. <+TedWalther> Martine's Handbook of Etiquette, by Arthur Martine. It was written in
  71. <+TedWalther> 1868. All developers should take a comprehension quiz to make sure
  72. <+TedWalther> they understand it.
  73. <@don_armstrong> recognize AnthonyTowns
  74. <+AnthonyTowns> AFAIK, we don't have "a" code of conduct; I think it'd be worth trying to work on one -- the one's we've had so far have been developed separately and reflect ideas from a bunch of different people.
  75. <+AnthonyTowns> I don't think it should be viewed primarily as a way of "correcting people", but as a way of helping people get on with each other so we avoid people getting fed up and quitting or trying to kick people out.
  76. <@don_armstrong> recognize SteveMcIntyre
  77. <+SteveMcIntyre> A CoC is necessary, IMHO. The exact details need to be thrashed out,
  78. <+SteveMcIntyre> and we need to agree on them and then abide by the code we agree.
  79. <+SteveMcIntyre> That way I think we have more of a chance of avoiding/reducing the
  80. <+SteveMcIntyre> flamewars that we're often seeing; let's make it clearer that we will
  81. <+SteveMcIntyre> _not_ accept personal insults in technical debates, for example.
  82. <@don_armstrong> recognize BillAllombert
  83. <+BillAllombert> for the time being, I am opposed to an enforced code of conduct, however I am in favour of a set of guidelines and I gave some in my platform. I am unsure what is "the proposed code" the question refers to.
  84. <@don_armstrong> next question:
  85. <@don_armstrong> Do you believe Debian has hit a size barrier, with many or even most DD's not reading -devel any more? If so, do you think we're adequately tackling this problem?
  86. <@don_armstrong> recognize SteveMcIntyre
  87. <+SteveMcIntyre> no, not neecessarily a size barrier
  88. <+SteveMcIntyre> there is more and more detailed debian work going on away from -devel, and that's only natural
  89. <+SteveMcIntyre> dwn and the like make it easier for people to keep up, even if they're not readin all the detail on d-devel IME
  90. <@don_armstrong> recognize AndreasSchuldei
  91. <+AndreasSchuldei> Debian has grown a lot and it needs to find self-organizing structure in order to cope. This could very well be the "small teams" that i have been pushing for some times.
  92. <+AndreasSchuldei> debian-devel could remain as a central market place but would slow down traffic wise, since much information is moved locally, instead of centrally.
  93. <@don_armstrong> recognize TedWalther
  94. <+TedWalther> I don't see any problem with Debian's size. I think we could easily
  95. <+TedWalther> get bigger. We aren't all young, single male revolutionaries anymore.
  96. <+TedWalther> Debian has become mainstream. Lots of us don't have time to follow
  97. <+TedWalther> -devel, but we are active in our smaller sub-projects. That is a good
  98. <+TedWalther> thing, not a bad thing.
  99. <@don_armstrong> recognize AnthonyTowns
  100. <+AnthonyTowns> No; I think -devel's stagnated because it's signal:noise ratio has dropped substantially, and I think the DD count hasn't risen as much as it might, because it's been displaced by sponsorship and maintainers.
  101. <+AnthonyTowns> Other lists, and other teams are growing significantly, and there remain lots of new people getting interested in Debian, whether directly or through Ubuntu.
  102. <@don_armstrong> recognize JeroenVW
  103. <+JeroenVW> Debian is big, but we're actually doing quite fine. A lot of work can happen in specialized teams. However, we should take care to not lose the big picture, Debian needs to have a reasonable number of peopel working on 'general' issues
  104. <+JeroenVW> because of the big community etc, we've come to a point where we need to enforce some very very basic minimum social behaviour on lists
  105. <+JeroenVW> so that productive and constructive discussion can happen, regardless of the sheer number of people involved
  106. <@don_armstrong> recognize BillAllombert
  107. <+BillAllombert> I don't see any size barrier (the number of people contributing to Debian is grwing everyday) and I don' t believe not reading -devel is so much a problem. There are lots of Debian parts that are largely independant. The only issue I see is the lack of view of the "big picture" but I am unsure if debian-devel is supposed to adress that anyway.
  108. <@don_armstrong> Q: What do you think of Debian's status on the desktop? Is Debian capable of making the kind of polished desktop that people expect
  109. <@don_armstrong> from a Linux distribution, and if so what do we need to do to get there?
  110. <@don_armstrong> Q: What do you think of Debian's status on the desktop? Is Debian capable of making the kind of polished desktop that people expect from a Linux distribution, and if so what do we need to do to get there?
  111. <@don_armstrong> (now with less horrible formatting)
  112. <@don_armstrong> recognize JeroenVW
  113. <+JeroenVW> We can certainly be a good and polished Desktop distribution too. All it technically takes, would be different d-i options, or the current task selection. However, to really polish it out-of-the-box, we need to make some tradeoffs w.r.t. *defaults*
  114. <+JeroenVW> I feel that currently, we're not very good at making such choices, while Ubuntu manages to do so. This does not mean that we should give in on freedom at all, it's all about the defaults
  115. <@don_armstrong> recognize SteveMcIntyre
  116. <+SteveMcIntyre> Debian is perfectly capable of making a good desktop distro - I use it
  117. <+SteveMcIntyre> myself, and so do many others. But sometimes our users like the latest
  118. <+SteveMcIntyre> newest eye candy that our longer release cycles struggle to keep up
  119. <+SteveMcIntyre> with. Improving the speed of releases will probably fix most of that
  120. <+SteveMcIntyre> Our normal policies mean that we can already do quite a good job of making package work well together
  121. <@don_armstrong> recognize AnthonyTowns
  122. <+AnthonyTowns> I'm use ion, so I'm not well qualified to comment on the "desktop" stuff in general; but I think we're well on the way to being able to use the d-i betas and testing security support to solve the "old software" problem,
  123. <+AnthonyTowns> and new updates to Xorg, KDE and Gnome in unstable seem to be being handled fairly well these days; so I think we're well on the way to having good support.
  124. <@don_armstrong> recognize TedWalther
  125. <+TedWalther> Debian did many innovative things on the desktop. Unfortunately, that
  126. <+TedWalther> was a long time ago. Now we are playing keep-up. If people come into
  127. <+TedWalther> the project who want to fix that, great. Otherwise we'll just keep
  128. <+TedWalther> focusing on our strength as a developement and server platform.
  129. <+TedWalther>
  130. <@don_armstrong> recognize BillAllombert
  131. <+BillAllombert> We need to address the so-called "desktop" globally not packages by packages. Actually d-i had lead progress in that direction. but maybe there is a more general issue of providing predefined "profiles" on top of Debian. that would allow better desktop integration, but also better foo integration for a lot of foo. This is a challenge I consider.
  132. <@don_armstrong> ok, that concludes the second part of the debate; we're going to enter into the free for all shortly, after a brief 5 minute break.
  133. <+AndreasSchuldei> un?
  134. <+AndreasSchuldei> what about me?
  135. * +AndreasSchuldei just answers
  136. <@don_armstrong> recognize AndreasSchuldei
  137. <+AndreasSchuldei> Debian could produce a just as polished and well integrated desktop as other distros. The fine-tuning between the packages could happen in extra configuration packages as outlined in Message-ID: <20060305203953.GZ13066@schuldei.org> on -vote.
  138. <+AndreasSchuldei> Up-to-date software will be much less of an issue once we manage to release more regularly and in shorter intervalls. Joey Hess has good ideas to solve this and I hope he and the d-i team will make them happen.
  139. <+AndreasSchuldei> done
  140. <@don_armstrong> sorry, my mistake. ;-)
  141. <@don_armstrong> ok, now we've really finished the second part, so we'll start with the free for all in 4 minutes.
  142. -!- Part of http://people.debian.org/~mjr/irc/dpl-debate-2006/