Debian Project Leader Debate, 2007

  1. <don_armstrong> we're just waiting on a few of the candidates now; we'll get going in a bit [21:31]
  2. <SteveMcIntyre> fine [21:39]
  3. <don_armstrong> This year I'll be assisted by MJ Ray (slef) and Neil McGovern (Maulkin) [21:43]
  4. <don_armstrong> They will be following #debian-dpl-discuss and selecting questions from you to ask the candiates; if you have a question that you would like to ask, please bring it to their attention. [21:44]
  5. <don_armstrong> This year's debate is again broken into three main sections. [21:45]
  6. <don_armstrong> The first is a long response section, where the candiates are all asked a question and have 8 minutes to respond in a lengthy written response. [21:45]
  7. <don_armstrong> (err, 6 minutes rather) [21:45]
  8. <don_armstrong> The second is a short response, where the candidates will be asked a question, they'll each have 1.5 minutes or 5 lines to respond, whichever is shorter. [21:45]
  9. <don_armstrong> The final section is a free for all, no-holds-barred cage match. [21:45]
  10. <don_armstrong> The candiates this year are Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sven Luther, Sam Hocevar, Steve McIntyre, Raphaël Hertzog, Anthony Towns, Simon Richter. [21:45]
  11. <don_armstrong> They've already been asked the first question: [21:45]
  12. <don_armstrong> 1. Please give us a brief introduction of yourself, and tell us why you are running for DPL this year. [21:45]
  13. <AigarsMahinovs> I am 23 years old programmer from Latvia. I am a founder of Latvian Free Software Association and participated in the fight against software patents in EU. Currently I am finishing my Masters thesis in UK. [21:51]
  14. <AigarsMahinovs> I am running for DPL because I think that I have ideas and a vision that would allow Debian to remain at the forefront of the Free Software movement. [21:51]
  15. <SamHocevar> Hi, I'm a French hacker and scientist. I've been contributing to [21:52]
  16. <SamHocevar> Debian for 8 years now. I'm running for DPL because I see [21:52]
  17. <SamHocevar> problems (mostly communication) that I feel are important and are [21:52]
  18. <SamHocevar> endangering Debian both as a community and as a product. I think [21:52]
  19. <SamHocevar> I can solve efficiently and I'm not entirely satisfied with how [21:52]
  20. <SamHocevar> they have been addressed or even acknowledged in the past. [21:52]
  21. <WouterVerhelst> My name is Wouter Verhelst, and I've been a Debian Developer since 2001. [21:52]
  22. <WouterVerhelst> At the time, I was still at school, and went to become a Debian [21:52]
  23. <WouterVerhelst> Developer since I thought it'd be a nice introduction into this huge [21:52]
  24. <WouterVerhelst> Open Source/Free Software scene, but didn't plan to stick around for [21:52]
  25. <WouterVerhelst> long. It didn't take me long to figure out that Debian is one of the [21:52]
  26. <WouterVerhelst> leading forces within the Free Software movement, and that not sticking [21:52]
  27. <WouterVerhelst> around would be a grave mistake. [21:52]
  28. <WouterVerhelst> . [21:52]
  29. <WouterVerhelst> Running for DPL has been something I've been pondering about since about [21:52]
  30. <WouterVerhelst> 2004, if I'm not mistaken. Personally, I think that the DPL is, or [21:52]
  31. <WouterVerhelst> should be, someone who easily works with people, since his main job is [21:52]
  32. <WouterVerhelst> coordination. I feel I have the required qualities to do that. [21:52]
  33. <WouterVerhelst> . [21:52]
  34. <WouterVerhelst> Additionally, I'm hoping to be able to slightly change Debian's culture [21:52]
  35. <WouterVerhelst> for the better. This will require help from other developers, but I'm [21:52]
  36. <WouterVerhelst> confident we can do it. [21:52]
  37. <SteveMcIntyre> I'm Steve McIntyre, a long-time Debian developer with lots of experience of development, packaging and trying to organise Free Software groups and gatherings. There's more about that in my platform. I'm 32, single, I live in Cambridge in the UK, and I work for a company manufacturing Linux-based [21:52]
  38. <SteveMcIntyre> ..IPTV set-top boxes. [21:52]
  39. <SteveMcIntyre> . [21:53]
  40. <SteveMcIntyre> I'm standing for DPL because I think I can do a good job of it, both representing Debian and working on the goals I have outlined. [21:53]
  41. <RaphaelHertzog> I'm a DD since 1998 and accumulated lots of experience over the years. [21:53]
  42. <RaphaelHertzog> I have been progressively moving from simple packagers to active member of [21:53]
  43. <RaphaelHertzog> the QA team. It means that nowadays I work more on infrastructural issues [21:53]
  44. <RaphaelHertzog> than on my packages. I wrote the PTS and I am administering [21:53]
  45. <RaphaelHertzog> our Gforge installation. [21:53]
  46. <RaphaelHertzog> . [21:53]
  47. <RaphaelHertzog> I already candidated once for DPL in 2002 because I had many interesting [21:53]
  48. <RaphaelHertzog> projects. Since then I completed several of them and others have been [21:53]
  49. <RaphaelHertzog> implemented without my involvement. [21:53]
  50. <RaphaelHertzog> . [21:53]
  51. <RaphaelHertzog> I want to use this experience to enhance Debian because I encountered many [21:53]
  52. <RaphaelHertzog> problems. But I'm sure that I can't do it alone, I need many people to [21:53]
  53. <RaphaelHertzog> assist me. That's why I want to work within a DPL board. I like the work [21:53]
  54. <RaphaelHertzog> of others and I need their help to make Debian a better place to work. [21:53]
  55. <AnthonyTowns> Hi, I'm Anthony Towns, aka aj. I'm running for re-election to continue [21:53]
  56. <AnthonyTowns> the things I've worked on over the past year and to make sure we've got [21:53]
  57. <AnthonyTowns> a transition process so that other people get help in the role rather [21:53]
  58. <AnthonyTowns> than thrown in the deep end. Having seen just how much stuff you have to [21:53]
  59. <AnthonyTowns> deal with as DPL that I didn't expect I haven't listed too many specifics [21:53]
  60. <AnthonyTowns> this year, but I think the ones I have listed (maintainers, dak, ambassadors [21:53]
  61. <AnthonyTowns> and assistant DPLs) will be a respectable step forward. [21:53]
  62. <don_armstrong> The candidates have been asked the next question: [21:54]
  63. <don_armstrong> A key theme in the past few months has been communication, from inter/intra-team communication, to user<->maintainer communication. What do you plan to do as DPL to address the issue of communication? [21:54]
  64. <WouterVerhelst> Working on improving communication isn't easy; it requires one to work [21:58]
  65. <WouterVerhelst> on our culture, in addition to a few things that could be done on a [21:58]
  66. <WouterVerhelst> technical level. [21:58]
  67. <WouterVerhelst> . [21:58]
  68. <WouterVerhelst> For the technical things, I'm thinking of ways to make work by core [21:58]
  69. <WouterVerhelst> teams more transparent in as many ways as possible. The request tracker [21:58]
  70. <WouterVerhelst> that's been suggested is one thing, but most of this transparency [21:58]
  71. <WouterVerhelst> depends on the core teams themselves; I'll have to work with them to get [21:58]
  72. <WouterVerhelst> that done. [21:58]
  73. <WouterVerhelst> . [21:58]
  74. <WouterVerhelst> Next, I'm hoping to help improve our discussion culture by suggesting a [21:58]
  75. <WouterVerhelst> few rules that people can abide by (on a voluntary basis), and by [21:58]
  76. <WouterVerhelst> actively participating in discussions where I feel problems exist. [21:58]
  77. <AigarsMahinovs> Change the topics. There is and always be communication problems in an organisation as large as Debian has become. [21:59]
  78. <AigarsMahinovs> It is important to identify the clots as soon as possible and see them trough before the problems related to a communication clots intensify beyond all reasonable borders. [21:59]
  79. <AigarsMahinovs> However in general: stap back, cool down and try another way would be my advice. [21:59]
  80. <SteveMcIntyre> I'd like to encourage people to think more about how they say [21:59]
  81. <SteveMcIntyre> things on IRC and mailing lists (especially). A large part of [21:59]
  82. <SteveMcIntyre> the problem is people not considering the effects of what they [21:59]
  83. <SteveMcIntyre> say and how they say it. [21:59]
  84. <SteveMcIntyre> . [21:59]
  85. <SteveMcIntyre> Also, I will push for various of the core teams and people to [21:59]
  86. <SteveMcIntyre> post regular updates on status so that people can see what is [21:59]
  87. <SteveMcIntyre> going on. [21:59]
  88. <SteveMcIntyre> . [21:59]
  89. <SteveMcIntyre> The two are interlinked; we need to make our lists and channels [21:59]
  90. <SteveMcIntyre> healthier places for people to put those updates without fear [21:59]
  91. <SteveMcIntyre> of abuse. [21:59]
  92. <SamHocevar> It's hard to make people communicate if they don't want to, [21:59]
  93. <SamHocevar> especially when they're "serving" you. But I find it an abuse [21:59]
  94. <SamHocevar> of power when you have a key position and do not communicate, [21:59]
  95. <SamHocevar> I therefore would like to make reporting mandatory at least [21:59]
  96. <SamHocevar> for delegates or delegated teams. Failure to report would be [21:59]
  97. <SamHocevar> considered a lack of time and I would therefore assign [21:59]
  98. <SamHocevar> additional assistants to these teams. [21:59]
  99. <SamHocevar> I also believe merging scattered services back into the Debian [21:59]
  100. <SamHocevar> infrastructure may also improve passive communication by [21:59]
  101. <SamHocevar> making it unnecessary to ask for the information. [21:59]
  102. <AnthonyTowns> I don't think communication problems are something that the DPL can [21:59]
  103. <AnthonyTowns> magically solve -- both Martin and Branden worked very hard at that [21:59]
  104. <AnthonyTowns> without achieving a great result, and at least Bdale, Martin and Branden [21:59]
  105. <AnthonyTowns> had difficulties meeting their own goals of communicating themselves as [21:59]
  106. <AnthonyTowns> DPL. I specifically tried to set a low bar for my own reporting as DPL, [21:59]
  107. <AnthonyTowns> but I think with Steve's help we've managed to set a reasonably good [21:59]
  108. <AnthonyTowns> example of regular, interesting posts to d-d-a and elsewhere. As I noted [21:59]
  109. <AnthonyTowns> in [0] (and since then), there's been significant progress in setting up [21:59]
  110. <AnthonyTowns> an official DSA-supported rt instance to track non-package issues (such [21:59]
  111. <AnthonyTowns> as admin and keyring requests) which has been one of the things that's [21:59]
  112. <AnthonyTowns> been on the agenda, and I expect that will actually make a substantial [21:59]
  113. <AnthonyTowns> improvement once it's operational. Beyond that, I've been trying to [21:59]
  114. <AnthonyTowns> encourage other folks to report on what they've been doing to d-d-a when [21:59]
  115. <AnthonyTowns> it makes sense, and I think that's worked well most of the time. [21:59]
  116. <AnthonyTowns> . [21:59]
  117. <AnthonyTowns> [0] [21:59]
  118. <RaphaelHertzog> I want to show the project how we can communicate and bring issues to [21:59]
  119. <RaphaelHertzog> a solution. I plan to do this within the DPL board. I selected it so that [21:59]
  120. <RaphaelHertzog> all members have very good communication skills. They're not used to [21:59]
  121. <RaphaelHertzog> resorting to flames. But they still represent the diversity of the [21:59]
  122. <RaphaelHertzog> project. [21:59]
  123. <RaphaelHertzog> . [21:59]
  124. <RaphaelHertzog> I also want to draft some guidelines describing what we expect from our [21:59]
  125. <RaphaelHertzog> core teams, in particular in terms of communication with the rest of the [22:00]
  126. <RaphaelHertzog> project. I have handled the role of Alioth administrator in an open manner [22:00]
  127. <RaphaelHertzog> and I have always welcomed help. There's no reason why we can't extent [22:00]
  128. <RaphaelHertzog> that to all our teams. But they will need our help, there's a reason why [22:00]
  129. <RaphaelHertzog> their badly communicating: we're simply too negative on most public [22:00]
  130. <RaphaelHertzog> communication that anyone can do. This needs to change. [22:00]
  131. <RaphaelHertzog> . [22:00]
  132. <RaphaelHertzog> Of course, I'll keep the project informed and involved in all those [22:00]
  133. <RaphaelHertzog> projects. [22:00]
  134. <don_armstrong> The candidates have been asked the next question: [22:00]
  135. <don_armstrong> We've gained somewhat of a reputation for longer than projected release times. What do you plan to do as DPL to help us meet these projections? [22:00]
  136. <AigarsMahinovs> Plan not to release within this year. I feel that 1 release ever 2-3 years is appropriate for Debian. [22:05]
  137. <WouterVerhelst> We've done much better in releasing on a shorter timeframe this time [22:05]
  138. <WouterVerhelst> around (or, well, at least we will), which is a great thing. The reason [22:05]
  139. <WouterVerhelst> this worked out this time around, I think, is because of the excellent [22:05]
  140. <WouterVerhelst> way in which the release managers kept the Developer body up-to-date on [22:05]
  141. <WouterVerhelst> the release progress during the whole release (as opposed to just the [22:05]
  142. <WouterVerhelst> end of the release, when the freeze was near). [22:05]
  143. <WouterVerhelst> . [22:05]
  144. <WouterVerhelst> There are a few things that still could be fleshed out next time; for [22:05]
  145. <WouterVerhelst> instance, I think it would be prudent to try to avoid "surprises", such [22:05]
  146. <WouterVerhelst> as the issues with security buildd hosts we've had for the woody and the [22:05]
  147. <WouterVerhelst> sarge release, and the problems with the kernel we're having now. [22:05]
  148. <WouterVerhelst> Avoiding these will be a challenge, but I'm sure our release managers [22:05]
  149. <WouterVerhelst> are up to it. [22:05]
  150. <WouterVerhelst> . [22:05]
  151. <WouterVerhelst> If required, I will help them wherever I can, but I don't think that'll [22:05]
  152. <WouterVerhelst> be necessary. [22:05]
  153. <AnthonyTowns> I don't expect to do anything to improve release times other than [22:05]
  154. <AnthonyTowns> supporting the release managers however I can. Over the past year, that's [22:05]
  155. <AnthonyTowns> meant trying to give them more time to work on the release by letting [22:05]
  156. <AnthonyTowns> them work on it full-time, increasing the frequency of the incoming and [22:05]
  157. <AnthonyTowns> testing promotion scripts to twice a day, and being available to help [22:05]
  158. <AnthonyTowns> with bug fixing and archive issues. I think it's better to listen to their [22:05]
  159. <AnthonyTowns> suggestions for improving the release schedule/process and help them with [22:05]
  160. <AnthonyTowns> that, as the people most familiar with the current problems we're facing. [22:05]
  161. <RaphaelHertzog> While we haven't met our target release date with etch, we really have an [22:06]
  162. <RaphaelHertzog> active and communicative release team. So, as DPL, I'm ready to discuss [22:06]
  163. <RaphaelHertzog> any issues they encountered and will do my best to avoid those pitfalls [22:06]
  164. <RaphaelHertzog> for lenny. [22:06]
  165. <RaphaelHertzog> . [22:06]
  166. <RaphaelHertzog> I have no big plans on how to handle the lenny release but I know other [22:06]
  167. <RaphaelHertzog> members of my board have a stronger interest (sam in particular). I'm sure [22:06]
  168. <RaphaelHertzog> we'll have some interesting discussions on this topic shortly after the [22:06]
  169. <RaphaelHertzog> release of etch. I'll watch those discussions and be involved as usual. [22:06]
  170. <RaphaelHertzog> But really, the decision is up to the release managers, but since they are [22:06]
  171. <RaphaelHertzog> listening to what we have to say, there's no problem with that. [22:06]
  172. <RaphaelHertzog> . [22:06]
  173. <RaphaelHertzog> The only help I'll bring for the next release maybe with attracting more [22:06]
  174. <RaphaelHertzog> contributors, some of them who will hopefully augment the numbers of [22:06]
  175. <RaphaelHertzog> NMUers for the release... [22:06]
  176. <SamHocevar> This is probably not for the DPL to decide. I would personally [22:06]
  177. <SamHocevar> love a yearly, fixed-date stable release, with a 6-month freeze [22:06]
  178. <SamHocevar> period and an optional "desktop" release/add-on every six months. [22:06]
  179. <SamHocevar> Workforce is a key issue, our package-to-developer ratio has not [22:06]
  180. <SamHocevar> changed a lot since the beginning, and I believe augmenting our [22:06]
  181. <SamHocevar> number of developers (as explained in my platform) would help [22:06]
  182. <SamHocevar> meet this goal. This is ultimately for the Release Managers to [22:06]
  183. <SamHocevar> decide and though I'd try as a DPL to weigh in the discussion [22:06]
  184. <SamHocevar> towards having such a goal, it's not something I'd shove down [22:06]
  185. <SamHocevar> their throat if they found it unrealistic. [22:06]
  186. <SteveMcIntyre> Release timing is a place where the DPL does not necessarily [22:06]
  187. <SteveMcIntyre> have a huge amount of influence. The main point here IMHO is [22:06]
  188. <SteveMcIntyre> to come up with a reasonable set of release goals and timings [22:06]
  189. <SteveMcIntyre> and get people to agree to them. The trick then is to actually [22:06]
  190. <SteveMcIntyre> get people to work towards those goals; that's admittedly [22:06]
  191. <SteveMcIntyre> easier said than done. Consensus is good here. [22:06]
  192. <SteveMcIntyre> . [22:06]
  193. <SteveMcIntyre> Also, tracking the release work for the [22:06]
  194. <SteveMcIntyre> entire period rather than just towards the end - that has been [22:06]
  195. <SteveMcIntyre> a major improvement in the Etch release cycle compared with [22:06]
  196. <SteveMcIntyre> Sarge, and something I applaud in the release team. That doesn't [22:06]
  197. <SteveMcIntyre> need much from the DPL... [22:06]
  198. <don_armstrong> next question: Did you enter debian through the NM process? Is it relevant? What do you think of it and how would you change it? [22:08]
  199. <AigarsMahinovs> Yes, I entered into Debian via the NM process in September of 2000. The whole thing took around a month because I was replying t the requests very quickly. But the DAM approval took extra 2 weeks. [22:12]
  200. <AigarsMahinovs> NM is relevant and I think it is more or less appropriate, but delays over one year by a DAM however are not. [22:12]
  201. <WouterVerhelst> Yes, I went through the NM process, although the time required to get [22:12]
  202. <WouterVerhelst> through it was at a record low at that time (I signed up in November [22:12]
  203. <WouterVerhelst> 2000, and got my account in February 2001). [22:12]
  204. <WouterVerhelst> . [22:12]
  205. <WouterVerhelst> I think I'm a living proof of why the NM process is necessary. In [22:12]
  206. <WouterVerhelst> hindsight, I don't believe I was fully ready to become a DD when I did; [22:12]
  207. <WouterVerhelst> to get good results, I probably should've waited a bit longer. As it [22:12]
  208. <WouterVerhelst> happened, it was all okay in the end, but there was no guarantee that [22:12]
  209. <WouterVerhelst> this would happen. [22:12]
  210. <WouterVerhelst> . [22:12]
  211. <WouterVerhelst> Getting NM "quicker" or "faster" or whathaveyou at the cost of its [22:12]
  212. <WouterVerhelst> quality is not an idea that I endorse. And getting through NM isn't [22:12]
  213. <WouterVerhelst> impossible these days, either; I have been an AM since about a year now, [22:12]
  214. <WouterVerhelst> and am proud to report that my first NM (Lucas Nussbaum) has become a DD [22:12]
  215. <WouterVerhelst> since a few weeks. [22:12]
  216. <WouterVerhelst> . [22:12]
  217. <WouterVerhelst> If people can think of ways to improve it, however, and it is generally [22:12]
  218. <WouterVerhelst> agreed upon that this is indeed an improvement, then I do not see why we [22:12]
  219. <WouterVerhelst> should not implement those improvements; but I don't see possible areas [22:12]
  220. <WouterVerhelst> of improvements myself. [22:12]
  221. <SamHocevar> I entered Debian through the NM process, but it went really [22:12]
  222. <SamHocevar> fast, because (I think) I had already been asked to become [22:12]
  223. <SamHocevar> a DD earlier, and my employer was a Debian old-timer. [22:12]
  224. <SamHocevar> The NM process is a very good test for technical excellence, [22:12]
  225. <SamHocevar> but I don't believe one should need *packaging* excellence [22:12]
  226. <SamHocevar> in order to become a developer: though this would be [22:12]
  227. <SamHocevar> required to get upload access, I'd prefer that NMs who [22:12]
  228. <SamHocevar> work in packaging teams would get developer status earlier [22:12]
  229. <SamHocevar> on, and get upload rights when they complete the skills [22:12]
  230. <SamHocevar> tests. Debian is not just about packaging. [22:12]
  231. <RaphaelHertzog> No, I've not done the NM process in its current form. Joey or Elmo called [22:13]
  232. <RaphaelHertzog> at home, my mum responded and told me: "it must be for you, it's in [22:13]
  233. <RaphaelHertzog> english" (I'm French). Then we chatted two minutes about my package (the [22:13]
  234. <RaphaelHertzog> sympa mailing list manager) and I was approved shortly thereafter. [22:13]
  235. <RaphaelHertzog> . [22:13]
  236. <RaphaelHertzog> The current NM process is certainly far from perfect but it does its job. [22:13]
  237. <RaphaelHertzog> It's constantly evolving, the AM have some liberty in how they conduct [22:13]
  238. <RaphaelHertzog> the process, they must just be sure to prove that the candidate has [22:13]
  239. <RaphaelHertzog> the required skills. And looking at those that have been approved, it's [22:13]
  240. <RaphaelHertzog> the case! [22:13]
  241. <RaphaelHertzog> . [22:13]
  242. <RaphaelHertzog> However we're certainly scaring some contributors away and that's sad. We [22:13]
  243. <RaphaelHertzog> need to have the require infrastructure to let each contributor contribute [22:13]
  244. <RaphaelHertzog> to its own level. We need to create and recognize intermediary level of [22:13]
  245. <RaphaelHertzog> involvement. That's why I like the idea to have packagers who are not DD [22:13]
  246. <RaphaelHertzog> but who can still upload their own packages (once we checked that they are [22:13]
  247. <RaphaelHertzog> able to maintain them correctly). There are things like that in [22:13]
  248. <RaphaelHertzog> preparation. I like the initiative that Holger is [22:13]
  249. <RaphaelHertzog> preparing, etc. [22:13]
  250. <SteveMcIntyre> As mentioned in my platform, I entered Debian before there was [22:13]
  251. <SteveMcIntyre> any kind of NM process. Since then, the NM process has grown [22:13]
  252. <SteveMcIntyre> and become significantly more complex. The question's not as [22:13]
  253. <SteveMcIntyre> clear as it could be here, so I'll answer both versions as I [22:13]
  254. <SteveMcIntyre> see them. I don't think it's relevant that I didn't go through [22:13]
  255. <SteveMcIntyre> NM, as I know lots of people that have gone through it and I've [22:13]
  256. <SteveMcIntyre> helped several with mentoring etc. The NM process is very [22:13]
  257. <SteveMcIntyre> relevant itself - it helps us to decide who we will allow to [22:13]
  258. <SteveMcIntyre> upload to our archive and provide Debian packages directly to [22:13]
  259. <SteveMcIntyre> our users without direct oversight. [22:13]
  260. <SteveMcIntyre> . [22:13]
  261. <SteveMcIntyre> I'd like to push for a more social setup to the NM process. [22:13]
  262. <SteveMcIntyre> At the moment, we have a large number of technical questions [22:13]
  263. <SteveMcIntyre> that are asked, but we don't have much in terms of seeing how [22:13]
  264. <SteveMcIntyre> well candidates will fit in with the rest of us. I see that as [22:13]
  265. <SteveMcIntyre> a problem. [22:13]
  266. <AnthonyTowns> I joined Debian by sending a mail to new-maintainer saying I'd been using [22:13]
  267. <AnthonyTowns> Linux for a couple of years and I was interested in maintaining a package, [22:13]
  268. <AnthonyTowns> got my key signed by a DD who occassionally showed up to my LUG, and got [22:13]
  269. <AnthonyTowns> a phone call from Joey Schulze one Saturday morning. It took a couple [22:13]
  270. <AnthonyTowns> of weeks all up, and I didn't really do anything to "prove myself" until [22:13]
  271. <AnthonyTowns> after I was a DD; which included helping fix RC bugs, trying to provide [22:13]
  272. <AnthonyTowns> useful input to debates on the lists and IRC, and maintaining my packages. [22:13]
  273. <AnthonyTowns> . [22:13]
  274. <AnthonyTowns> There's a lot more interest in Debian now than there was then, so [22:13]
  275. <AnthonyTowns> self-selecting alone probably isn't enough; and beyond that the more [22:13]
  276. <AnthonyTowns> structured training process we have now is useful in and of itself. I do [22:13]
  277. <AnthonyTowns> think there's a lot to be said for giving people more permissions more [22:13]
  278. <AnthonyTowns> easily, though, and I'm currently working on an implementation of the [22:13]
  279. <AnthonyTowns> "maintainers" concept I wrote about last year [0] using Joey Hess's [22:13]
  280. <AnthonyTowns> "jetring" project. [22:13]
  281. <AnthonyTowns> . [22:13]
  282. <AnthonyTowns> [0] [22:13]
  283. <don_armstrong> next question: What is the biggest problem that Debian is facing currently? (Don't restrict yourself to problems that the DPL can solve.) Now that you idenfied it, what can be done to solve it? [22:14]
  284. <WouterVerhelst> I believe the biggest problems we're facing currently are situated in [22:19]
  285. <WouterVerhelst> communication. We don't always communicate very well, which leads to [22:19]
  286. <WouterVerhelst> misunderstandings--or in the worst case, personal vendettas. I've [22:19]
  287. <WouterVerhelst> already explained how I'll work on that in a previous question. [22:19]
  288. <AnthonyTowns> I think Debian's biggest problem for a while now has been finding some [22:19]
  289. <AnthonyTowns> way to take all the people who want to contribute to Debian -- particular [22:19]
  290. <AnthonyTowns> new contributors, but DDs too -- and giving them the encouragement, [22:19]
  291. <AnthonyTowns> support and authority they need to contribute as best they can. The more [22:19]
  292. <AnthonyTowns> ways we can find to help with that, particularly if we can avoid trading [22:19]
  293. <AnthonyTowns> off supporting some contributors against others, the better off we'll be. [22:19]
  294. <AigarsMahinovs> The biggest problem IMHO is that Debian is loosing the WOW! factor both for users and the developers. [22:19]
  295. <AigarsMahinovs> The few ideas in my platform are there to bring back the wow factor for the developers. Smaller specialised teams should be working to bring the wow to specific groups of our users, like Ubuntu does it to _our_ desktop users. ;) [22:19]
  296. <AigarsMahinovs> But seriously, it is hard for one man to come up with something that will wow the rest of the world, it need to be a team effort. [22:19]
  297. <SamHocevar> Debian has become a bunch of old farts who no longer [22:19]
  298. <SamHocevar> find it fun to work on Debian. Not true of everyone, [22:19]
  299. <SamHocevar> of course, but that's my general idea. [22:19]
  300. <SamHocevar> We have grown big but bored, we need to attract more [22:19]
  301. <SamHocevar> users, more developers (in the general meaning of [22:19]
  302. <SamHocevar> developer I have been using; this includes graphists, [22:19]
  303. <SamHocevar> translators, usability people) and instead of insisting [22:19]
  304. <SamHocevar> that newcomers suffer as much as we did, make it easier [22:19]
  305. <SamHocevar> for them to contribute. And we need to stop frustrating [22:19]
  306. <SamHocevar> people who're already here but are prevented to work [22:19]
  307. <SamHocevar> on what they love to do: another thing we need to ban [22:19]
  308. <SamHocevar> is the "better no solution than an imperfect solution" [22:19]
  309. <SamHocevar> spirit. [22:19]
  310. <SteveMcIntyre> The biggest problem that I think we have is social interaction. [22:19]
  311. <SteveMcIntyre> We have problems with flamewars on the lists, various teams and [22:19]
  312. <SteveMcIntyre> people not communicating any more about what they're doing, and [22:19]
  313. <SteveMcIntyre> others seemingly spending more time flaming and mocking other [22:19]
  314. <SteveMcIntyre> people's contributions than actually working on Debian. [22:19]
  315. <SteveMcIntyre> . [22:19]
  316. <SteveMcIntyre> In terms of how to fix that, I think we need to be clear on what [22:19]
  317. <SteveMcIntyre> we're trying to achieve. Those people who don't work with us on [22:19]
  318. <SteveMcIntyre> making Debian the best distro possible and would rather waste [22:19]
  319. <SteveMcIntyre> everybody's time in flaming and insults should be given a clear [22:19]
  320. <SteveMcIntyre> message that that behaviour is not acceptable. We can work on [22:19]
  321. <SteveMcIntyre> that together; the DPL's job here is to push it hard. [22:19]
  322. <RaphaelHertzog> That's a difficult question. We always remember the problems that we [22:19]
  323. <RaphaelHertzog> faced, and in my case, that would be the difficulty to cooperate with [22:19]
  324. <RaphaelHertzog> DSA. However that's certainly not our biggest problem. [22:20]
  325. <RaphaelHertzog> . [22:20]
  326. <RaphaelHertzog> I think Debian lacks a proper identity. We have strong roots with the [22:20]
  327. <RaphaelHertzog> social contract and the DFSG, but it's been a long time since Debian [22:20]
  328. <RaphaelHertzog> positionned itself clearly within the free software movement. Over the [22:20]
  329. <RaphaelHertzog> last years, we only took once a clear decision and that was concerning [22:20]
  330. <RaphaelHertzog> the GFDL problem. [22:20]
  331. <RaphaelHertzog> . [22:20]
  332. <RaphaelHertzog> I think we need to have some more discussions and make public statements [22:20]
  333. <RaphaelHertzog> about where we stand and what we care about. I'll probably push forward [22:20]
  334. <RaphaelHertzog> some position statements for the project, but I'll try to use the DPL [22:20]
  335. <RaphaelHertzog> board for those instead of relying on GR which have proved to be painful. [22:20]
  336. <RaphaelHertzog> That's part of the principle of the discussion by proxy that I want to try [22:20]
  337. <RaphaelHertzog> out. What about an offcial document explaining ho we stand compared to the [22:20]
  338. <RaphaelHertzog> FSF, to Ubuntu? [22:20]
  339. <don_armstrong> next question: Is a code of conduct (ala Ubuntu) needed? If not, why not? If yes, why and what should it contain? [22:21]
  340. <AnthonyTowns> I tried working on a code of conduct by creating the #debian-tech [22:26]
  341. <AnthonyTowns> channel back in 2005, with Steve Langasek, Steve McIntyre and a few [22:26]
  342. <AnthonyTowns> others. That worked okay for a while, particularly for a couple of [22:26]
  343. <AnthonyTowns> scheduled discussions, but hasn't kept alive with active discussion apart [22:26]
  344. <AnthonyTowns> from that. I think there are other things to be tried in this area, [22:26]
  345. <AnthonyTowns> but I'll leave it for other people to try them at this point. [22:26]
  346. <WouterVerhelst> I'm in doubt about this. On the one hand, I'm convinced that the "code [22:26]
  347. <WouterVerhelst> of conduct" which we have right now is a joke; it may have been useful [22:26]
  348. <WouterVerhelst> at the time it was created, but it's horribly outdated today. [22:26]
  349. <WouterVerhelst> . [22:26]
  350. <WouterVerhelst> On the other hand, I feel, as I have before, that actively enforcing a [22:26]
  351. <WouterVerhelst> set of social rules does not help anyone; you'll only be creating [22:26]
  352. <WouterVerhelst> animosity against the rules and/or the people pointing them out when [22:26]
  353. <WouterVerhelst> they are enforced. For a code of conduct to work, people have to /want/ [22:26]
  354. <WouterVerhelst> to follow it. [22:26]
  355. <WouterVerhelst> . [22:26]
  356. <WouterVerhelst> Getting that to happen will require a lot of work; but I don't think [22:26]
  357. <WouterVerhelst> it's impossible. [22:26]
  358. <AigarsMahinovs> A code of conduct should be there, but merely as a recommendation allowing eople to complain about things they do not like, even if those are not in violation of the CoC and at the same time allowing the DPL to allow some things to slide depending on the situation. [22:26]
  359. <AigarsMahinovs> In the end a human factor must be taken in account. By a human. [22:26]
  360. <AigarsMahinovs> The expulsion should however not be achievable via the CoC alone, the current expulsion procedure is much more appropriate. [22:26]
  361. <SamHocevar> I do not believe a code of conduct is needed. General [22:26]
  362. <SamHocevar> guidelines for sure, but a code of conduct means rules, [22:26]
  363. <SamHocevar> and rules mean borderline behaviour, deliberate [22:27]
  364. <SamHocevar> trolling and rule twisting. [22:27]
  365. <SamHocevar> If people quarrel on our mailing-lists, it's because [22:27]
  366. <SamHocevar> they have a reason to. Let's address the reasons instead. [22:27]
  367. <RaphaelHertzog> We already have the Debian Community Guidelines written by Enrico! [22:27]
  368. <RaphaelHertzog> [22:27]
  369. <RaphaelHertzog> It's a very interesting document that one should read. I would like [22:27]
  370. <RaphaelHertzog> to see it promoted during the NM process, and I would like that [22:27]
  371. <RaphaelHertzog> prospective DD try to abide to those basic rules. [22:27]
  372. <RaphaelHertzog> . [22:27]
  373. <RaphaelHertzog> It would be useful to have a shorter summary of the DCG to point people [22:27]
  374. <RaphaelHertzog> to. [22:27]
  375. <RaphaelHertzog> . [22:27]
  376. <RaphaelHertzog> We have a strong history of non-restrained discussions and it's difficult [22:27]
  377. <RaphaelHertzog> to change the habits of everybody. But I think that the project is slowly [22:27]
  378. <RaphaelHertzog> evolving. We already tend to block temporarily the inclusion of NM which [22:27]
  379. <RaphaelHertzog> are causing troubles. We start learning from the problems, let's continue [22:27]
  380. <RaphaelHertzog> on that way. [22:27]
  381. <SteveMcIntyre> I've suggested that a CoC would be useful in the past, and I [22:27]
  382. <SteveMcIntyre> still believe it would be. Simply getting everybody to agree to [22:27]
  383. <SteveMcIntyre> a reasonable base level of conduct would be a very good start [22:27]
  384. <SteveMcIntyre> on the road to cleaning up the atmosphere on our lists and IRC [22:27]
  385. <SteveMcIntyre> channels. [22:27]
  386. <don_armstrong> Thank you everyone for your attention during the first part of the debate; we'll take a short 5 minute break and start with the second section [22:27]
  387. <don_armstrong> they will ask to be recognized in an out of band channel, and I will say their name [22:32]
  388. <don_armstrong> they will then have 1.5 minutes or 5 lines to respond, whichever is shorter. [22:32]
  389. <don_armstrong> I'll then recognize the next candidate [22:32]
  390. <don_armstrong> some questions will have the opportunity for rebuttals; the candidates will indicate to me that they wish to rebut, and I will allow them to on selected questions [22:33]
  391. <don_armstrong> during this process, the candidates will be +v, however, they will refrain from responding unless they are recognized [22:33]
  392. -!- mode/#debian-dpl-debate [+vvvv SimonRichter SamHocevar SteveMcIntyre AnthonyTowns] by don_armstrong [22:35]
  393. -!- mode/#debian-dpl-debate [+vvv WouterVerhelst RaphaelHertzog AigarsMahinovs] by don_armstrong [22:35]
  394. <don_armstrong> Here we go with the first question; (candidates, if I forgot to voice one of you, let me know) [22:35]
  395. <don_armstrong> How do you plan to document your activities as DPL for your fellow developers and the community at large? [22:36]
  396. <don_armstrong> AnthonyTowns [22:36]
  397. <AnthonyTowns> I plan on doing irregular reports to d-d-a as has happened in the past. I think that works fairly well as long as you keep doing new things to write about, or can find other people to encourage to write about the things they're doing. [22:37]
  398. <don_armstrong> SteveMcIntyre [22:38]
  399. <SteveMcIntyre> I plan to make regular-ish posts to d-d-a to summarise things that have been going on in Debian, and things that the DPL has been doing - much like (most of) this last year. [22:38]
  400. <SteveMcIntyre> I also expect to blog about things more often, especially the smaller things that don't necessarily deserve the full hit of an announce posting [22:39]
  401. <don_armstrong> AigarsMahinovs [22:39]
  402. <AigarsMahinovs> For the short term information I think a published iCal file with everything that is being done or being planned, would be a good thing to try. Blogging about anything, including half-baked ideas, projects and concepts for the mid-term information. And regular status reports on d-d-a once every two month even if nothing significant has been done. [22:39]
  403. <don_armstrong> WouterVerhelst [22:40]
  404. <WouterVerhelst> I can only ack what the other candidates have said: I plan to post regularly to d-d-a; I will also, most likely, add a section to my blog for dpl-specific bits that don't warrant a full d-d-a post, but will have to see how that works out [22:41]
  405. <don_armstrong> SamHocevar [22:42]
  406. <SamHocevar> Every DD, not just the DPL, already has the proper tools to communicate about his/her activities: for small everyday reports, debian-devel or debian-project for projects and ideas that require discussion, debian-devel-announce for more synthesised activity reports. This is what I plan to use, I do not need additional tools and the fact that previous DPLs may have used them on an irregular basis does not render them ineffective. [22:42]
  407. <don_armstrong> SimonRichter [22:42]
  408. <SimonRichter> I think creating even more channels would be a bad thing, we already have too many. I think it would be d-d-a postings for larger and blog entries for smaller stuff for me as well. [22:42]
  409. <don_armstrong> RaphaelHertzog [22:43]
  410. <RaphaelHertzog> The DPL board has a public list, so most of the work will be public from [22:43]
  411. <RaphaelHertzog> the beginning. Of course, reports to d-d-a are required. I also like to [22:43]
  412. <RaphaelHertzog> use the wiki for documenting the ideas/projects that I like (see or [22:43]
  413. <don_armstrong> followup question: Many of you talked about posts to d-d-a. This has often been promised in the past, but these posts tend to die out as the term of the DPL continues. What stratagies do you have to make sure you actually make these posts? [22:44]
  414. <don_armstrong> SteveMcIntyre [22:44]
  415. <SteveMcIntyre> I started off reasonably well in the last year doing bits from the 2IC, but lost a little bit of focus towards the end of the year [22:45]
  416. <SteveMcIntyre> It just needs a little more discipline, and I'm happy I can manage that [22:45]
  417. <SteveMcIntyre> if needs be, cron/apt will help :-) [22:45]
  418. <don_armstrong> RaphaelHertzog [22:45]
  419. <RaphaelHertzog> It's difficult to remember everything when you want to communicate on everything you do. [22:46]
  420. <RaphaelHertzog> However there's a simple way to do this, any time that you have something interesting to say, put it up on a wiki page. [22:46]
  421. <don_armstrong> AnthonyTowns [22:47]
  422. <RaphaelHertzog> Once there's enough content to make an interesting post, send it. I setup such a page for the QA group already. [22:47]
  423. <RaphaelHertzog> [EOF] [22:47]
  424. <AnthonyTowns> I don't think we've done too badly at keeping reports going throughout the year -- there's been a lull in the last few months of the year as we've focussed more on the etch release, but that's about it. I think the main thing is to move your [22:47]
  425. <AnthonyTowns> focus to new things once something stalls -- it's no fun writing reports like "I've been working on X, but gotten nowhere with it", and it's often much easier to get past roadblocks when you come back later anyway. [22:47]
  426. <AnthonyTowns> [EOF] [22:47]
  427. <don_armstrong> AigarsMahinovs [22:47]
  428. <AigarsMahinovs> A technical solution to a social problem - a cron job that *will* send the email every two months, 6 text files with a template saying that nothing has been done and I just need to remember to write something good into those files before they are sent. [22:48]
  429. <AigarsMahinovs> A bit of random would help too, so that I would need to update the files as soon as possible fearing that the mail will go off today. [22:48]
  430. <AigarsMahinovs> [END] [22:48]
  431. <don_armstrong> SamHocevar [22:48]
  432. <SamHocevar> If I fail to properly report, I shall offer full reimbursement for your annual Debian subscription and a right to spank me at the next DebConf. [22:48]
  433. <SamHocevar> [END] [22:48]
  434. <don_armstrong> WouterVerhelst [22:49]
  435. <WouterVerhelst> Keeping people up to date on stuff isn't something I have much issues with; I've been singlehandedly managing the Debian presence at FOSDEM for at least three years now, and that's always worked out. [22:49]
  436. <WouterVerhelst> I'd like to add one word about RaphaelHertzog's suggestion about wiki stuff: I don't think that this can be compared to actually pushing information out through d-d-a; wiki's require people to poll them from time to time [22:49]
  437. <don_armstrong> ok; moving on [22:50]
  438. <don_armstrong> Do you believe Debian would benefit from having all packages in version control? If so, how do you think we could get to that point? [22:51]
  439. <don_armstrong> WouterVerhelst [22:51]
  440. <WouterVerhelst> no. It would first spark a flame war about which version control system we're going to use, [22:52]
  441. <WouterVerhelst> then would get people unhappy about the version control system we're actually using, so they'll flame about that, too [22:52]
  442. <WouterVerhelst> I think our current ways work well, and we have for history [22:52]
  443. <WouterVerhelst> perhaps that could be .org'ed, but that's about it [22:52]
  444. <don_armstrong> AigarsMahinovs [22:53]
  445. <AigarsMahinovs> Yes, we could do that in 3-4 years, if we design a version control system for our needs, like Linus did (or make the GIT people adapt theirs) [22:53]
  446. <AigarsMahinovs> I would see branching as a major rethink of the maintaining concept. [22:53]
  447. <AigarsMahinovs> [END] [22:54]
  448. <don_armstrong> SamHocevar [22:54]
  449. <SamHocevar> It would be great, yes, and unlike others so far I don't believe we'd need to decide to use a single version control system for everyone to be happy, we can pretty well work with all the diversity we have on Alioth. (we have been, so far) [22:54]
  450. <SamHocevar> The first step is to have all packages team-maintained to force us using a VCS in the first place. [22:54]
  451. <SamHocevar> [END] [22:54]
  452. <don_armstrong> RaphaelHertzog [22:54]
  453. <RaphaelHertzog> We certainly do benefit from good tols to manage our packages and VCS are [22:55]
  454. <RaphaelHertzog> among them. However each DD has its own VCS preference. But that's not a [22:55]
  455. <RaphaelHertzog> real problem... we can support most of them. We're about to announce the support of mercurial on Alioth, so it completes the existing list: arch, bzr, cvs, svn, git [22:55]
  456. <RaphaelHertzog> Now we needs tools to work in the same way with the various VCS... that's part of ;-) [22:55]
  457. <RaphaelHertzog> [END] [22:55]
  458. <don_armstrong> AnthonyTowns [22:56]
  459. <AnthonyTowns> I think all our packages _are_ in version control simply by our versioning scheme and source packages. It's not very complicated and there's not a lot of metadata, but it does work. I think we can do that better by making past versions more [22:56]
  460. <AnthonyTowns> readily/reliably available, and implementing the "Wig and Pen" changes to the dpkg source format to make the sources we distribute more compatible with the version control systems maintainers/upstream use. I think the main things we need for [22:56]
  461. <AnthonyTowns> that is support in the archive for the multiple patch format, and support for the "Wig and Pen" format in the various cvs-buildpackage programs. [22:56]
  462. <AnthonyTowns> [END] [22:56]
  463. <don_armstrong> SimonRichter [22:56]
  464. <SimonRichter> I agree with Wouter on the flamewar bit; also, it further heightens the learning curve for new maintainers for no real benefit [22:56]
  465. <don_armstrong> SteveMcIntyre [22:57]
  466. <SteveMcIntyre> yes, it will help on most fronts [22:57]
  467. <SteveMcIntyre> to be honest, I think we're already working towards version control for a lot of our packages naturally and therefore I don't think we necessarily need to do anything specific to further it [22:58]
  468. <don_armstrong> NB: For info on the wig and pen format: [22:58]
  469. <don_armstrong> next question: Name your major weak point as a dpl [22:59]
  470. <don_armstrong> AigarsMahinovs [22:59]
  471. <AigarsMahinovs> Crazy ideas and not much of a reputation as an actual programmer I would think. [22:59]
  472. <AigarsMahinovs> [END] [23:00]
  473. <don_armstrong> SamHocevar [23:00]
  474. <SamHocevar> My French humour. But I'm working on that, I already know a few good Irish jokes. [23:00]
  475. <SamHocevar> [END] [23:00]
  476. <don_armstrong> WouterVerhelst [23:00]
  477. <WouterVerhelst> I'm terribly bad at figuring out my own weaknesses... but, well, I'm not too stubborn to ack them when pointed out. [23:01]
  478. <don_armstrong> SimonRichter [23:01]
  479. <SimonRichter> In trying to see "the big picture" I might miss details. [23:01]
  480. <don_armstrong> SteveMcIntyre [23:01]
  481. <SteveMcIntyre> I can be a little too serious sometimes, and when I'm stressed I don't take criticism well - I'm normally enough of a self-critic already... [23:02]
  482. <SteveMcIntyre> [END] [23:02]
  483. <don_armstrong> AnthonyTowns [23:03]
  484. <AnthonyTowns> My biggest difficulties are that my manner can be somewhat abrasive, both accidently and sadly at times deliberately, and that I can forget things that have been brought up while I'm focussed on something else. [23:03]
  485. <AnthonyTowns> [END] [23:03]
  486. <don_armstrong> next question: What do you think of the idea to define a "core" distribution with several other package groups around that (X; Desktop common; KDE; Gnome; ...) in relation to allowing arches to not support certain groups and allowing update during the lifetime of a stable release? [23:04]
  487. <don_armstrong> SimonRichter [23:04]
  488. <SimonRichter> that's two questions [23:04]
  489. <SimonRichter> the first is a technical one - if you can show that it works, it can be done [23:05]
  490. <SimonRichter> (Ian Murdock was working on that BTW) [23:05]
  491. <don_armstrong> SteveMcIntyre [23:06]
  492. <SteveMcIntyre> I'm not sure on the exact details of how to do it, but I think there is some validity to the first part of this [23:06]
  493. <SteveMcIntyre> for example, at the moment we're building numerical analysis packages on arm - that's ridiculous IMHO [23:07]
  494. <SteveMcIntyre> looking into this would be useful [23:07]
  495. <SteveMcIntyre> I'm not sure what the second half is asking - please expand [23:07]
  496. <SteveMcIntyre> [END] [23:07]
  497. <don_armstrong> WouterVerhelst [23:07]
  498. <WouterVerhelst> as an m68k porter, this question hits home. Strange as it might sound to some, I'm not terribly fond of the idea. First, it will complicate our dependencies rather than simplifying them (details by mail, if you want them). Second, compiling 10G worth of software actually is a pretty good way to figure out whether or not your toolchain sucks; and if you've built it, why not upload it anyway? And finally, I've always felt that the decision on [23:07]
  499. <WouterVerhelst> ...what's "useful" should be left to our users, not to us. If someone really, really wants to run KDE on his 68030, who are we to tell them they can't? [23:08]
  500. <don_armstrong> SamHocevar [23:09]
  501. <SamHocevar> We already have that, more or less. It's called base/standard/etc. vs. optional/extra. [23:09]
  502. <SamHocevar> Having more package groups may not be easy, and technology merges between KDE and GNOME (dbus, many freedesktop standards) render it even more difficult. Is GTK part of GNOME or should it be a separate group because of Xfce? [23:09]
  503. <SamHocevar> As I said earlier, I'd be more in favour of releasing more often (a yearly release) with "desktop" upgrades inbetween that would not touch the core. The specifics would need to be discussed, but KDE or GNOME teams could work in experimental and only upload to unstable if their packages are fit for the inbetween release. [23:10]
  504. <SamHocevar> [END] [23:10]
  505. <don_armstrong> AnthonyTowns [23:10]
  506. <AnthonyTowns> Architectures can already choose to support however much or little they want -- they all seem to choose to support as much as possible, and sometimes a little more. As far as release or security support goes, I'd rather see Debian support [23:10]
  507. <AnthonyTowns> everything that gets packaged, if that's possible. [23:10]
  508. <AnthonyTowns> [END] [23:10]
  509. <don_armstrong> AigarsMahinovs [23:10]
  510. <AigarsMahinovs> Theoretically it could be done outside Debian stable update process if we would he the code to allow outside repositories to be added to the buildd queue. So, a group of DDs should be able to create a Debian-woody-Gnome-updates repository. But I would not agree to let some arch release without KDE for example. That would be a path to making such arch even more irrelevant. [END] [23:10]
  511. <AigarsMahinovs> s/he the code/have the code/ [23:11]
  512. <don_armstrong> moving right along to the next question [23:11]
  513. <don_armstrong> actually, RaphaelHertzog [23:12]
  514. <RaphaelHertzog> There's too much in this question. I really would like us to find a way to [23:12]
  515. <RaphaelHertzog> provide some updates for kernels/Xorg once during the stable lifetime. [23:12]
  516. <RaphaelHertzog> I'm not sure that it needs a split in the archive however. [23:12]
  517. <RaphaelHertzog> It's a difficult topic, but we will probably discuss it when we'll discuss release management, because it could be a way to hit the release date... [23:13]
  518. <RaphaelHertzog> [END] [23:13]
  519. <don_armstrong> now really moving to the next question [23:13]
  520. <don_armstrong> Name something, other than releases, that you think a specific other distribution does better than Debian. How could we fix that? [23:13]
  521. <don_armstrong> (After this question, I'm going to ask a few directed questions; I'll give the candidates 2 minutes to respond so they can actually read the question) [23:14]
  522. <don_armstrong> SamHocevar [23:14]
  523. <SamHocevar> Ubuntu is far better than us at doing transitions. We could fix this by having "transition strike teams" who NMU all late packages faster than we currently do. [23:15]
  524. <don_armstrong> WouterVerhelst [23:15]
  525. <SamHocevar> Gentoo is far better at including new ports (OS X, for instance). We could fix this by lowering the requirements for new ports, and only decide later if the arch can be released [23:15]
  526. <SamHocevar> [END] [23:15]
  527. <WouterVerhelst> Ubuntu is doing pretty well in getting mindshare currently, mainly because it's so slick and shiny (in some respects). I think we'll have caught up there by the time etch releases; I recently did an installation of an etch machine, which blew me away in terms of what's changed since sarge. [23:15]
  528. <WouterVerhelst> But other than that, I have always felt that Debian is a great distribution, and the best in most ways. Otherwise, I wouldn't have stuck around :) [23:16]
  529. <don_armstrong> AnthonyTowns [23:17]
  530. <AnthonyTowns> Working Live CDs for Debian instead of having to used derived distros. I think we'll have this for etch, which just means we need to promote them, and keep them working. [END] [23:17]
  531. <don_armstrong> AigarsMahinovs [23:17]
  532. <AigarsMahinovs> Ubuntu is nice at many things, I think we should assimilate them by making it possible to do what they are doing in a way that is inside Debian for some definitions of "inside". Gentoo has the nice ability of adjusting you systems vital parameters (mostly compilation settings) and feel great if it works. It should be possible to make a way to have local packages that are autocompilled forks of the main tree. [23:18]
  533. <AigarsMahinovs> [END] [23:18]
  534. <don_armstrong> SteveMcIntyre [23:18]
  535. <SteveMcIntyre> Ubuntu have done a very good job of getting things like laptop support working [23:19]
  536. <SteveMcIntyre> by pushing changes through at all levels that need them in a short-ish interval [23:19]
  537. <SteveMcIntyre> working together more on that kind of goal should be possible, but we need to agree to do that [23:20]
  538. <SteveMcIntyre> [END] [23:20]
  539. <don_armstrong> RaphaelHertzog [23:20]
  540. <RaphaelHertzog> Everybody said the most obvious already. For my part, what I like in [23:20]
  541. <RaphaelHertzog> Ubuntu is the process of selection of goals for the next release and how [23:20]
  542. <RaphaelHertzog> they document their projects in the wiki. It really helps getting new [23:20]
  543. <RaphaelHertzog> people involved and for everyone to see what they can expect from the next [23:20]
  544. <RaphaelHertzog> release. [23:20]
  545. <RaphaelHertzog> [END] [23:20]
  546. <don_armstrong> we'll have a round of rebuttals, then I'll ask directed questions [23:20]
  547. <don_armstrong> WouterVerhelst [23:20]
  548. <WouterVerhelst> Sam Hocevar mentioned something about Gentoo, that they do pretty well in ports. I don't think that's right; they do have support in their systems for many ports, [23:21]
  549. <WouterVerhelst> but when I tried out a non-standard port once (i.e., not ppc or i386 or some such), I found that most packages couldn't be installed because they were 'masked' [23:22]
  550. <WouterVerhelst> we're doing much better in that respect [23:22]
  551. <don_armstrong> SamHocevar [23:22]
  552. <SamHocevar> I mostly agree with Wouter. [23:23]
  553. <SamHocevar> But that's a problem with Gentoo's QA; the fact that our QA is better should not hinder the fact that our ports do not get proper support early enough. [23:23]
  554. <SamHocevar> [END] [23:23]
  555. <don_armstrong> moving along to directed questions; the candidates will have two minutes to respond. [23:23]
  556. <don_armstrong> Wouter: You mentioned meetings to help team building in your platform: Which teams do you think should meet first? How do you propose to organize the meetings? [23:24]
  557. <WouterVerhelst> That will depend on the teams themselves. I'm not going to shove meetings down people's throats if they don't want them. I will only encourage people to hold them, and help them when they want to hold one. [23:25]
  558. <WouterVerhelst> hence, I can't know which team will be the first to hold a meeting [23:25]
  559. <don_armstrong> Aigars: You mentioned continuing education of developers in your platform: How do you propose to implement that? What have you done so far towards implementing it? [23:25]
  560. <AigarsMahinovs> I have not done anything about it as I am not in position to do that. On the contrary, I myself feel that I would need to refresh on current best practises of Debian development. [23:27]
  561. <don_armstrong> Sam: I noticed that you mentioned that you thought the BTS was ugly, but I don't see any bugs filed by you against either or debbugs. What have you done so far to communicate and/or fix some of the other problems that you've identified in Debian? [23:28]
  562. <SamHocevar> I have grown pretty afraid of the "show the code or shut up" argument. [23:28]
  563. <SamHocevar> I don't mean to say that my suggestions would be met with such responses, though, but I thought I'd rather start working on a PoC before complaining [23:29]
  564. <SamHocevar> I have already started working on lintian.d.o improvements [23:29]
  565. <SamHocevar> and will continue with the BTS once finished with lintian. [23:30]
  566. <SamHocevar> [END] [23:30]
  567. <don_armstrong> Steve: Communication was a common theme in your platform; over the past 12 months when you were 2IC, what were you able to do to help improve communication in Debian? [23:30]
  568. <SteveMcIntyre> I tried to get involved in various teams, so I could help them talk with the rest of the project (not as much as I'd hoped, unfortunately) [23:31]
  569. <SteveMcIntyre> I tried to point out some of the discussions etc going on in the 2IC posts [23:31]
  570. <SteveMcIntyre> mediation work [23:32]
  571. <don_armstrong> Anthony: What was your biggest triumph over the past 12 months? Your biggest mistake? [23:32]
  572. <AnthonyTowns> the thing that pleased me the most was all the things getting freed -- the new GFDL drafts, the new creative commons drafts, and Sun's announcemnet of its intention to GPL Java (and the hints that the GPLv3 will be considered for OpenSolaris for that matter) [23:34]
  573. <don_armstrong> Simon: Could you pick out one of the problems you identified in your platform and describe how you'd attempt to solve it? [23:34]
  574. <AnthonyTowns> (gak, time's up already? i'll reply on list) [23:35]
  575. <SimonRichter> there is only one problem [23:36]
  576. <SimonRichter> subgroups are fighting each other [23:36]
  577. <SimonRichter> any attempt at solving Debian's problems must remove the incentive to fight [23:36]
  578. <don_armstrong> Raphael: What will differentiate your DPL Board from the previous attempts that we've had at them? [23:36]
  579. <RaphaelHertzog> It will have the real DPL powers. [23:37]
  580. <RaphaelHertzog> It won't be a simple board of DPL advisers. [23:37]
  581. <RaphaelHertzog> They'll have to play an active role, making propositions, discussing them and deciding together. [23:38]
  582. <RaphaelHertzog> They will have access to the information that the DPL has via the leader@d.o alias. [23:39]
  583. <don_armstrong> ok; thanks everyone for your responses. We're going to take a 5 minute break here and start up with the cage match in 5. [23:39]
  584. <don_armstrong> for this part the candidates are free to ask eachother questions, as am I; I'll attempt to relay questions asked in real time from the audience to the candidates as well as asking some of the followup questions that didn't get a chance to be answered [23:42]
  585. <don_armstrong> ok; here we go! [23:45]
  586. <don_armstrong> Approximately how much of your time per week will you be able to spend on DPL related tasks? [23:45]
  587. <don_armstrong> SimonRichter: you mentioned incentive to fight; how would you remove it? [23:45]
  588. <RaphaelHertzog> It really depends on my workload, I can spend a whole week doing Debian only stuff (I did that during the python transition) [23:45]
  589. <WouterVerhelst> That first question's been asked on -vote already, I believe [23:46]
  590. <SimonRichter> about four to five hours, travelling time not counted as I generally travel by train which lets me work on other things [23:46]
  591. <SteveMcIntyre> I expect to be able ot spend quite a lot of time on DPL work [23:46]
  592. <SamHocevar> I think this was already asked on -vote; I'd say 3-4 hours a day, more in the weekends, and I can afford to work less if necessary [23:46]
  593. <WouterVerhelst> I'm self-employed currently, which basically means I mostly get to choose my own time schedule :) [23:46]
  594. <AnthonyTowns> don_armstrong: it'll vary wildly, but generally be "as much as it takes". i'm hoping to have more time for other things this year, and i'm hoping more assistant dpls, along with actually knowing what being dpl is like, will help with that [23:46]
  595. <don_armstrong> AnthonyTowns: what obsticals did you encounter trying to make things happen? [23:46]
  596. <don_armstrong> AnthonyTowns: how could they have been overcome? [23:46]
  597. <AnthonyTowns> SamHocevar: what do you believe needs to be done to have transition teams work? There are very few technical restrictions on uploading, and we've already had discussions about this sort of issue in the past. So what more needs to happen for us to have, eg, a team of people doing NMUs to fix kfreebsd build issues? (Cf [23:47]
  598. <SteveMcIntyre> I already spend a lot of time on Debian, and between squeezing that and optionally getting more time released from work I can do a day or two each week on average, obviously squashed together more as demands [23:47]
  599. <WouterVerhelst> I usually spend quite a number of hours per day on Debian-related stuff [23:47]
  600. <SimonRichter> the most important bit is not exactly a DPL task: reading email and having an overview of what is happening; I don't count that into the time required either) [23:47]
  601. <don_armstrong> In what ways do you think Debian can use its resources more effective? [23:47]
  602. <SimonRichter> (as already written on -discuss) to a certain extent, the lack of communication between teams makes goals of different teams appear conflicting; the prime example is the mail asking for newer GNOME to be pushed into etch. [23:47]
  603. <SimonRichter> des, I think the important bit will be identifying these situations and getting a consensus on the best technical solution that is compatible with both team's goals [23:47]
  604. <SteveMcIntyre> Debian's best resources are its people [23:47]
  605. <SamHocevar> AnthonyTowns: we need consensus that these teams are legitimate; we currently rely on LowThresholdNMU to guess whether a maintainer is "NMU-friendly", and we shouldn't have to [23:47]
  606. <WouterVerhelst> SteveMcIntyre: couldn't agree more [23:48]
  607. <don_armstrong> Communications break down, and conflicts can arise. What do you plan to do as DPL to handle the (almost) inevitable conflicts? [23:48]
  608. <SteveMcIntyre> we need to make it easier for people to work together to get things done, with less of the sniping that currently causes people to waste time, or at worst leave [23:48]
  609. <SamHocevar> for instance the kfreebsd-i386 porters would gain legitimacy by having their port accepted in the archive, they have unanswered bugs that are hundreds of days old [23:48]
  610. <don_armstrong> SteveMcIntyre: how can we reduce the sniping? [23:48]
  611. <AigarsMahinovs> SteveMcIntyre: now we only need to figure out 1) how can we get more people and 2) how to use them in the most effective fashion [23:48]
  612. <SteveMcIntyre> we can reduce the sniping as part of a combined effort to raise the quality of our communications [23:49]
  613. <AnthonyTowns> don_armstrong: mostly arguments on the lists, and not being sure i had the moral authority to do things. one example where interminable debate was "overcome" was the sun-java-in-non-free issue, which, after help from Sun in clarifying their issues, it was passed on to SPI's lawyer for an opinion [23:49]
  614. <RaphaelHertzog> If you get people busy with interesting project, they' don't have the time to fight. [23:49]
  615. <don_armstrong> AigarsMahinovs: how do you think we can get more people? [23:49]
  616. <SimonRichter> SteveMcIntyre, indeed, these are related [23:49]
  617. <WouterVerhelst> SamHocevar: I don't think you get legitimacy simply by getting a port in the archive [23:49]
  618. <SteveMcIntyre> as I said earlier, a reasonable minimum base code of conduct will help here [23:49]
  619. <WouterVerhelst> 68k is in the archive too, and has similar problems to kfreebsd-i386 in some regards (obviously not all, since it's still Linux) [23:49]
  620. <don_armstrong> SamHocevar: what do you feel is hindering them from entering the archive? [23:49]
  621. <SimonRichter> SteveMcIntyre, and I disagree on that one [23:49]
  622. <WouterVerhelst> +m [23:49]
  623. <SamHocevar> WouterVerhelst: I think it helps a lot; just because it's not enough doesn't mean it's not worth it [23:49]
  624. <SteveMcIntyre> make it more obvious that most of us do *not* find the sniping funny, or useful for example [23:49]
  625. <RaphaelHertzog> Thus the solution is to help people realize their project... why discuss endlessly if kfreebsd-i386 is worth it when we can add it to the archive and have the numerous members happy to do even more good work ? [23:50]
  626. <AigarsMahinovs> don_armstrong: Ubuntu gets loads of users because of its wow factor. Some of those are bound to become developers. To get more deelopers we need to get more users join the free software community overal and more developers to preffer developing in Debian. [23:50]
  627. <SteveMcIntyre> and also start working out exactly what common goals we really have as a project [23:50]
  628. <WouterVerhelst> SamHocevar: I didn't say we shouldn't put kfreebsd in the archive nor that it wouldn't be worth it; only that it doesn't affect the port's legitimacy [23:50]
  629. <don_armstrong> SteveMcIntyre: what needs to be done to darft the code of conduct? [23:50]
  630. <SamHocevar> don_armstrong: the common "it's not perfect yet so we're better without it" belief that we often use as an excuse for the status quo [23:50]
  631. <don_armstrong> SamHocevar: how do you plan on overcomming that? [23:50]
  632. <SamHocevar> WouterVerhelst: on that precise point I disagree [23:51]
  633. <AnthonyTowns> don_armstrong: we've two major issues with using resources -- keeping track of what's available and what's needed (eg hardware donations, bandwidth/hosting donations, and what people actually need machines to help them with) and feeling authorised to actually use them (eg, i didn't feel comfortable spending debian money to fly myself places to promote debian, so i ended up only authorising smaller flights for toher people) [23:51]
  634. <don_armstrong> AigarsMahinovs: how should we go about getting more developers involved in Debian and keeping them once they're here? [23:51]
  635. <RaphaelHertzog> Of couse, we must take care of problems, but that's something that are solved in a continual basis, not in a "get it right straight the first time" [23:51]
  636. <SteveMcIntyre> if needs be, encourage those that do not agree with those goals to fit in better or (if necessary) leave and work on their own goals separately rather than dragging Debian along [23:51]
  637. <RaphaelHertzog> on this I agree with sam [23:51]
  638. <SimonRichter> SteveMcIntyre, a Code of Conduct is not going to improve communications, rather degrade them by being waved in the faces of people instead of civilly addressing them, [23:51]
  639. <don_armstrong> AnthonyTowns: what should be changed to help us keep track of what is available and what is needed? [23:51]
  640. <WouterVerhelst> RaphaelHertzog: what do you mean with "this"? :) [23:51]
  641. <don_armstrong> Debian receives a generous $10 million dollar donation; what do we spend it on? [23:52]
  642. <SamHocevar> don_armstrong: by making it more difficult for people in position of power to refuse contributions, namely by having their teams grow with "younger" developers less prone to thinking like that [23:52]
  643. <SteveMcIntyre> SimonRichter: no, I disagree; coming up with an agreed *basic* code will help; consider it as encouragement to do the right thing rather than as a stick to beat people woth [23:52]
  644. <SteveMcIntyre> s/woth/with/ [23:52]
  645. <RaphaelHertzog> WouterVerhelst: the fact that we should start first and fix continuously instead of doing nothing [23:52]
  646. <WouterVerhelst> SimonRichter: having an informal code of conduct as a guideline rather than a hard and fast rule will certainly help [23:52]
  647. <don_armstrong> SamHocevar: how will the teams be forced to grow or avoid refusing contributions? [23:52]
  648. <SteveMcIntyre> to draft a code, we will need discussion and consensus; that's (admittedly) not going to be easy [23:52]
  649. <AigarsMahinovs> don_armstrong: Debian need to _again_ become the kind of distro and the kind of community that one would be cool to be part of. Some things taht IMHO could achieve that have been raised here and in my platform, but much more is needed. [23:52]
  650. <AnthonyTowns> don_armstrong: i think (hope) an rt instance will help a little; ultimately we'll need someone willing to volunteer time to keep track of it. kalle kivemaa as debian auditor's been trying to work out what funds are held in debian's name around the world for a few months now, eg -- but it's a hard job [23:52]
  651. <SimonRichter> SteveMcIntyre, I agree; the hard part is how to avoid it being used as a stick [23:53]
  652. <SteveMcIntyre> but I believe/hope that the vast majority of DDs are sensible people who will not object to such a discussion [23:53]
  653. <WouterVerhelst> AigarsMahinovs: how do you view that Debian could lead in cleaning up $HOME? [23:53]
  654. <WouterVerhelst> as opposed to, say, [23:53]
  655. <don_armstrong> SteveMcIntyre, WouterVerhelst, SimonRichter: what should be done about violations of the code of conduct? [23:53]
  656. <SteveMcIntyre> AigarsMahinovs: same Q from me [23:53]
  657. <SamHocevar> don_armstrong: for delegated teams, the DPL has the power to delegate new persons; for other teams I'd like to have the NM process accept people faster if they are in a team [23:53]
  658. <SteveMcIntyre> don_armstrong: to start with, get people to buy in so that we shouldn't get there [23:54]
  659. <don_armstrong> SteveMcIntyre: and beyond that? [23:54]
  660. <RaphaelHertzog> SamHocevar: why haven't you responded to my question on -vote ? :-) [23:54]
  661. <SteveMcIntyre> if we do have violations, then we will need to agree on consequences [23:54]
  662. <WouterVerhelst> don_armstrong: I mostly see a code of conduct as a guideline. When people often don't follow it, that means it sucks [23:54]
  663. <SimonRichter> violations of the CoC must be dealt with on an individual basis [23:54]
  664. <AnthonyTowns> don_armstrong: right now, i would suggest that it not be given to debian directly, but instead spent elsewhere -- eg on a "summer of code" like program that might include debian, or on upstream development, or to employ debian developers, or similar. [23:54]
  665. <SteveMcIntyre> that's something where I don't have a magic answer, I want to get discussion going [23:54]
  666. <WouterVerhelst> SteveMcIntyre: +1 from me :) [23:54]
  667. <SamHocevar> RaphaelHertzog: I haven't yet, I'm still drafting my answers to you and to Ron [23:55]
  668. <AigarsMahinovs> WouterVerhelst: Debian is the only organisation that has enough coverage over the whole range of the free software projects to produce and implement the principles and the code required for the transition. We would need to work with to make sure that what we do become the standard, but I believe that Debian is the only place where this standard could actually be implemented. [23:55]
  669. <SimonRichter> AnthonyTowns, I think people would have less of a problem with dunc-tank if it wasn't perceived as pushing an own agenda [23:55]
  670. <don_armstrong> AnthonyTowns: is that because of our reticence to spend money? or is it that it could just be better spent elsewhere? [23:55]
  671. <SamHocevar> RaphaelHertzog: it's difficult for me to explain why I'm not in favour of a board that I agreed to join if it were to be created [23:55]
  672. <WouterVerhelst> AigarsMahinovs: how are you going to properly deal with the massive amounts of patches that would be required for, say, KDE to implement that? [23:55]
  673. <SimonRichter> AnthonyTowns, for example, I can see that having a group of people coordinate funding development work is a good thing [23:56]
  674. <don_armstrong> what, in all of your opinion, are the weak points of Debian? [23:56]
  675. <SteveMcIntyre> AigarsMahinovs: and how do you expect to convince upstreams to take patches if they don't care about FD ideas? [23:56]
  676. <don_armstrong> WouterVerhelst: should anything be done about the rare failures? If so, what? [23:56]
  677. <SamHocevar> Debian has too much inertia [23:56]
  678. <WouterVerhelst> don_armstrong: we don't have enough focus. [23:57]
  679. <SteveMcIntyre> don_armstrong: we're probably getting too big [23:57]
  680. <WouterVerhelst> don_armstrong: eh, failures of the code of conduct, you mean? [23:57]
  681. <RaphaelHertzog> all of the above at the same time [23:57]
  682. <don_armstrong> WouterVerhelst: yes [23:57]
  683. <SteveMcIntyre> we're spending too much time arguing and bike-shedding rather than getting real work done in a lot of cases [23:57]
  684. <AnthonyTowns> don_armstrong: we don't have the acocunting procedures in place to cope with that much money -- the spi treasurer would have a heart attack for one thing; second, i think we'd have a very hard time actually working out how to spend the money; at present we don't have good procedures to spend money outside the US generally [23:57]
  685. <don_armstrong> SamHocevar, WouterVerhelst, SteveMcIntyre, RaphaelHertzog: what (if anything) can be done to deal with that? [23:57]
  686. <AigarsMahinovs> WouterVerhelst: some technical solutions have been proposed where a temporal measure is put in place while not all patches are implemented. I myself do not now of a technical feasibility of, for example, an LD_PRELOAD library doing this, but smarter coders than me could no doubt figure that one out. [23:57]
  687. <SteveMcIntyre> it's also too easy to miss the sheer amount of good work that is happening quietly every day, because it's lost in the noise [23:58]
  688. <don_armstrong> SteveMcIntyre: is there any good way to bring the good work forward? [23:58]
  689. <AigarsMahinovs> SteveMcIntyre: we do already something similar towards FHS compliance, why not extend the same toward the home folder? [23:58]
  690. <SimonRichter> AnthonyTowns, plus, dealing with that as a non-profit is difficult [23:58]
  691. <SteveMcIntyre> don_armstrong: work on stopping the flamewars, for one [23:58]
  692. <SamHocevar> don_armstrong: more people and more work done; my platform has a lot about that [23:58]
  693. <SteveMcIntyre> also push more of the good work, advertise it [23:58]
  694. <WouterVerhelst> don_armstrong: we should first work towards actually making it rare, by documenting what people actually expect rather than some ideal utopian perfect world we'd like to live in. After that, I expect the problem will mostly solve itself [23:59]
  695. <SteveMcIntyre> the Debian Package of the Day blog is wonderful for that, for example [23:59]
  696. <RaphaelHertzog> exactly, more work done, and more visibility to that work [23:59]
  697. <WouterVerhelst> this will take a long time, though, I'm not even sure a year is enough [23:59]
  698. <AnthonyTowns> don_armstrong: weak points of debian? we're trying large scale, cross-cultural, decentralised, volunteer development. that's not something that's been done before in any field ttbomk, so we're facing problems that people haven't solved before, and that's difficult. [23:59]
  699. <RaphaelHertzog> but I want everybody motivated given a chance, [23:59]
  700. <SteveMcIntyre> AigarsMahinovs: the FHS has mostly been working to get people to use existing locations AFAICS [23:59]
  701. <RaphaelHertzog> and the most motivated are the DPL candidates [23:59]
  702. <SamHocevar> I cannot magically solve the inertia problem; if Debian as a whole doesn't want to change, then it won't, we need enough people who want it to change [23:59]
  703. --- Day changed Sun Mar 11 2007
  704. <RaphaelHertzog> that's why several of them are in the DPL board, they have energy, and I want them to continue on that track [00:00]
  705. <SteveMcIntyre> AigarsMahinovs: the problem is that no such locations have ever been agreed in home-dirs [00:00]
  706. <don_armstrong> If you could name one self-contained thing about Debian that you want to change, and the code to implement that change would just magically appear, what would you name? [00:00]
  707. <SteveMcIntyre> we then get problems in the places where people may want to use Debian alongside other distros/other Unixes using common home dirs [00:00]
  708. <SteveMcIntyre> that's a real problem... [00:00]
  709. <AigarsMahinovs> SteveMcIntyre: the same can be said about moving configuration files into more proper places inside user home folders, and once Debian and agrees on that, I feel that it would have similar weight as the FHS. [00:00]
  710. <RaphaelHertzog> the ability to handle several profiles in our central LDAP [00:00]
  711. <WouterVerhelst> don_armstrong: if it would magically appear? I'd love fixes for all our bugs to magically appear [00:01]
  712. <RaphaelHertzog> so that we could have DD, translators, packagers [00:01]
  713. <RaphaelHertzog> each with their own rights [00:01]
  714. <don_armstrong> WouterVerhelst: heh. one thing. ;-) [00:01]
  715. <don_armstrong> RaphaelHertzog: what is the first step (in your opinion) towards making that happen? [00:01]
  716. <SamHocevar> I must say I agree with RaphaelHertzog: different (incremental?) developers' rights is the way to go [00:01]
  717. <AnthonyTowns> don_armstrong: keyring management, it already happened exactly like that :D [00:01]
  718. <RaphaelHertzog> don_armstrong: for me, learning how to change a LDAP schema :-) [00:02]
  719. <SteveMcIntyre> don_armstrong: I'd love to get the NM thing working better, with an agreed idea of how we should treat maintainers, translators, documentation writers etc [00:02]
  720. <don_armstrong> Comming back to communication: what can be done to work around communication breakdowns? [00:02]
  721. * SteveMcIntyre snaps RaphaelHertzog [00:02]
  722. <WouterVerhelst> don_armstrong: I'd love for Debian to be a place where the boundaries of technology are pushed forward. But that's future dreaming, and I don't think it's relevant in a DPL environment. Most responsibilities for the DPL, as I see it, do not involve much actual coding anyway [00:02]
  723. <RaphaelHertzog> but then we have to discuss this with many teams (ftp-masters, NM) [00:02]
  724. <SimonRichter> SamHocevar, I think the NM process is a bit of a group building process; the initiation ritual (NM) certainly helps people in identifying with Debian. [00:02]
  725. <SamHocevar> don_armstrong: if the magically appearing code was a totally hypothetical question, I'd say every package in the same VCS [00:03]
  726. <SimonRichter> SamHocevar, so I'm not sure there should be too many intermediate steps [00:03]
  727. <AigarsMahinovs> SteveMcIntyre: it could also help to call in some key developers from other distributions, so that the new FHS /home extension can truly become a universal and commony accepted standard that Debian can then put into the policy and start implementing and pushing upstream. [00:03]
  728. <SteveMcIntyre> AigarsMahinovs: maybe, yes; it's a *BIG* job... :-) [00:03]
  729. <AigarsMahinovs> SteveMcIntyre: I fully agree with that [00:03]
  730. <SimonRichter> re: weak points of Debian: we feel a need to compete with other distributions rather than doing what is best [00:03]
  731. <SamHocevar> SimonRichter: I believe one should not wait T&S to become a developer; T&S should only be required for upload rights [00:03]
  732. <SimonRichter> SamHocevar, T&S is the shortest part of NM [00:04]
  733. * SteveMcIntyre nods SamHocevar to a certain extent [00:04]
  734. <don_armstrong> SimonRichter: can you underline an example where we've followed other distributions to compete instead of doing what is best? [00:04]
  735. <SamHocevar> SimonRichter: one (or several, maybe three) advocate, a PGP signature, a commitment to free software, and you're in [00:04]
  736. <SteveMcIntyre> but rather than no T&S, maybe a different/more targeted equivalent [00:04]
  737. <SamHocevar> SimonRichter: what do you mean is the longest part? DAM approval? [00:04]
  738. <SimonRichter> don_armstrong, the discussion of more frequent releases cropping up all the time [00:05]
  739. <RaphaelHertzog> SamHocevar: some history of contribution is still required [00:05]
  740. <AnthonyTowns> *: As DPL you're considered a representative of Debian; beyond replying to email, what would you plan to do in that role? Do you think it's a good idea to encourage other people to be viewed as representatives of Debian, and if so, how? [00:05]
  741. <don_armstrong> getting back to the $10M donation question, which only Anthony answered: if a sizeable donation was made to Debian, how would you spend it? [00:05]
  742. <WouterVerhelst> SamHocevar: you're forgetting P&P, which is what most NM's spend most time in (for the parts they are part of the delays, at least) [00:05]
  743. <RaphaelHertzog> otherwise you have the "I want a @d.o email" syndrom [00:05]
  744. <SimonRichter> SamHocevar, P&P [00:05]
  745. <SteveMcIntyre> don_armstrong: to work around communications breakdowns is difficult [00:05]
  746. <SteveMcIntyre> ideally we don't want to get there in the first place [00:06]
  747. <SamHocevar> ok, don't you believe P&P could be split into P (required to be a DD) and P (required to get upload rights)? [00:06]
  748. <don_armstrong> SteveMcIntyre: any ideas on how to do it, though? [00:06]
  749. <WouterVerhelst> don_armstrong: I've missed that one, I think. If $10M was offered, I'd refuse it. Debian does not need that amount of money, and deciding what to do with it could well mean its death due to the flame wars. [00:06]
  750. <SteveMcIntyre> but when things _do_ fail, then there are ways to work [00:06]
  751. <SteveMcIntyre> moderation to try and get the parties talking sensibly again [00:06]
  752. <don_armstrong> SteveMcIntyre: any ideas on how to identify those sorts of problems earlier on and stop them? [00:06]
  753. <AigarsMahinovs> we could just give the $10M to Ubuntu :) [00:06]
  754. <SamHocevar> does anyone *really* believe the "I want a @d.o email" syndrom is real and commonplace? I for one have never used my Debian address in 7 years [00:07]
  755. <don_armstrong> (nb: please feel free to ask eachother questions too; I'm just a facilitator here) [00:07]
  756. <SteveMcIntyre> work to resolve whatever underlying problems are actually causing the breakdown [00:07]
  757. <SimonRichter> don_armstrong, I think it could be used for travelling costs to build teams; I do see the danger of becoming dependent on that sort of thing though [00:07]
  758. <SteveMcIntyre> and in some cases we maybe just have to acknowledge that some people just won't get on [00:07]
  759. <RaphaelHertzog> SamHocevar: it's not common place, but it happens [00:07]
  760. <SteveMcIntyre> in those situations, we'll have to work out reasonable ways to split them up [00:07]
  761. <don_armstrong> In what ways do you think Debian can use its resources more effectively? [00:08]
  762. <don_armstrong> (I asked it before, but lets come back to it) [00:08]
  763. <SamHocevar> RaphaelHertzog: what would you do if someone in your DPL board grew uninterested or overwhelmed? leave the seat vacant? appoint someone else? [00:08]
  764. <SteveMcIntyre> comms is something that needs to be worked on on a per-case basis [00:08]
  765. <don_armstrong> SteveMcIntyre: who should be responsible for them? [00:08]
  766. <WouterVerhelst> for clarity, I obviously won't refuse all donations, and I will use money on meetings, which is where I think most of our money should go. But 10M is just way too much [00:08]
  767. <AigarsMahinovs> SamHocevar: it is real. Many teenage developers have the need for recognition and getting the DD status and the @d.o email to show that off is a great way to get recognition. [00:09]
  768. <SteveMcIntyre> SamHocevar: yes, I've spoken to many people that seem to want to get into Debian "because it's cool" [00:09]
  769. <RaphaelHertzog> SamHocevar: discuss with him to see, if it's going to last, if he goes completely MIA, we can resort to phone to have some news [00:09]
  770. <SteveMcIntyre> and they'd like the d.o email [00:09]
  771. <SteveMcIntyre> I think it's a good thing to educate those people so they understand better, or even to put them off altogether if necessary [00:09]
  772. <don_armstrong> What do you expect to accomplish (if elected) in the first three months of office? [00:09]
  773. <RaphaelHertzog> SamHocevar: then I would have no problem appointing someone else after discussing with the rest of the board [00:09]
  774. <RaphaelHertzog> but I also expect to have different profiles [00:10]
  775. <AnthonyTowns> RaphaelHertzog: if you win by a landslide, but sam and steve come dead last, even after NOTA, will you uninvite them from the dpl board? [00:10]
  776. <RaphaelHertzog> some will more likely make proposals whiler other will mainly comment [00:10]
  777. <SteveMcIntyre> don_armstrong: in the first 3 months of office, I expect to deliver enough sponsorship money to Debconf to make it work [00:10]
  778. <SteveMcIntyre> (primarily) [00:10]
  779. <SamHocevar> RaphaelHertzog: did you consider having a woman in your board? [00:10]
  780. <RaphaelHertzog> AnthonyTowns: no, they're still only 2 out of 10 [00:10]
  781. <SteveMcIntyre> I also want to get some more of the DAM/DKR/DSA split done that AJ and I have been working on lately [00:10]
  782. <SteveMcIntyre> beyond that, anything's a bonus to be honest [00:11]
  783. <WouterVerhelst> don_armstrong: in the first three months, not much. I expect to get worked in during the first month up to the first month and a half, and expect to get my first results a few weeks or months later [00:11]
  784. <don_armstrong> SteveMcIntyre: can you go into any detail on that split? [00:11]
  785. <don_armstrong> WouterVerhelst: lets say the first 6 months then [00:11]
  786. <SteveMcIntyre> don_armstrong: a little; we're working on ways to help devolve the keyring maintenance work, as mentioned on -project recently [00:11]
  787. <SamHocevar> okay, I'll take your word for it that people actually /do/ want an @d.o address for fame. I'll stick that with the upload rights in my previous comments [00:11]
  788. <RaphaelHertzog> SamHocevar: yes but I have too few contacts with them and none candidated spontaneously [00:11]
  789. <SteveMcIntyre> that should allow people to do the keyring-maint job without needing to be root@ [00:12]
  790. <SamHocevar> RaphaelHertzog: you might want to lurk on #debian-women then [00:12]
  791. <WouterVerhelst> I'm hoping to get the transparency of the project up, and do hope to see the first results of changing culture at that point, too. Other than that, I'm not actually planning to make many radical changes, so... [00:12]
  792. <SteveMcIntyre> ditto, DAM should not need root powers - DAM should talk to to DKR and DSA to control exactly who is a DD [00:12]
  793. <RaphaelHertzog> SamHocevar: I'm in that channel, but well, IRC discussion don't mean much wrt Debian's involvment [00:13]
  794. <SteveMcIntyre> and then DSA should not need to be a gateway, but should be simply popping the changes off the queue as they're needed [00:13]
  795. <WouterVerhelst> RaphaelHertzog: there's a mailinglist, too :) [00:13]
  796. <AnthonyTowns> don_armstrong: by the first six months, i'd like to have some of the assisting dpls actively and visibly working on a project of their own choosing -- something of the scale of the problems people have described in the past as "i haven't done that because i'm not dpl" [00:13]
  797. <RaphaelHertzog> and some women that I appreciated are not (yet) DD too (Meike Reichle for example) [00:13]
  798. <RaphaelHertzog> s/appreciated/appreciate/ [00:13]
  799. <SamHocevar> RaphaelHertzog: but IRC discussions surely are a huge part of Debian's communication channels, aren't they? [00:13]
  800. <don_armstrong> What are the major problems you've all identified in your platforms that you actually have to be DPL to perform? [00:14]
  801. <AigarsMahinovs> SamHocevar: not for casual DDs [00:14]
  802. <SteveMcIntyre> I'm curious what the other candidates think - why have we not had a female DPL candidate yet? [00:14]
  803. <RaphaelHertzog> SamHocevar: yes they are, but you don't to follow 20 channels and 20 lists easily [00:14]
  804. <RaphaelHertzog> I watch #alioth closely, but not #debian-women [00:14]
  805. <WouterVerhelst> to change a culture, you need to be someone that'll be listened to, rather than just one person among a mass of equals. [00:15]
  806. <SamHocevar> AigarsMahinovs: but for many involved DDs, and also many involved NMs, it is [00:15]
  807. <AnthonyTowns> SteveMcIntyre: we haven't had a spanish or an asian candidate either ttbomk; i think it's mostly just demographics [00:15]
  808. <WouterVerhelst> I don't think I'll be able to do much in that regard without having at least some moral authority which an election could get me. [00:15]
  809. <don_armstrong> Will any of you you push to change any of the fundamental documents of Debian? [00:15]
  810. <don_armstrong> (perhaps by adding a code of conduct to them, etc?) [00:15]
  811. <RaphaelHertzog> WouterVerhelst: on this part, I really disagree with you [00:15]
  812. <RaphaelHertzog> we had this discussion on -vote already [00:16]
  813. <SamHocevar> AigarsMahinovs: especially for debian-women, which aims at making Debian more accessible to a part of the population; IRC definitely helps make it more accessible [00:16]
  814. <AnthonyTowns> WouterVerhelst: if you come second, will you feel like you have that moral authority? if you are/aren't an assistant dpl or dpl board member, will that have any effect? [00:16]
  815. <RaphaelHertzog> you can prepare the project for a future direction that you like [00:16]
  816. <RaphaelHertzog> and if that direction is the easiest way to go forward, the project is likely to follow it [00:16]
  817. <don_armstrong> (15 minutes left) [00:16]
  818. <SteveMcIntyre> don_armstrong: I think the communications improvements really need the DPL mandate behind them to get things moving [00:16]
  819. <WouterVerhelst> AnthonyTowns: if I end up second, and the DPL-elect agrees with me, then I probably will have that moral authority, yes [00:16]
  820. <RaphaelHertzog> that's what I did with Alioth and the PTS [00:16]
  821. <AigarsMahinovs> SamHocevar: I am not sure how that works. I for one feel mailing lists to be far more intimidating then mailing lists. [00:16]
  822. <SamHocevar> don_armstrong: I'd like to clarify the "We won't hide problems" in our SC to make it clean that it's not only about bugs in our software [00:16]
  823. <SteveMcIntyre> otherwise, many of my ideas can be done by anyone [00:17]
  824. <AnthonyTowns> WouterVerhelst: if you end up last, but the dpl-elect agrees with you? [00:17]
  825. <WouterVerhelst> Also, being assistant DPL or board member might help. [00:17]
  826. <SamHocevar> AigarsMahinovs: you mean IRC I guess, but I see your point [00:17]
  827. <SteveMcIntyre> the main difference is that if elected I expect to be able to devote more time to them [00:17]
  828. <don_armstrong> How willing are you all to make controversial decisions? [00:17]
  829. <WouterVerhelst> AnthonyTowns: if I end up last (that is, below NOTA, or in close proximity to it), then it's clear that most of the project does not want me to change Debian's culture. Whether the DPL-elect agrees with me doesn't matter at that point, because you can't change a culture if the people making up that culture don't want it changed. [00:18]
  830. <SteveMcIntyre> I don't expect at *this* point to be making any changes to any of the fundamental docs, no [00:18]
  831. <SamHocevar> for instance, developers who wish to leave the project are supposed to do it publicly (as per our Constitution), but they always do it on -private; same for [VAC] messages (I understand there's a privacy issue here, but one should be made aware that a developer is going to be away for a while) [00:18]
  832. <SteveMcIntyre> but that doesn't mean it won't happen - I have no plans, but things can change [00:18]
  833. <WouterVerhelst> don_armstrong: I think controversy should be avoided if/when possible; but in some cases, there's no choice and you *have* to make a controversial decision. [00:19]
  834. <don_armstrong> WouterVerhelst: what can be done to reduce the controversy? [00:19]
  835. <RaphaelHertzog> don_armstrong: I'm not willing to make controversial decisions until I'm convinced that they are the only way forward [00:19]
  836. <SteveMcIntyre> I'm quite prepared to make controversial decisions, but only if they're necessary and (imo) correct [00:19]
  837. <AnthonyTowns> I don't think controversy should be a deciding factor. Often it's possible to resolve disagreements with some sort of compromise, or a more thorough understanding/explanation of the idea. I don't think loudly disagreeing is a good way to contribute in and of itself though -- better to talk quietly and have good reasons, and if you lose the debate sit quietly and wait until you can say "I told you so" later, imo. [00:19]
  838. <AigarsMahinovs> SamHocevar: I assume that vacation field in LDAP is more useful for that - DDs see the reason, non-DDs only see that a developer is away [00:20]
  839. <don_armstrong> (I suppose it depends on the decision, but how in general would you act to reduce it?) [00:20]
  840. <SteveMcIntyre> on most decisions, we're better off getting consensus, but sometime it's difficult to get everybody to agree [00:20]
  841. <SamHocevar> don_armstrong: recent history shows that controversial decisions are a risky move for the DPL; I hope that the election will act as a confirmation that the DPL's platform was consensual [00:20]
  842. <WouterVerhelst> don_armstrong: talk to those people whose opinion makes it a controversial (i.e., who oppose to your idea), and figure out what they'd prefer to see; with that information, try to work towards consensus [00:20]
  843. * SteveMcIntyre nods WouterVerhelst [00:20]
  844. <SamHocevar> AigarsMahinovs: then there is no reason not to mail -devel that one's going to be away, is there? (as far as I remember I have always sent my VAC messages to -devel) [00:20]
  845. <don_armstrong> Ask yourself and answer a question that you wish I'd asked you. [00:21]
  846. <RaphaelHertzog> Since consensus is the best, I want to make it the norm again, and I want to prove with the board, that it's still possible on many topics. [00:21]
  847. <WouterVerhelst> if consensus turns out to be impossible, then either don't force the change through (if possible), or be unhappy at having to be controversial :) [00:21]
  848. <SamHocevar> AigarsMahinovs: asking "is developer X away" is very different from being notified that developer X is away [00:21]
  849. <AigarsMahinovs> don_armstrong: I am willing to make contraversial decisions as long as they are consistent with my pre-election platform - as in I already have the mandate. In other cases I would also go forward and decide things that can be reversed later. [00:21]
  850. <don_armstrong> lets tread deper: What should be done about serious conflicts between developers and/or groups of developers? [00:22]
  851. <AigarsMahinovs> SamHocevar: we could make an Atom stream from that :) [00:22]
  852. <SteveMcIntyre> going back to an earlier Q: large donations... [00:22]
  853. <WouterVerhelst> don_armstrong: the only thing that can be done in case of serious conflicts is "mediation". [00:22]
  854. <don_armstrong> RaphaelHertzog: how will the communications/decisions within the board be documented? Is it going to supplant the cabal? [00:22]
  855. <WouterVerhelst> that isn't easy, however, and often fails, as we've seen this year. [00:22]
  856. <don_armstrong> WouterVerhelst: what to do when it fails? [00:23]
  857. <SteveMcIntyre> given a very large donation, I'd love to be able to make Debconf bigger and pay for more of the DDs to come along [00:23]
  858. <WouterVerhelst> however, I've done some mediations in a debian context, and many of them were actually successful [00:23]
  859. <SamHocevar> don_armstrong: easy answer I know, but maybe avoid serious conflicts in the first time? :) [00:23]
  860. <RaphaelHertzog> don_armstrong: I expect most decisions to be made on the public list [00:23]
  861. <WouterVerhelst> don_armstrong: try again. if they continue failing, nothing can be done. [00:23]
  862. <don_armstrong> RaphaelHertzog: -project? [00:23]
  863. <RaphaelHertzog> the board is not a cabal, it's a team with members from many cabals (ftpmasters, french cabal, RM, ... ;-)) [00:24]
  864. <don_armstrong> 5 mintues [00:24]
  865. <WouterVerhelst> you can't force people to work together; and while expelling one of the parties is always possible, that inherently means you put the blame at one side of the argument [00:24]
  866. <WouterVerhelst> which never is fair [00:24]
  867. <AigarsMahinovs> don_armstrong: Only when a controversial decision is to be made that can not be reversed later I would do what I can to delay the decision and seek more consultations. However IMHO DPL must be decisive and not ask a committee or the whole project what to do in every case and situation. However he must also be prepared to deal with the fallout of his decisions. [00:24]
  868. <RaphaelHertzog> the board should be a communication backbone for the project :-) [00:24]
  869. <SteveMcIntyre> don_armstrong: if we get serious conflicts, then we try to mediate [00:24]
  870. <SteveMcIntyre> if that fails altogether, then (as I said earlier) we try to defuse by keeping people apart [00:25]
  871. <don_armstrong> Will users have any capability in the decision taking of Debian or are DD the only one that have this responsability? [00:25]
  872. <RaphaelHertzog> don_armstrong: nope, not -project, a public list but restriect to the members for posting [00:25]
  873. <SimonRichter> if possible, yes [00:25]
  874. <don_armstrong> SimonRichter: how? [00:25]
  875. <WouterVerhelst> SteveMcIntyre: you've done a mediation attempt between Sven and Frans this year, but it failed. Can you name the reasons why they failed, and do you think you could do better if you were to try again? [00:25]
  876. <WouterVerhelst> (if answering that requires you to say things that were said in private, then no need to answer it) [00:25]
  877. <SteveMcIntyre> WouterVerhelst: we tried to mediate, but civil conversation broke down [00:26]
  878. <AigarsMahinovs> It is very common in conflicts that what people really want to achieve is not too controversial and both positions could be met if both agreed to cooperate. [00:26]
  879. <SteveMcIntyre> when the people involved do not even respect the mediatiors, then things are going nowhere [00:26]
  880. <AigarsMahinovs> that is true and little can be done about that [00:26]
  881. <AnthonyTowns> *: do you think "developers" means coders/hackers, or covers other contributions like translating, graphics, etc? what about user support or promotion? [00:26]
  882. <SamHocevar> one serious issue with Sven and Frans was the language; I don't want to minimise the impact of Sven's words, but the translation to English sure helped things escalate [00:27]
  883. <SimonRichter> don_armstrong, giving a formal vote to nonmembers is difficult, but I can see some sort of "informal straw poll" or "request for comment" mails going out where users would get their say, too [00:27]
  884. <don_armstrong> AnthonyTowns: how should we get more users involved? [00:27]
  885. <SteveMcIntyre> if trying mediation again in a similar situation, I would make it 100% clear up front that abusing the mediators would immediately terminate the discussion [00:27]
  886. <AnthonyTowns> (I think all of those are "developers", but it seems a lot of people, at least in .au think "developer" excludes those poeple) [00:27]
  887. <WouterVerhelst> AnthonyTowns: I think "Developers" in a Debian context can mean anything that eventually can only be done through uploading some package [00:27]
  888. <WouterVerhelst> so people translating, writing documentation, etc., can all be Developers IMO. [00:28]
  889. <don_armstrong> 2 minutes [00:28]
  890. <AnthonyTowns> WouterVerhelst: (we've had at least one person become a debian developer in order to help maintain mirroring stuff, which isn't uploading packages) [00:28]
  891. <WouterVerhelst> user support is a different matter, [00:28]
  892. <RaphaelHertzog> development is a generic term for growth at least in french, so I have no problem to continue using the term DD to emcompass other profiles [00:28]
  893. <don_armstrong> SimonRichter: how do you think that kind of poll should be implemented? [00:28]
  894. <SamHocevar> I believe in the same definition of a "developer" as WouterVerhelst [00:28]
  895. <SimonRichter> AnthonyTowns, I think everyone who is a DD should know basic things like packaging [00:28]
  896. <WouterVerhelst> AnthonyTowns: okay, so I missed infrastructure then :) the point that I have really is that anything that helps Debian forward can be seen as "Developer" [00:28]
  897. <AigarsMahinovs> In my mind developers=maintainers and so far have not had enough reasons to reconsider that. [00:28]
  898. <AnthonyTowns> don_armstrong: i don't know. holger's debian-community project, jvw's unofficial forums, and local conferences are good ways, but i expect we could do orders of magnitude better at it [00:29]
  899. <don_armstrong> 1 minute [00:29]
  900. <WouterVerhelst> and while helping users use Debian is valuable, it's not actually the same thing as helping Debian grow. [00:29]
  901. <SamHocevar> if we're trying to create something like the "big players" we cannot do it only with hackers [00:29]
  902. <SteveMcIntyre> don_armstrong: users of course have some say in how Debian works [00:29]
  903. <SteveMcIntyre> our lists are open by default, and many of our ideas come from users [00:29]
  904. <SteveMcIntyre> and of course that's where we get new DDs too [00:29]
  905. <don_armstrong> ok; thanks everyone [00:30]
  906. <SteveMcIntyre> there's nothing magic about being a DD there [00:30]
  907. <AnthonyTowns> don_armstrong: on the other hand, i think having users be contributors -- in whatever way they can, big or small, technical or not -- is even more important both for debian and free software in general [00:30]
  908. <don_armstrong> we're going to stop here and the candidates will have 8 minutes to write a closing statement [00:30]
  909. <SimonRichter> don_armstrong, some web page with buttons, or a special mail alias where opinions would be collected. The former could possibly be attacked, but asks for only a few seconds of everyone's time so it could provide some insight when we are interested in how a certain thing is perceived. [00:30]
  910. -!- mode/#debian-dpl-debate [-vvvv AnthonyTowns SimonRichter SteveMcIntyre WouterVerhelst] by don_armstrong [00:31]
  911. -!- mode/#debian-dpl-debate [-vv SamHocevar AigarsMahinovs] by don_armstrong [00:31]
  912. <don_armstrong> while they're doing that, I'd like to first thank the candidates for volunteering to serve as DPL [00:31]
  913. <don_armstrong> all of the candidates this year have presented some interesting ideas, and I hope that even those who are not elected work to get them implemented [00:32]
  914. <don_armstrong> Next, thanks to MJ Ray (slef) and Neil McGovern (Maulkin) for assisting me behind the scenes in collecting questions for the debate [00:32]
  915. <don_armstrong> please feel free to ask the candidates to followup to questions that you identified in the debate on, esp. if I wasn't able to ask your question [00:33]
  916. <don_armstrong> Finally, thanks to the audience and those who e-mailed me questions for participating; remember to vote when the polls openn [00:34]
  917. -!- mode/#debian-dpl-debate [-v RaphaelHertzog] by don_armstrong [00:35]
  918. <don_armstrong> The logs from this (and the other channels) will be made available on -vote for your perusal [00:36]
  919. <don_armstrong> The bots will start pasting the closing statements in a few moments [00:39]
  920. <SteveMcIntyre> Thanks to all the candidates, the moderators and all the people [00:40]
  921. <SteveMcIntyre> posing questions. I hope that we've done a good job of answering [00:40]
  922. <SteveMcIntyre> those questions. If there is any more clarification needed on [00:40]
  923. <SteveMcIntyre> some points, please ask us on debian-vote in the next week [00:40]
  924. <SteveMcIntyre> before voting opens. [00:40]
  925. <SteveMcIntyre> . [00:40]
  926. <SteveMcIntyre> Thank you in advance to any DDs that may vote for me. I believe [00:40]
  927. <SteveMcIntyre> I could do a good job as the DPL, as stated in my platform and [00:40]
  928. <SteveMcIntyre> elsewhere. So could many of the other candidates - it's been [00:40]
  929. <SteveMcIntyre> great to see that they all want to work for Debian and have lots [00:40]
  930. <SteveMcIntyre> of ideas on what they could do. [00:40]
  931. <SteveMcIntyre> . [00:40]
  932. <SteveMcIntyre> Please remember to vote! [00:40]
  933. <AnthonyTowns> Thanks to Don, slef and Maulkin for hosting. I don't have anything to add [00:40]
  934. <AnthonyTowns> to what I've already said -- if you've got other questions, please ask [00:40]
  935. <AnthonyTowns> them on -vote. Thanks for coming and your interest in Debian's future :) [00:40]
  936. <SamHocevar> Well, I'd like to thank everyone for taking the time to listen, for organising the debate, and for taking part in it. [00:40]
  937. <SamHocevar> I know that because of my Q4 2006 history of humourous (and sometimes tactless) planet.d.o entries many DDs believe I am this year's joke candidate. I'd like to stress again that I am not, and that I regret hurting the people I hurt. [00:40]
  938. <SamHocevar> I wish luck to everyone in these elections. And if you don't like me as a person, I suggest you have a look at Gustavo Franco's platform! [00:40]
  939. <WouterVerhelst> I'd like to thank Don Armstrong for running the DPL debate. Although [00:40]
  940. <WouterVerhelst> this type of thing really isn't my cup of tea, I must say he's done a [00:40]
  941. <WouterVerhelst> hell of a job. Some people have previously expressed confusion at my [00:40]
  942. <WouterVerhelst> lack of detail about what I'll be doing once elected, and I've tried to [00:40]
  943. <WouterVerhelst> provide a bit more detail during this debate. I hope that worked out [00:40]
  944. <WouterVerhelst> well. [00:40]
  945. <WouterVerhelst> . [00:40]
  946. <WouterVerhelst> I think it's been interesting to somewhat directly talk to the other [00:40]
  947. <WouterVerhelst> contestants about the ideas they had for Debian; in some cases, this has [00:40]
  948. <WouterVerhelst> led me to better understand their motives in joining the DPL race, and [00:40]
  949. <WouterVerhelst> to better understand what they plan to do. If I'm elected, this will [00:40]
  950. <WouterVerhelst> also help me to better decide whom to talk to when the project faces an [00:40]
  951. <WouterVerhelst> issue that is close to what one of the other candidates suggested -- [00:40]
  952. <WouterVerhelst> which I entirely plan to do. [00:40]
  953. <WouterVerhelst> . [00:41]
  954. <WouterVerhelst> I'd also like to thank the other candidates for running, and the [00:41]
  955. <WouterVerhelst> audience for listening; I regret not being able to stay longer, though [00:41]
  956. <WouterVerhelst> -- it's 1:30 AM over here, and I'm starting to get sleepy; but I'll [00:41]
  957. <WouterVerhelst> happily answer any questions you still might have on the debian-vote [00:41]
  958. <WouterVerhelst> mailinglist. [00:41]
  959. <AigarsMahinovs> Debian is slowly losing its ground and something needs to be done to get more users to Debian in order that more of them would become developers and to get more non-Debian developers come and help us. We need to do something to bring the cool back into Debian. [00:41]
  960. <AigarsMahinovs> If I am elected, I will do all in my power to allow Debian as a project to take a step back, relax and think big on what we as a project what to do in the next 5-10 years. The concepts in my platform are only that, concepts - they can be done and can be very useful for all of us and to the Free [00:41]
  961. <AigarsMahinovs> ..Software movement in general. However even more creative thinking would be needed from the rest of the community to really get us going. [00:41]
  962. <RaphaelHertzog> First, I'd like to thank everybody who survived 3 hours of intense IRC [00:41]
  963. <RaphaelHertzog> discussions. ;-) Some difficult questions have been asked, all candidates [00:41]
  964. <RaphaelHertzog> could respond and we had no flames. We have no magic solutions either. [00:41]
  965. <RaphaelHertzog> But it's a proof that we can discuss things sanely if we're in a limited [00:41]
  966. <RaphaelHertzog> set of persons, and given more time I'm sure that we would be able to find [00:41]
  967. <RaphaelHertzog> out good compromise on important points. [00:41]
  968. <RaphaelHertzog> . [00:41]
  969. <RaphaelHertzog> important problems that hinder my work and the work of people around me [00:41]
  970. <RaphaelHertzog> and we'll discuss between reasonable people what we can do about them. [00:41]
  971. <RaphaelHertzog> We'll find solutions, because despite all the ramblings, we all want the [00:41]
  972. <RaphaelHertzog> best for Debian. And if you engage a discussion with this in mind, then [00:41]
  973. <RaphaelHertzog> you're likely to get positive results. [00:41]
  974. <RaphaelHertzog> . [00:41]
  975. <RaphaelHertzog> Of course, this needs to a choice of the whole project, and that's why I [00:41]
  976. <RaphaelHertzog> ask you to vote for me and my board. Why not get 4 DPL candidates (and 4 [00:41]
  977. <RaphaelHertzog> motivated people with complementary goals) for the price of one? :-) [00:41]