Stratus debate 2007

  1. <stratus> hi slef :-) [14:04:15]
  2. <slef> hi stratus - what's happening? [14:04:53]
  3. <stratus> the things are calm now [14:05:53]
  4. <slef> do you want to answer the debate questions, not bother, or give it a few minutes to see if anyone else returns? [14:07:23]
  5. <stratus> I prefer to answer the debate questions now, i'll lunch in one hour and after that i'll be back here to answer more questions if anyone else show up. [14:08:46]
  6. <slef> Shall I try to ask them, so the logs make more sense? [14:09:01]
  7. <stratus> yes, please. [14:09:12]
  8. <slef> Please give us a brief introduction of yourself, and tell us why you are running for DPL this year. [14:09:21]
  9. <stratus> I'm Gustavo Franco and I've been contributing to the Debian project since 2001, I'm also working on a custom Debian distribution called Sacix in a brazilian NGO - a more detailed introduction is available in my platform. I'm running for DPL because I've enough motivation and support to cover every topic included in my platform. [14:12:18]
  10. <slef> 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? [14:20:24]
  11. <stratus> I can't force people to communicate nor i can force people to do volunteer work, but i plan to address our communication problems with the people that actually wants to work and cooperate with more face to face meetings. [14:22:25]
  12. <stratus> Elected or not, I'll push the ombudsman team forward for a better user<->maintainer communication. [14:22:51]
  13. <stratus> The inter/intra-team communication with face-to-face meetings as i wrote above. [14:23:15]
  14. <stratus> [END] [14:23:23]
  15. <slef> 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? [14:23:28]
  16. <stratus> I'm committed to the idea that Debian will be released when it's ready, but we've diverged on what ready really means during our development cycle from time to time. I want to define with the release managers and related teams what we mean with 'ready' right after we release Etch. More details on my 'release goal based schedule' that i wrote in my platform. [14:25:47]
  17. <stratus> [END] [14:25:50]
  18. <slef> Did you enter debian through the NM process? Is it relevant? What do you think of it and how would you change it? [14:25:54]
  19. <stratus> Yes, I did. It is really important but can be improved as many other areas in the project. I need to do something to change this, i suffered with the long DAM wait (more than 2 years). I want to change it working around the single point of failure, bringing Joerg Jaspert not only full DAM privileges but delegating to him the keyring management. He is being more active and responsive than James Troup, and if we can't come up with a solution [14:29:13]
  20. <stratus> on how two people can handle the keyring in a one year I'm all for temporarily let only the most active handle it. [14:29:14]
  21. <stratus> This is far from the best solution though, I would prefer to address the problem with both James and Joerg able to deal with the keyring though. [14:29:34]
  22. <stratus> Since I'm not a dictator I'll discuss with them these points, if elected. [14:30:02]
  23. <stratus> [END] [14:30:03]
  24. <slef> 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? [14:30:09]
  25. <stratus> Ubuntu. Ubuntu is like a friend that gained more attention than you in the school when you were distracted with others things (endless discussions?!) and you're sure that you should be the one to receive that attention. It started all sort of side effects from 'they don't contribute back to us' to 'we hate them, they're not our friends', including 'is Debian still relevant?'. I think that to solve the "Ubuntu problem" we need to cooperate m [14:35:43]
  26. <stratus> ore with them to turn the last Ubuntu release obsolete (for both desktop and servers) every time Debian releases. They release two times a year, so they will be a step ahead of us for some, but for others that doesn't need the latest features or something sid based Debian will stll be better, for both servers and desktops. Keeping in mind that we support more architectures. [14:35:43]
  27. <stratus> once we work with that in mind, i think we will have less flamewars and the atmosphere will be better for real work [14:36:33]
  28. <stratus> [END] [14:36:35]
  29. <slef> Thank you for your attention during the first part of the debate^Winterrogation; do you want to take a 5-minute break, or carry straight on? [14:36:38]
  30. <stratus> no need to break, let us carry on [14:37:13]
  31. <slef> How do you plan to document your activities as DPL for your fellow developers and the community at large? [14:37:15]
  32. <slef> (These are shorter questions and you can skip them if you want - not all candidates answered all questions IIRC.) [14:37:43]
  33. <stratus> I've started a shared Google Calendar (already published on my blog) that I'll maintain updated, in the calendar you can see that I plan monthly bits from DPL. I'll also blog about my activities. [14:38:46]
  34. <stratus> [END] [14:38:49]
  35. <slef> Some candidates talked about posts to d-d-a. Do you plan to use them? This has often been promised in the past, but these posts tend to die out as the term of the DPL continues. What strategies do you have to make sure you actually make these posts? [14:39:14]
  36. <stratus> Yes, I do. My strategy is organize my tasks as DPL around the monthly 'bits from DPL' schedule to always have something to write about. [14:40:26]
  37. <stratus> [END] [14:40:29]
  38. <slef> 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? [14:40:38]
  39. <stratus> I don't think it should be a requirement for one (or just a few) package maintainers, but that's what we've with larger projects actually. It wouldn't be interesting enforce this policy during my term. [14:42:45]
  40. <stratus> [END] [14:42:47]
  41. <slef> Name your major weak point as a dpl [14:42:50]
  42. <stratus> Since i was never DPL I'm not sure, but maybe it's the fact that I'm not a English native speaker and live in South America (Brazil), but I plan to address this problem, specially due to the fact that it would be expensive travel to Europe too many times during my term delegating some tasks to a 2IC. [14:45:11]
  43. <stratus> [END] [14:45:12]
  44. <slef> 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? [14:45:20]
  45. <stratus> I like the idea, but it isn't something we can do in a one year during my term, with the risk to lost track of a Lenny release anytime soon. I would prefer to see a custom Debian distribution going this way and we evaluate with the technical committee and release managers the results. I don't think that Progeny had good results with this though, but maybe it was a failure to building a community around the componentized linux than the techn [14:49:19]
  46. <stratus> ical concept itself. [14:49:19]
  47. <stratus> [END] [14:49:21]
  48. <slef> Name something, other than releases, that you think a specific other distribution does better than Debian. How could we fix that? [14:49:28]
  49. <stratus> Ubuntu promotes itself better; does more face to face meetings, online meetings and has a better overall atmosphere for newcomers. I think that a lot of people in Debian already learned with their lessons but many still prefer to discuss and show our weak than our success and interesting aspects. Some topics in my platform address these problems, including the publicity, 'alioth' - our gforge setup, the vendors and more. [14:53:01]
  50. <stratus> [END] [14:53:02]
  51. <slef> Gustavo: Your platform has a lot of interesting ideas in it, but it seems that a lot of them are outside the areas that previous DPLs have been able to influence. How do you plan to get the core teams to buy in and get your ideas implemented? [14:53:07]
  52. <stratus> Great question. My plan is talk with the core teams a lot and not being part of them put me in a more common position (as a regular DD), but being the DPL I've the bless of many of these regular DDs. I'll be their voice with the core teams and i want to fill the gap between "DDs" and "core teams" with work from both sides. [14:57:25]
  53. <stratus> [END] [14:58:02]
  54. <slef> OK; thanks for your responses. The next bit was the open discussion, which won't work so well with only two. Do you want to continue now for 10 or so, or break and see whether more people arrive? [14:58:04]
  55. <stratus> You're welcome and thanks for coming here. [14:58:55]
  56. <SynrG> well, i'm here and reading with interest :) [14:59:09]
  57. <stratus> I would prefer have a break, I'll need to leave the room to lunch in some minutes. [14:59:20]
  58. <slef> SynrG: want to join in? [14:59:26]
  59. <stratus> SynrG: :-) hey! [14:59:30]
  60. <slef> when will you return? [14:59:35]
  61. <SynrG> good luck herding cats. what are the areas a DPL actually *can* influence? [14:59:36]
  62. <stratus> slef: in 1hr aprox. [14:59:56]
  63. <stratus> SynrG: is this a question for me? [15:00:02]
  64. <slef> SynrG: can I tell you later, to avoid showing stratus any more of my hand? [15:00:02]
  65. <SynrG> heh [15:00:13]
  66. * stratus hides [15:00:18]
  67. <slef> stratus: ok, I need to pop out... I'll try to be back in an hour [15:00:29]
  68. <SynrG> stratus: actually, no, slef implied there are areas DPLs can influence [15:00:31]
  69. <stratus> slef: thanks. [15:00:36]
  70. <SynrG> stratus: i gather, since you're running, you believe there are some [15:00:39]
  71. <slef> SynrG: hey, not my questions! [15:00:43]
  72. <stratus> SynrG: yes, there are many areas. [15:00:54]
  73. <stratus> see you in 1hr [15:00:59]
  74. <stratus> bbl [15:01:00]
  75. -*- lines trimmed [15:01:00]
  76. <stratus> slef: ok, i'll wait you but i'm open for question fron SynrG and pusling too. [16:29:38]
  77. * pusling didn't come here for the dpl-debate - but is one of the regular citizens. [16:29:44]
  78. <SynrG> i don't know what to say ... i just want debian to be a happy place. and i want a DPL who has the best chance at helping debian make that happen [16:29:58]
  79. <SynrG> but it largely depends on debian *wanting* to make that happen, and actually working to get there [16:30:10]
  80. <SynrG> and no DPL can *make* debian do that [16:30:22]
  81. <SynrG> stratus: so, how do you think you can best influence debian towards that end? [16:30:49]
  82. <stratus> SynrG: The DPL can't do that alone right, but what the past DPLs did for a better development atmosphere? Not that they did nothing, some of them did a lot technically, but it isn't enough. [16:32:00]
  83. <pusling> stratus: I have seen most of the other candidates doing 'bad things' all over debian (blogging negative about release team, dunc-tank, being arrogant and stupid, arguing over vancouver, ...) - but I haven't noticed anything from you. What can I expect ? [16:32:09]
  84. <stratus> SynrG: I'm all for face to face meetings, online meetings and work rather than endless discussion without real work being done. [16:32:29]
  85. <stratus> SynrG: See LKML, you will be (almost) ignored if you came up with a great idea. They've enough great ideas, they need code. We need uploads, cooperation and a lot that involves social skills and not only technical skills. We've already enough technical skills. [16:33:12]
  86. <SynrG> that's sensible [16:33:51]
  87. <stratus> pusling: I can't promise that i'll do only 'good things' in your view, but i'll do my best to do things for a better project. I want to bring the fun back. I want to have fun while developing a universal operating system like many others, but i'm motivated to lead some of the changes. [16:34:15]
  88. <stratus> We can't ignore flames all the time, but we can work around almost all of them with real work. This is the first step to a better atmosphere. Releasing there will be no complain about release delays, working and communicating giving updates and people will have no reason to complain about it too. [16:35:46]
  89. <stratus> I want to be DPL to share this driving force we've in the project that feels out of the loop for some weird reason, while the flames seems to be leading us to nowhere. [16:36:27]
  90. <stratus> See, we've alioth, we've and sponsors. That's enough to replicate the aclaimed MOTU process in Ubuntu, for example. Where we lack technically? We don't! The newcomers simple don't know about it. [16:37:34]
  91. <stratus> How many times you see people advocating alioth,mentors and sponsoring on their blogs ? Is it visibile on Debian website ? It isn't! We are failing to communicate how good we are for the right audience. [16:38:54]
  92. <pusling> ..and new maintainers guide. [16:39:41]
  93. <stratus> right, but update our documentation won't be enough [16:40:27]
  94. <stratus> we need this social circle to keep going again [16:40:32]
  95. <stratus> i've already motivated newcomers to write their own documentation from their perspective on how hard or easy it's to get into the Debian project [16:40:54]
  96. <stratus> post it on their blogs, spread the word [16:41:02]
  97. <slef> what can be done to work around communication breakdowns? [16:42:11]
  98. <slef> hello? [16:43:37]
  99. <stratus> slef: which aspect of communication breakdowns? [16:44:00]
  100. <slef> debian to newcomers, but also DD vs DD [16:44:20]
  101. <slef> There seem to be two sorts [16:44:33]
  102. <slef> first, we were saying about how DD disputs spiral [16:44:51]
  103. <slef> but now you've mentioned that the project doesn't communicate things like mentoring and alioth to newcomers [16:45:20]
  104. <stratus> dispute is a good thing, but we're wasting too much resources going nowhere socially or technically, that's the real problem [16:45:41]
  105. <stratus> it would be good if person A came up with a patch for dak to implement all sort of stuff and them somebody reject that with a even better patch [16:46:06]
  106. <slef> and I guess there's another aspect: not all DDs are ubuntu-fanatics... I don't know how MOTU differs from DDship. [16:46:11]
  107. <stratus> that's good you wrote 'ubuntu-fanatics' [16:46:43]
  108. <stratus> I don't think that the Debian-fanatics are driving the Debian project right now, that's the problem, they felt out of the loop. [16:47:06]
  109. <slef> *shrug* I think some people watch ubuntu very very closely [16:47:07]
  110. <slef> I mean nothing insulting by it. [16:47:20]
  111. <stratus> I do and i don't see this a problem, as i'm glad to be informed about others distributions developments and communities by friends. [16:47:53]
  112. <slef> If you were DPL, would you try to encourage people to patch core infrastructure like dak? [16:48:12]
  113. <SynrG> i feel very deeply about debian and am not yet ready to abandon it. i guess you could call me a "debian fanatic" in a sense, and you're right, i do feel "out of the loop". but i have my doubts, at my current level of involvement, about my ability to influence it to change. [16:48:40]
  114. <stratus> Submit patches for core infrastructure and not only vague proposals? Yes, for sure. I'll do my homework with BTS though. [16:49:08]
  115. <slef> How would you handle a) someone complaining that they can't patch infrastructure because it's undocumented or kept on a tight-permission machine? b) a infrastructure maintainer ignoring patches? [16:50:16]
  116. <stratus> SynrG: You've enough influence if during the next development cycle you feel that we're improving and you contribute for a better project. [16:50:17]
  117. <stratus> SynrG: I'm sure you won't do only one upload, but for some that's more than enough. Do one upload and work on to promote Debian to their friends and stuff like that. [16:50:46]
  118. <SynrG> stratus: my work consists of whatever relates to debian jr. this appears to be somewhat "on the fringe" and we haven't really been terribly productive ... but the ideas behind jr and related projects (-desktop, -custom, -live) are all very important [16:51:25]
  119. <SynrG> stratus: for the most part i think it won't be me, but the heavy-duty workers in each of these areas who wield the most influence [16:51:50]
  120. <SynrG> stratus: how can you as DPL help magnify the positive impact these teams have on the rest of the project? [16:52:33]
  121. <stratus> a) I would ask the core team to publish the up-to-date source code (at least) - b) They can disagree with features or the way somebody implemented that, but simple ignore a patch and the DPL isn't acceptable. I'll delegate the task for somebody else in the same team. [16:53:07]
  122. <stratus> SynrG: I think as debian-desktop member i do magnify our influence out of Debian, and as DPL i'll try to replicate our approach in others areas. [16:54:32]
  123. <slef> Will you push to change any of the fundamental documents of Debian? (perhaps by adding a code of conduct to them, etc?) [16:54:47]
  124. <stratus> SynrG: See, i really like the idea and wishes but why not team up with debian-www and work on something like instead? [16:54:57]
  125. <stratus> slef: No, but i'll try to bring more visibility to the code of conduct in mailing lists that exists. I've already opened a bug against lists.d.o asking for its inclusion into the message footers. [16:56:23]
  126. <slef> But you can do that without being DPL. What are the major problems you've identified in your platform that you actually have to be DPL to address? [16:57:12]
  127. <stratus> SynrG: btw, talking about Debian Jr. it lacks promotion and artwork (you know i'm working on this with andre). After Etch release i'll try to push for a more active promotion of our goodies with the press team and debian-publicity mailing lists. [16:57:34]
  128. <SynrG> stratus: it looks to me like there's a lot of energy being brought into the project by new members who are not yet through NM, so that they find they need to work through unofficial channels to make their contributions [16:57:46]
  129. <stratus> slef: Almost all the stuff in my platform can be done without being DPL, as i pointed out in my 'live platform'. The point is that without being DPL, as many others regular DDs i feel out of the loop and sometimes without enough power (I can't delegate) to act. [16:58:38]
  130. <SynrG> stratus: that being said, if could be realized without distorting their vision, that would be great. [16:58:52]
  131. <stratus> slef: I think that being the DPL, it will be easier to me push my platform ideas, not doing stuff alone or behind the scenes but as a lead of that changes listed there. [16:59:19]
  132. <SynrG> stratus: the rather slow pace of jr. development suits me fine :) i always joke i will be a grandparent before jr. is really ready for prime time, but that may be more true than i think. [16:59:53]
  133. <stratus> SynrG: yes, in fact some newcomers are teaming up with DDs to work on newer and interesting stuff out of the 'regular channels'. That's why i want to establish a groups, supergroups and projects cycle of life during my term. [17:00:35]
  134. <stratus> SynrG: see, why Debian Desktop and Jr are projects (or subprojects) while others are treated as mere 'groups in alioth' ? There's no clear reason for that. [17:01:06]
  135. <SynrG> stratus: no indeed. historical accident. [17:01:30]
  136. <stratus> SynrG: The debian-community should start as a group with a separate website and a roadmap to be integrated officially as a subproject in the future. [17:01:53]
  137. <stratus> SynrG: debian-community is just an example, not that it's something i've discussed with the responsible people behind that. [17:02:16]
  138. <slef> stratus: would you clarify what is a subproject and what isn't? [17:02:19]
  139. <stratus> slef: exactly. [17:02:47]
  140. <stratus> slef: basically because i think that each subproject should have its own section or subdomain into [17:03:43]
  141. <slef> another question I liked from the debate: Debian receives a generous $10 million dollar donation; what do we spend it on? [17:05:55]
  142. <slef> (probably the last I will re-use) [17:06:04]
  143. <SynrG> stratus: i assume you mean, for example,,,, etc. but what about much smaller efforts, e.g. teams to maintain a single package? surely not every group within debian needs that degree of visibility? [17:06:20]
  144. <stratus> SynrG: right, these can be kept with their webpages in alioth and that's it. [17:07:12]
  145. <stratus> slef: hardware for better quality assurance and autobuilders, IMHO. [17:07:36]
  146. <SynrG> stratus: so who gets to decide what's elevated to "subproject" status, and by what criteria? [17:08:00]
  147. <slef> stratus: do you think hardware wouldn't get flamed like paying people? [17:08:52]
  148. <SynrG> stratus: and indeed, what prevents that from happening today? just lack of interest in making it happen? technical barriers? social barriers? [17:09:23]
  149. <stratus> SynrG: I'm not able to tell you now the exact criteria, but I'll involve people who wrote our policy and others documents in the discussion. I plan to write a draft, pass it to them delegating this task. I think that if the group is a 'niche' it doesn't need to be a subproject to succeed (e.g: pkg-gnome, tasksel, python-modules, pkg-ltsp), but if it's scoop cross between groups (supergroups) (e.g: debian jr., debian live, debian desktop, d- [17:10:35]
  150. <stratus> i) it deserves the subproject title once it matures. [17:10:35]
  151. <SynrG> it's arguable if junior has "matured" :) [17:11:37]
  152. <stratus> slef: not if we make clear that it's "Debian hardware" and not a toy for somebody (DD or not) to play with. [17:11:43]
  153. <SynrG> except perhaps in the cheese sense [17:11:51]
  154. <stratus> SynrG: as I've wrote in my platform, it makes no sense downgrade status from current projects. [17:12:15]
  155. <SynrG> fair enough [17:12:41]
  156. <stratus> [17:14:33]
  157. <stratus> sounds interesting [17:14:37]
  158. <stratus> slef: and if people insists on flame, we fight that back with results (QA results obtained with the hardware or number of packages built with that). [17:16:41]
  159. <slef> have we run out of steam? [17:19:37]
  160. <SynrG> mhm [17:19:53]
  161. <SynrG> only so much 2 people can do to keep things moving along [17:20:05]
  162. <SynrG> and i'm not a very good debater anyway [17:20:18]
  163. <slef> stratus: would you like to make a closing statement about why people should vote for you? [17:20:21]
  164. <slef> then I'll stop logging [17:20:31]
  165. <stratus> slef: Yes, first i would like to ask Debian Developers to vote regardless if they're going to vote for my platform or not, but I also want to ask those who feel that we can have more fun and less wars developing a universal operating system to vote for us. I will do my best to work a lot alone, but I would be glad to be just a lead and make things that are in my platform happen. [17:24:09]
  166. <stratus> slef: Debian is a important part of my life as its contributors and users, I don't want people to ruin this with cheap disputes. [17:24:35]
  167. <stratus> slef: See you all soon, and thanks for reading. [17:25:02]
  168. <stratus> [END] [17:25:03]