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> alioth.debian.org 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] http://lists.debian.org/debian-project/2007/02/msg00204.html [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 debian-community.org 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] http://azure.humbug.org.au/~aj/blog/2006/04/12 [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> http://people.debian.org/~enrico/dcg/ [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: planet.debian.org 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 wiki.debian.org/CRMI or wiki.debian.org/CollaborativeMaintenance). [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 snapshot.debian.net 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 wiki.debian.org/CollaborativeMaintenance ;-) [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: http://lwn.net/Articles/139811/ [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 bugs.debian.org 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 http://lists.debian.org/debian-project/2006/07/msg00240.html) [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, freedesktop.org? [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 FD.org 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 FD.org 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 leader@debian.org 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 wi