[05:22:42] Join madduck_ has joined this channel. (~madduck@p3E9EBFB7.dip.t-dialin.net) [05:22:45] Mode madduck gives channel operator privileges to madduck_. [05:23:26] Mode madduck gives channel operator privileges to madduck_. [05:37:04] are you going to invite the candidates in here? [05:37:12] I think we should ask them to change their nicks to be their names [05:38:44] Join aj has joined this channel. (aj-irc@azure.humbug.org.au) [05:39:04] good morning aj [05:39:19] good afternoon, madduch -- what channels am i meant to be in? [05:39:27] madduck even [05:39:52] aj: this one and the debate one, at least. [05:40:45] Join stockholm has joined this channel. (~andi@petrus.schuldei.org) [05:41:51] ah, and -discuss, and that's all? [05:41:57] stockholm: good morning. [05:42:01] (hey stockholm, helen) [05:42:02] aj: yes [05:42:11] aj: yes, that's all. [05:42:45] aj, stockholm: at your convenience, please change your nicks to AnthonyTowns and AndreasSchuldei (or similar) [05:43:06] madduck_: hi! [05:43:51] madduck_: Andreas_Schuldei The hand of the deity is upon thee, thy nick may not change [05:43:54] (#debian-dpl-debate) [05:44:09] should i leave that channel first? [05:44:14] Join Overfiend has joined this channel. (~branden@cpe-65-26-182-85.indy.res.rr.com) [05:44:25] Overfiend: at your convenience, please change your nick [05:44:36] (good afternoon) [05:44:46] 00:44 [freenode] -!- BrandenRobinson The hand of the deity is upon thee, thy nick may not change (#debian-dpl-debate) [05:44:55] madduck_: ---^ [05:45:32] aye [05:45:36] wtf??? [05:45:45] i think you may have to /part the channel and rejoin. [05:45:48] no clue why... [05:45:51] balls. [05:45:54] maybe because it's moderated? [05:45:57] sorry [05:46:01] Nick Overfiend is now known as BrandenRobinson. [05:46:21] aj, stockholm: please do the same. [05:46:43] where are gus, jonathan, mjg59? [05:46:44] Nick aj is now known as AnthonyTowns. [05:47:16] "Why register and identify? Your nick is how people know you." - heh [05:47:18] maybe krooger is stuck in line at Kroger. [05:47:33] [05:50:00] Nick stockholm is now known as AndreasSchuldei. [05:50:19] Join mjg59 has joined this channel. (~mjg59@tyrosine.codon.org.uk) [05:50:28] mjg59: great. good morning. [05:50:37] 4 out of 6 [05:50:41] morning to all :) [05:50:44] mjg59: please part from -debate, change your nick to your real name, then rejoin -debate. [05:50:58] Nick mjg59 is now known as MatthewGarrett. [05:55:38] * AnthonyTowns wonders how this is going to all work [05:56:04] AnthonyTowns: we do too. :) [05:56:11] awwwesome [05:56:33] branden's done this all before, we should just let him moderate :-P [05:56:39] :-P [05:57:17] okay, that's two tongues out. Where do the other 2/3rds of the candidates stand on the all-important exposed tongue issue? [05:57:28] lol [05:57:36] Join gus has joined this channel. (~user@46.33.233.220.exetel.com.au) [05:57:40] howdy gus [05:57:50] okay, andreas will only expose his tongue in a wide jawed laugh [05:57:54] My tongue is remaining entirely within my mouth [05:58:02] bah. just managed to get out of a meeting :( [05:58:10] gus: please change your nick to AngusLees. you will need to part from -debate and rejoin to be able to do so. [05:58:13] (Lordy, I'm tired) [05:58:14] MatthewGarrett: /your/ mouth? [05:58:31] MatthewGarrett: hehe - me too [05:58:53] MatthewGarrett: the adrenalin will be there in a se [05:58:55] sec [05:58:59] no sign of Jonathan Walter? [05:58:59] * BrandenRobinson isn't tired. Just nervous and hallucinating. Should make for some entertainment. [05:59:05] madduck_: "Walther" [05:59:07] with an H [05:59:16] but, no I haven't seen him under any of his nicks [05:59:18] SirD* [06:00:58] so are we supposed to keep up with / chat on -discuss too? [06:01:06] gus: if you want. [06:01:09] please change your nick... [06:01:26] Nick gus is now known as AngusLees. [06:01:33] AngusLees: thanks [06:01:57] sorry, hadn't realised it hadn't worked previously.. [06:01:59] yay [06:02:15] in previous years, candidates talking on -discuss was not allowed. [06:02:23] because of the time limits on replies [06:02:37] BrandenRobinson: it's your own decision [06:02:48] BrandenRobinson: if you can multitask... [06:02:53] shall we all (candidates) take a pledge not to real quick? :) [06:03:11] i can't keep up with -discuss already :) [06:03:18] heh. i've already got information overload [06:03:18] me either. [06:03:26] MatthewGarrett: please join #debian-dpl-debate! [06:03:28] * BrandenRobinson is swamped as well. [06:03:33] BrandenRobinson: can you rephrase that? [06:03:41] MatthewGarrett: nevermind [06:03:51] AndreasSchuldei: we can all mutually agree to not speak on debian-dpl-discuss during the actual debate [06:04:03] oh, sure. [06:04:15] i would not dare waste time [06:04:21] just to keep the playing field level for people who don't have multiple brains. [06:04:45] * BrandenRobinson so pledges, contingent on unanimity :) [06:06:13] AndreasSchuldei: wake up! [06:06:18] and yay, i get a phonecall as soon as helen hits enter. yeesh [06:06:40] i am awake, whats wrong? [06:06:48] #debian-dpl-debate... [06:06:51] ah [06:07:08] AndreasSchuldei: please confirm you are there and ready to go [06:07:23] * AndreasSchuldei waves [06:07:37] in -debate, please... [06:08:54] Join SirDinosaur has joined this channel. (~user@s142-179-93-180.bc.hsia.telus.net) [06:09:09] we're answering here, right? [06:09:11] SirDinosaur is Jonathan Walther [06:09:13] SirDinosaur: please change your nick to JonathanWalther. you nwill need to part and rejoin -debate [06:09:16] * SirDinosaur waves. [06:09:17] AnthonyTowns: that's my understanding [06:09:19] just got in from church. [06:09:19] AnthonyTowns: yes [06:09:20] helen: is anything more required? [06:09:35] AndreasSchuldei: nope, paste your answer in *here* when you are ready or when we call Time. [06:09:43] yes [06:09:54] my *scratch* buffer is ready [06:09:55] had a team of 5 prayer warriors praying with and for me. :-) [06:10:05] ouch [06:10:09] SirDinosaur: please change your nick to JonathanWalther. you nwill need to part and rejoin -debate [06:10:16] SirDinosaur: we are already started with the first question, you may want to be quick... [06:10:31] SirDinosaur: we gave you a few minutes to be running late, but we had to get started [06:10:42] thanks helen, I appreciate the breather. [06:10:52] if everyone else will give their answer, I'll start composing mine [06:10:58] SirDinosaur: you need to change your nick [06:11:03] SirDinosaur: please change your nick... :) [06:11:06] crud. [06:11:10] I just did change my nick. guess it didn't work [06:11:13] for that you need to leave -discuss [06:11:23] -debate [06:11:38] -debate, otherwise it wont work [06:11:51] Nick SirDinosaur is now known as JonathanWalther. [06:12:00] (c: [06:12:01] there. danke. [06:12:22] thanks. [06:12:44] helen: I saw everything up until "you agree, please state" [06:12:50] s/up until/past/ [06:13:02] how long do we have left/ [06:13:14] 27 secs [06:13:16] BrandenRobinson: 30 seconds [06:13:26] i saw no question at all [06:13:31] I think the primary responsibility of the DPL with respect to [06:13:31] release management is to make sure the release managers have the [06:13:31] support and resources they need. The recent proposal which I've [06:13:31] decided to call the "Vancouver Prospectus" has done a good job [06:13:31] of getting the ball rolling, when it comes to exposing the [06:13:33] developers at large to the exigencies of release management. [06:13:36] There's a lot more to it than fixing RC bugs, as critical as [06:13:38] that is. As I said in my recent message to -vote, this is a [06:13:41] pardon? [06:13:41] beginning, not the end of the release management process. The [06:13:43] current RM team certainly has my full trust and respect. As [06:13:46] DPL, I pledge to work with them to the best of my ability to see [06:13:48] that their needs are met. Sometimes, that includes deflecting a [06:13:51] flame or two, of course -- though they're amply equipped in [06:13:53] their own regard on that front. :) [06:13:56] did I do the right thing? [06:14:01] BrandenRobinson: yes [06:14:05] and if so, should the rest of us do it too? :) [06:14:08] yes please [06:14:10] now please [06:14:13] The release strategy is primarily the release manager's responsibility. [06:14:14] TIME IS UP [06:14:15] I think the key focus for the DPL is on supporting their role, andensuring they have the resources to act appropriately, such as byorganising meetings like AndreasSchuldei and Steve did in Vancouver, [06:14:17] I believe OpenBSD has developed the optimal release strategy. However I believe that the release team, at their meeting in Vancouver, came up with a very welcome step forward, which will benefit Debian greatly. [06:14:19] and be making sure that other teams are aware of what the release [06:14:22] team needs, and vice-versa. There's a lot of benefit to be had tothe release team from simply ensuring other teams -- such as the [06:14:25] GNOME/KDE teams or the d-i team -- are functioning effectively. [06:14:27] I think the ideal release strategy would result in regular releases, [06:14:30] on either a six, nine, twelve, or eighteen month basis; ideally [06:14:33] predictable to the day. [06:14:35] I think the release team's proposal for sarge and etch is good, and [06:14:38] working out the kinks in it on the mailing lists is the best approach. [06:14:50] I believe that Debian should release faster, but beyond that I believe [06:14:53] the details should basically be left up to the release team. The current [06:14:56] proposals are somewhat controversial, and I'll happily admit that I'm [06:14:59] not a big fan of the idea of reducing our support of other [06:15:02] architectures. However, the release team are the people doing the work. [06:15:05] Now that they've provided more information about the problems they face, [06:15:08] there's an opportunity to try to find other ways of tackling the [06:15:10] problems. The release team are the people responsible for actually doing [06:15:13] the work - if nobody else can come up with an acceptable plan, then we [06:15:16] should support them in their choices. [06:15:46] The DPL should represent the projects views on the release cycle, and [06:15:46] that means the views of the release team. Being DPL should give [06:15:46] little weight over the average developer. Personally I think reducing [06:15:46] the number of archs will be a necessary part of this. Given the [06:15:46] existence of testing, I think the optimum release cycle for stable [06:15:46] releases is probably somewhere around 18-30 months. [06:15:48] [06:15:50] is there an agree on order we should answer the questions? [06:15:55] (crap, how do you people write so much so quickly) [06:16:06] JonathanWalther: no. [06:16:07] JonathanWalther: madduck will change the order as he pastes them into -debate [06:16:12] ok. [06:16:32] (i don't know if you can manage it, but BrandenRobinson said: .... would be nicer than having the name on each pasted line) [06:16:43] my roommate is the greatest; I come home at 10pm to find a big Italian dinner ready waiting on the counter. [06:17:12] * AnthonyTowns watches JW try to distract us all with salivating hunger [06:17:15] AndreasSchuldei: did you see anything that I wrote in the start? [06:17:23] AndreasSchuldei: I can't understand how youwould not see the question [06:17:26] no, i did not [06:17:38] could i have caused this by /ignore #debian-dpl-debate * JOIN NICKS PARTS QUITS [06:17:41] you didn't see my welcome or anything? not ignoring me are you? [06:17:43] damn [06:17:47] is the * at fault? [06:17:56] I don't know [06:18:02] CANDIDATES, please answer on a single IRC line if possible. [06:18:18] madduck_: ugh, my answers are very likely to overflow that [06:18:34] but I set my texwidth to 40 in Vim, to help the 80-column-limited people [06:18:37] madduck_: It's not possible to answer on a single line unless you want the length of answers to be heavily limited [06:18:37] is that any help: [06:18:38] ? [06:18:38] and is hard to do with cut and paste :( [06:18:42] (it was 65) [06:18:56] tr '\n' ' ' [06:19:17] i'll work on something in my script [06:19:19] madduck_: there is a limit to the length of IRC lines, and some clients truncate them after what they tell you [06:19:32] i.e., you see "abcdefg" at the end of your line in the client... [06:19:39] ...but only "abc" shows up. [06:19:53] IRC lines can go up to 1024 characters in length. [06:19:58] are we on the next question yet? [06:20:09] no, just getting started [06:20:36] AndreasSchuldei: you see what I am writing now? [06:20:36] hey, we should work out a plan to drop gnome, and announce it at the end of the debate [06:20:44] no [06:20:47] it must be the star [06:20:56] I'll repaste it here [06:20:56] how can i unignore * ? [06:21:07] 06:20:44] Question 2 has a time limit of 4 minutes: [06:21:07] [06:21:00] 2. The New Maintainer queue has recently been "revived" thanks (in part) to additional manpower. Where do you see the strengths of the current approach to new maintainers, and which weaknesses can you identify? In what ways does the current NM process ensure the necessary skills of a prospective developer, and where does it fall short? What might you do after your election to further improve the [06:22:25] AndreasSchuldei: I'm sorry, I don't know. [06:22:43] AndreasSchuldei: /ignore shows you the index numbers. [06:22:48] /uinignore [06:23:09] this reminds me of the running of the bulls in Pamplona. [06:23:16] except with DPL candidates instead of bulls. [06:23:34] 100 seconds left [06:23:49] The NM process is strong in that it [06:23:49] probably weeds out those who are only [06:23:49] very casually interested. The downside [06:23:49] is that it is so rigorous that it might [06:23:49] scare off, or drain, people who could [06:23:51] otherwise contribute valuably. Some of [06:23:53] this year's DPL candidates (including aj [06:23:56] and myself) came in under the old [06:23:58] system, and I don't think anyone can [06:24:01] deny that we've contributed a lot to the [06:24:04] project. A good start, as DPL, would be [06:24:06] to simply talk to the NM team and find [06:24:09] out what gets complained about by the [06:24:11] actual applicants. Also, there's a [06:24:14] legendarily difficult dynamic loader [06:24:16] question that's in T&S that might, [06:24:19] perhaps, be overkill. [06:24:21] madduck_: if you want me to join that beast, I will [06:24:42] erk [06:24:49] one sec [06:25:03] I haven't had any particular reason to complain about the skills of any [06:25:04] It has been 8 years since I went through the New Maintainer process. I haven't looked at it since then. Since we keep bringing new developers on board, it must be working well. If anyone knows of any problems with the New Maintainer queue, they are welcome to bring them up to me before, after, and during the election. Vote Jonathan Walther! [06:25:06] of the recent new maintainers, so I'm happy enough with the amount of [06:25:09] testing that we're performing. Again, I don't really see it as the DPL's [06:25:12] job to interfere with the working of a system unless there's obviously [06:25:16] something wrong, and as far as I can tell the majority (if not all) of [06:25:18] Time people [06:25:20] I've posted about NM on -vote; but to summarise. I think there are a few [06:25:24] flaws remaining in NM; most notably that it takes a long time to go [06:25:26] through. I was accepted into Debian within a week or so of applying, and only [06:25:26] the people working on NM are doing an excellent job of it. [06:25:29] to maintain "distributed-net-pproxy", in non-free. Now, people routinely [06:25:32] have to wait months before they can get in, which is far from ideal. [06:25:33] [06:25:34] The new maintainer process helps people entering the project to reach a good skill level on technical terms today. It still has probems with the socal skills. somehow we filter for endurability and patient, not for the ability to cooperate.It might help to add a SocialSkills part to the process and communicate how the new maintainer should try to behave. [06:25:34] I'd like to see NM focus more on a mentoring role; so that the "tasks and [06:25:37] skills" section at least, and some of the procedures/policies section to [06:25:40] In my SmallTeams approach explained in my platform the NM process is partly integrated and has mentoring and social skills included. [06:25:40] mostly consists of working on real packages with real maintainers, rather [06:25:44] than often filling in questionnaires, or working on new packages that aren't [06:25:46] necessarily very useful. There are some more details in my post ot -vote, [06:25:50] and I think the example of the -women mentoring project is worth following, [06:25:53] but more details will need to be worked out over time as well. [06:25:55] my irc client may be playing up, yay :( [06:26:01] AnthonyTowns: :( [06:26:09] madduck_: Branden's reply has been truncated [06:26:20] I'll keep pasting the questions in here after I ask them in -debate [06:26:28] helen: thanks. that helps. [06:26:30] BrandenRobinson: where??? [06:26:38] on the actual channel [06:26:43] madduck_: It got to "A good start, as DPL" [06:26:57] The new maintainer process is to weed out people who are unsuitable [06:26:58] (either technically or because they're just downright unhelpful). My [06:26:58] (uneducated) understanding is that few people are actually *actively* [06:26:58] turned away by this process, and certainly Debian has little in place [06:26:58] to deal with such people once they make it into the project. So this [06:26:58] probably shows that almost all people in NM are appropriate and we [06:27:00] should optmiise the process a little on that assumption. In [06:27:02] particular, I'm not at all confident that existing DDs would survive [06:27:04] what we ask of new DDs now, which says a lot. Perhaps forcing *all* [06:27:07] DDs to "reevaluate" regularly might force us all to pay more attention [06:27:08] to the suitability of NM - as well as giving us a way to weed out MIA or maintainers that no longer reach our increasing demands. [06:27:11] [06:27:49] * JonathanWalther looks at Angus mirthfully. [06:29:07] madduck_: Angus got truncated this time. [06:29:41] a rapier wit is no match for a 40-character-per-line limit! [06:29:47] "MIA or ma" [06:30:12] btw: i have -debate now [06:30:31] AndreasSchuldei: you can see what i say there? [06:30:44] yes i do [06:30:55] good, that's much better [06:31:02] [06:30:37] Question 3 has a time limit of 5 minutes: [06:31:02] [06:30:43] 3. It has often been claimed that Debian is growing too large. What positive and what negative influences does Debian's current size have on the project? Depending on where you see Debian in the future, what steps would you take as DPL to shrink or grow the project, or to help it maintain its current extents? [06:31:07] just incase anyone missed it [06:31:41] fmt sucks [06:32:14] madduck_: you're doing fine. Glad I'm not doing your job here... [06:34:42] * madduck_ fixed his script [06:34:58] great :) [06:35:01] The large size of Debian, in terms of our developer population, our userbase, and the size of our archive (thanks to both package coverage and architecture support) is both a blessing and a curse. Large size makes us appealing to a broad audience, and often an official Debian package of a FLOSS project you've heard of is just an apt-get away. Still, the large size means we've accumulated a lot of cruft. I think Mart [06:35:08] urp [06:35:11] BrandenRobinson: feel free to paste as before [06:35:13] that didn't paste how I wanted [06:35:13] BrandenRobinson: Truncated [06:35:19] yeah. balls. [06:35:20] It's not clear whether the question refers to the size of the archive or [06:35:20] Beyond its free software stance, Debian's size is probably its most [06:35:20] significant asset. Because the number of developers is (pretty much) [06:35:20] allowed to scale with the amount of free software packaged, Debian is [06:35:20] ableto give each package a much larger amount of attention than any [06:35:20] other distro. This is evident in the complexity (and usefulness) of [06:35:21] our postinsts compared to (say) the average redhat ".tar.gz with deps" [06:35:22] going back to 40 cols [06:35:23] package. I think the project is growing at a reasonable rate [06:35:23] the number of people involved. If the former, I think that's up to the [06:35:25] currently, and all we (and the DPL) really need to do is watch out for [06:35:26] release team - if they believe we can release with an archive this size, [06:35:27] bottlenecks that aren't scaling with the number of members. One such [06:35:29] then we should do so. If they don't, then we'll need to start thinking [06:35:29] point was DAM, which is now being addressed - perhaps the security [06:35:31] team might be next (I have no idea without talking with people [06:35:32] about approaches to reduce the size. The wide range of software we offer [06:35:33] involved in various areas). [06:35:34] Debian's great as a large project; the more architectures and packages and developers and users we can support the better. Each of those have problems though; lots of architectures are a hot topic right now; but the others cause problems too: lots of packages make it hard for users to know what to install, make it hard to track bugs, and make it hard to provide services [06:35:35] [06:35:35] is obviously something our users like, and it would be good to be able [06:35:36] Groups that dont grow stagnate. But Debian can grow a lot bigger if it manages to handle the process smoothly. It has reached several chokepoints now, limiting its growth severly. The SmallTeams approach i presented in my platform is a unique and proven way of letting social groups grow larger without losing their charater or vision. With its help there would be a smooth entry point for developers and users to help along on most level [06:35:38] to continue supporting that. [06:35:40] (like the buildds or the archive or mirrors or lintian.debian.org) that work on all of them. Lots of developers make it hard to reach consensus on issues, and understand what everyone else in the project is doing. And lots of users mean that you're never allowed to make mistakes. :) [06:35:41] If it's in terms of the number of people involved, then the obvious [06:35:43] issue is that it's harder to keep a strong sense of a single community. [06:35:45] I think Debian's about solving those problems as well as possible, and making an OS that works as effectively as possible for everyone. [06:35:46] I don't think that Debian growing in size is an intrinsic problem, but [06:35:47] The large size of Debian, in terms of our developer population, our userbase, and the size of our archive (thanks to [06:35:50] we need to be able to communicate more clearly within the project. With [06:35:51] Many hands make for light work. The more the merrier! As DPL I will let things develop organically, as they have so far. When we reach the natural limits to our growth, we will stop growing without any need for DPL intervention. [06:35:52] a small set of developers, information can be trusted to pass back and [06:35:54] audience, and often an official Debian [06:35:55] forth. With a thousand people involved, we need to be more rigerous in [06:35:57] package of a FLOSS project you've heard [06:35:59] terms of making sure that people are told everything that they need to [06:35:59] of is just an apt-get away. Still, the [06:36:02] know. [06:36:02] large size means we've accumulated a lot [06:36:04] of cruft. I think Martin Michlmayr has [06:36:05] AndreasSchuldei: truncated... [06:36:07] done a great job with MIA, but we [06:36:09] probably need more people doing it, if [06:36:13] we can find the volunteers. Likewise, [06:36:15] we might want to more strongly consider [06:36:17] an MIA review process for packages [06:36:19] themselves. Some packages in sarge [06:36:22] haven't been revved since woody -- they [06:36:24] should be looked at, at the very least. [06:36:26] BrandenRobinson: "(thanks to audience, and often an official Debian" [06:36:27] Managing growth is a major challenge for [06:36:28] The SmallTeams approach i presented in my platform is a unique and proven way of letting social groups grow larger without losing their charater or vision. With its help there would be a smooth entry point for developers and users to help along on most levels. [06:36:29] all organizations -- many businesses [06:36:32] fail because they can't manage this. [06:36:34] The DPL's primary role in many respects [06:36:37] is to manage growth. IMO the best way [06:36:39] to do this is keep one's ears open, and [06:36:42] remember the Social Contract: We Won't [06:36:44] Hide Problems. [06:36:47] what a mess :( [06:36:49] I wonder if we'd be better off /dcc sending text files [06:36:53] audience, and often an official Debian [06:36:53] package of a FLOSS project you've heard [06:36:53] of is just an apt-get away. Still, the [06:36:53] large size means we've accumulated a lot [06:36:55] of cruft. I think Martin Michlmayr has [06:36:58] done a great job with MIA, but we [06:37:06] does that help? [06:37:13] BrandenRobinson: we need the log of what you said compared to what we pasted into -debate [06:37:14] yeah [06:37:24] BrandenRobinson: We got a ( but not a ) (as far as I could tell) [06:37:38] 01:35 < BrandenRobinson> The large size of Debian, in terms of [06:37:38] our developer population, our userbase, [06:37:38] and the size of our archive (thanks to [06:37:39] both package coverage and architecture [06:37:39] support) is both a blessing and a curse. [06:37:41] Large size makes us appealing to a broad [06:37:43] 01:35 < BrandenRobinson> audience, and often an official Debian [06:37:48] oh, I see. [06:37:48] grrrr [06:37:51] that better? [06:38:12] I don't know why irssi laid out that first line like that [06:38:18] "We Won't Hide Problems. what a mess :(" :) [06:38:20] AndreasSchuldei: you were truncated in the first reply. Please repaste [06:38:29] The SmallTeams approach i presented in my platform is a unique and proven way of letting social groups grow larger without losing their charater or vision. With its help there would be a smooth entry point for developers and users to help along on most levels. [06:38:34] that is the second part [06:39:21] AnthonyTowns: yeah, that's the sound of 100 rank-1 votes going away :-P [06:39:35] madduck_: do you need the first part, again? [06:40:26] yes [06:40:27] AndreasSchuldei: yes [06:40:41] Groups that dont grow stagnate. But Debian can grow a lot bigger if it manages to handle the process smoothly. It has reached several chokepoints now, limiting its growth severly. [06:40:56] (stagnant) [06:41:06] Do not chatter here. i will paste everything. [06:41:43] can we do a ---BEGIN/---END instead and chatter outside? [06:42:11] BEGIN [06:42:11] The large size of Debian, in terms of our developer population, our userbase, and the size of our archive (thanks to [06:42:18] audience, and often an official Debian [06:42:21] package of a FLOSS project you've heard [06:42:25] of is just an apt-get away. Still, the [06:42:27] large size means we've accumulated a lot [06:42:29]