1 00:00:01,560 --> 00:00:05,290 Lucas Nussbaum, the current Debian Project Leader 2 00:00:05,370 --> 00:00:09,020 will deliver the Bits from the Debian Project Leader now, enjoy. 3 00:00:09,140 --> 00:00:11,330 Thank you. 4 00:00:11,330 --> 00:00:15,840 [applause] 5 00:00:18,850 --> 00:00:22,160 OK so, I want to start 6 00:00:22,560 --> 00:00:25,850 with the sides of Debian that people encounter. 7 00:00:25,860 --> 00:00:28,760 Usually when people meet Debian for the first time 8 00:00:28,760 --> 00:00:30,760 it's about the technical project. 9 00:00:30,960 --> 00:00:34,760 So we're a project building a very successful distribution 10 00:00:34,760 --> 00:00:36,240 with a real impact on the world 11 00:00:36,270 --> 00:00:38,010 that's really great because 12 00:00:38,010 --> 00:00:40,110 you can go basically anywhere on Earth 13 00:00:40,180 --> 00:00:41,890 and meet people using Debian, 14 00:00:41,890 --> 00:00:43,340 or using Debian derivatives, 15 00:00:43,340 --> 00:00:44,500 who know about Debian 16 00:00:44,510 --> 00:00:47,140 and if you try to wear Debian t-shirts everyday 17 00:00:47,140 --> 00:00:49,140 you will see that many people recognize Debian. 18 00:00:49,140 --> 00:00:51,140 That's really cool. 19 00:00:51,140 --> 00:00:53,140 [from the audience] And in space too! 20 00:00:53,620 --> 00:00:56,270 Yeah, and in space too 21 00:00:56,550 --> 00:00:59,270 But it's harder to meet people in space. 22 00:01:00,650 --> 00:01:02,660 But then we're also 23 00:01:02,660 --> 00:01:04,380 a philosophical and political project 24 00:01:04,380 --> 00:01:06,600 about promoting and defending Free Software. 25 00:01:06,780 --> 00:01:08,600 And what's really cool about Debian 26 00:01:08,600 --> 00:01:10,880 is that we do that 27 00:01:11,020 --> 00:01:14,700 but with reality checks about technical parts 28 00:01:14,700 --> 00:01:17,010 it works like a feedback cycle 29 00:01:17,010 --> 00:01:20,200 between the technical part and the philosophical part. 30 00:01:20,620 --> 00:01:25,100 And we are not doing politics in the blind 31 00:01:25,130 --> 00:01:31,160 we are doing politics while making sure that what we propose actually works. 32 00:01:32,380 --> 00:01:34,810 And then there's a social experiment 33 00:01:34,810 --> 00:01:39,010 with thousands of volunteer contributors all over the world 34 00:01:39,350 --> 00:01:45,410 and bulding this community is a key outcome of DebConf. 35 00:01:45,410 --> 00:01:48,270 And I really think that this place is a fantastic 36 00:01:48,270 --> 00:01:50,640 place to have a successful DebConf that will help 37 00:01:50,640 --> 00:01:52,640 build the Debian community. 38 00:01:53,890 --> 00:01:59,110 I tried to find a symbol better than a good photo 39 00:01:59,110 --> 00:02:03,560 to describe our international community of contributors 40 00:02:03,560 --> 00:02:05,560 and I came up with power plugs 41 00:02:05,560 --> 00:02:10,030 because I think that really shows the diversity of Debian. 42 00:02:11,410 --> 00:02:16,350 So the question I get asked quite often as a Project Leader is 43 00:02:16,350 --> 00:02:17,970 "How is Debian doing?" 44 00:02:17,970 --> 00:02:21,640 and I think that most of the project is working fine. 45 00:02:21,640 --> 00:02:24,150 I decided to single out one team 46 00:02:24,150 --> 00:02:26,720 because usually that team gets a lot of blame 47 00:02:26,720 --> 00:02:28,720 it's the FTP Master team. 48 00:02:28,720 --> 00:02:37,570 Actually probably most of you know that NEW processing had some small issues in the last few weeks 49 00:02:37,570 --> 00:02:40,630 but if you loOK at the data 50 00:02:40,630 --> 00:02:43,380 there are seven members of FTP Masters that 51 00:02:43,380 --> 00:02:46,990 are doing NEW processing since the beginning of July 52 00:02:46,990 --> 00:02:52,920 and, probably, that might be one of the most active teams 53 00:02:52,920 --> 00:02:56,430 in terms of active Debian Developers: seven loOKs like huge! 54 00:02:56,430 --> 00:03:01,000 The DebConf team might have more but still... 55 00:03:01,070 --> 00:03:06,610 and since the beginning of August they processed 284 packages 56 00:03:06,610 --> 00:03:09,500 like in eleven days, 57 00:03:09,720 --> 00:03:15,190 versus only 73 uploads in the queue. 58 00:03:16,900 --> 00:03:20,370 Also we released Wheezy, finally! 59 00:03:20,370 --> 00:03:25,280 It's quite obvious that this cycle 60 00:03:25,280 --> 00:03:28,510 was a bit painful compared to the previous cycles. 61 00:03:28,510 --> 00:03:32,220 If you loOK at the length of the cycle 62 00:03:32,220 --> 00:03:41,820 we're a bit above our previous cycles and the freeze was quite long. 63 00:03:43,290 --> 00:03:46,320 So we started the development of Jessie 64 00:03:46,320 --> 00:03:50,060 with the usual bump of RC bugs 65 00:03:50,060 --> 00:03:53,480 and Jessie will be a quite challenging cycle 66 00:03:53,480 --> 00:03:58,070 we'll really need to work on returning to shorter freezes 67 00:03:58,070 --> 00:04:01,390 because long freezes are not really healthy for the project 68 00:04:01,810 --> 00:04:05,510 and we have some difficult decisions to take: 69 00:04:05,510 --> 00:04:08,600 first one about init systems, 70 00:04:09,220 --> 00:04:13,220 and also I think that in this cycle 71 00:04:13,220 --> 00:04:15,440 at the beginning of this cycle 72 00:04:15,440 --> 00:04:18,430 there are many architectures where the status is not 73 00:04:18,430 --> 00:04:20,260 completely clean 74 00:04:20,260 --> 00:04:21,850 probably we'll need to 75 00:04:22,020 --> 00:04:25,760 have quite difficult discussions about some architectures. 76 00:04:26,770 --> 00:04:30,910 So I think that we should be really careful 77 00:04:30,910 --> 00:04:35,280 making those decisions the Debian way - that is, 78 00:04:35,280 --> 00:04:38,440 make sure to take the best technical decisions 79 00:04:38,440 --> 00:04:40,720 but once the decisions will be taken 80 00:04:40,720 --> 00:04:45,590 I think we'll really need to stand behind the decisions as a project. 81 00:04:45,590 --> 00:04:51,450 We should not let ourselves be divided by the decision. 82 00:04:54,480 --> 00:04:58,250 Debian is almost twenty years old, 83 00:04:58,250 --> 00:05:01,640 and that's an age when most people stop growing 84 00:05:01,640 --> 00:05:03,640 but Debian is still changing quite a lot. 85 00:05:05,600 --> 00:05:11,020 If you went to sleep in 2005 and wOKe up now, probably 86 00:05:11,020 --> 00:05:13,610 the Debian project would loOK very different. 87 00:05:13,670 --> 00:05:16,050 I don't know if you know that movie about 88 00:05:16,050 --> 00:05:18,460 someone getting into a coma 89 00:05:18,460 --> 00:05:22,230 and waking up after the Berlin wall was brOKen down 90 00:05:22,230 --> 00:05:25,790 but could be fun to have someone waking up now, 91 00:05:25,790 --> 00:05:27,790 after eight years. 92 00:05:28,510 --> 00:05:33,270 So, first: team maintenance. 93 00:05:33,730 --> 00:05:38,650 The majority of packages in Debian are maintained by teams now, 94 00:05:38,900 --> 00:05:42,400 since about 2012. 95 00:05:42,650 --> 00:05:47,410 The red line is packages maintained by teams 96 00:05:47,410 --> 00:05:51,270 green line is packages not co-maintained 97 00:05:51,270 --> 00:05:55,400 and the others are: one co-maintainer, two co-maintainers, three co-maintainers, etcetera. 98 00:05:57,200 --> 00:06:01,620 Team maintenance is really the new way to maintain stuff 99 00:06:01,620 --> 00:06:03,620 in Debian, but then we have a problem: 100 00:06:03,870 --> 00:06:06,900 we have teams that get MIA (Missing In Action). 101 00:06:06,900 --> 00:06:10,430 We used to have developers going MIA, now we have teams going MIA. 102 00:06:10,430 --> 00:06:13,800 and actually we are not quite good at detecting that. 103 00:06:14,570 --> 00:06:16,740 When I did the survey about new contributors 104 00:06:16,740 --> 00:06:18,180 one of them had a nice story, 105 00:06:18,180 --> 00:06:19,880 well not so nice actually, 106 00:06:19,880 --> 00:06:24,580 they created a team with only one DD to maintain a set of packages 107 00:06:24,580 --> 00:06:26,560 and then the DD went MIA 108 00:06:26,560 --> 00:06:29,580 and the team was still active 109 00:06:29,580 --> 00:06:32,150 but with no one to talk to to upload the packages. 110 00:06:32,150 --> 00:06:35,680 So it's kind of a lonely island in the middle of Debian 111 00:06:37,550 --> 00:06:39,630 and we really suck at detecting that, currently. 112 00:06:39,660 --> 00:06:40,880 We need to work on that. 113 00:06:44,110 --> 00:06:47,890 Something else is: the use of VCSes to - 114 00:06:47,890 --> 00:06:51,020 that's related to teams, actually - to maintain packages in Debian. 115 00:06:51,290 --> 00:06:53,160 The green line there is Git, 116 00:06:53,160 --> 00:06:57,160 the red line there is no VCS, 117 00:06:57,160 --> 00:06:59,160 and the blue line is SVN. 118 00:06:59,160 --> 00:07:01,700 Git is clearly taking over, 119 00:07:02,340 --> 00:07:07,500 Darcs is increasing, not sure why. 120 00:07:07,640 --> 00:07:14,080 [laughing] the Haskell team maybe? 121 00:07:15,380 --> 00:07:19,690 But Git is really the new standard to maintain packages. 122 00:07:19,690 --> 00:07:24,430 But which way...? We have several ways to maintain packages using Git. 123 00:07:24,430 --> 00:07:28,040 Each team tends to develop its own workflow 124 00:07:28,040 --> 00:07:30,440 with its own packages. 125 00:07:30,440 --> 00:07:32,480 And that really sucks, because as a project 126 00:07:32,540 --> 00:07:35,680 we really need to standardize on a single way 127 00:07:35,680 --> 00:07:37,380 to maintain packages 128 00:07:37,380 --> 00:07:41,570 and not have the project divided into smaller projects 129 00:07:41,570 --> 00:07:43,910 each with its own way to maintain packages. 130 00:07:45,750 --> 00:07:49,220 There's really some work to do in that area, 131 00:07:49,220 --> 00:07:53,480 it would be fantastic if some teams could use DebConf to 132 00:07:53,480 --> 00:07:58,770 come together and decide on a standard way to maintain packages in Git. 133 00:08:01,710 --> 00:08:05,510 And then there are also packaging helpers 134 00:08:05,510 --> 00:08:08,840 the blue line is dh, 135 00:08:08,840 --> 00:08:13,440 the red line is pre-dh debhelper, 136 00:08:13,440 --> 00:08:15,880 and the green line is cdbs. 137 00:08:15,880 --> 00:08:19,440 That graph I always find quite funny because 138 00:08:19,440 --> 00:08:22,760 dh was originally advertised as the cdbs killer 139 00:08:22,760 --> 00:08:26,970 and actually is not killing cdbs, it's more killing debhelper. 140 00:08:26,970 --> 00:08:29,770 [laughter from audience] 141 00:08:30,760 --> 00:08:35,720 But still, that's raises a question: what do we do about 142 00:08:35,720 --> 00:08:37,960 our formal way to maintain packages? 143 00:08:37,960 --> 00:08:39,960 We are quite slow in general 144 00:08:39,960 --> 00:08:44,420 at deprecating the previous standard way to maintain packages. 145 00:08:44,420 --> 00:08:47,370 Clearly dh is now the new standard, 146 00:08:47,370 --> 00:08:50,380 but packages are only slowly 147 00:08:50,380 --> 00:08:54,360 migrating to dh. 148 00:08:54,960 --> 00:08:56,590 Oh, and by the way if you were wondering, 149 00:08:57,070 --> 00:09:01,560 those kind of staircases and steps, there and there 150 00:09:01,560 --> 00:09:03,440 those are the freeze, so you can see that 151 00:09:03,460 --> 00:09:07,140 things slow down during the freeze and start up again, which is expected. 152 00:09:10,210 --> 00:09:13,730 Debian is almost twenty years old 153 00:09:13,730 --> 00:09:16,620 so first I thought that a clarification was needed 154 00:09:16,620 --> 00:09:20,280 as computer geeks: it's in decimal, 155 00:09:21,110 --> 00:09:25,390 and when you see that you can ask yourself another question which is 156 00:09:25,390 --> 00:09:28,830 what should we do before reaching 20 in hex. 157 00:09:28,830 --> 00:09:34,110 Actually I'm turning 20 in hex this year, so it's something I gave some thoughts. 158 00:09:34,890 --> 00:09:43,320 Or maybe... oops! that's the problem with making last minute changes to presentations. 159 00:09:43,320 --> 00:09:45,320 Or maybe what should we do before 160 00:09:45,320 --> 00:09:50,200 well... in the next few years, what are the big challenges. 161 00:09:51,550 --> 00:09:57,890 So first, if you loOK at the global picture around Debian 162 00:09:57,890 --> 00:10:01,940 we have upstream projects, we have users 163 00:10:01,940 --> 00:10:04,320 and Debian is in the middle. 164 00:10:04,320 --> 00:10:06,460 We get software from upstream projects 165 00:10:06,460 --> 00:10:10,060 and we turn them into packages and distribute to users. 166 00:10:10,060 --> 00:10:15,660 And we get feedback and bugs and sometimes patches from users, 167 00:10:16,620 --> 00:10:20,510 and we forward them to upstream projects. 168 00:10:21,730 --> 00:10:27,050 Or we sometimes forward them to upstream projects possibly with adding patches. 169 00:10:28,310 --> 00:10:32,000 But that's not the only thing, we have also Debian derivatives 170 00:10:32,000 --> 00:10:38,670 for which we have the same schema and some of them also have their own derivatives. 171 00:10:39,630 --> 00:10:44,100 And that's really the picture of how it should be, 172 00:10:44,100 --> 00:10:48,210 with Debian really at the center of the Free Software ecosystem, 173 00:10:48,210 --> 00:10:53,230 but some of those are ... 174 00:10:53,230 --> 00:10:57,270 some of those streams don't work so well in some cases. 175 00:10:57,270 --> 00:11:01,260 So one can ask whether we are always 176 00:11:01,260 --> 00:11:05,960 a good downstream for our upstream and a good upstream for our derivatives. 177 00:11:05,960 --> 00:11:08,810 I think there's room for improvement. 178 00:11:08,810 --> 00:11:13,060 In some cases the relationship we have with downstreams or upstreams 179 00:11:13,060 --> 00:11:14,870 is really good 180 00:11:14,870 --> 00:11:18,480 but we can do better in that area 181 00:11:18,480 --> 00:11:23,650 and really reinforce the position of Debian in the center of the ecosystem. 182 00:11:23,650 --> 00:11:25,470 So the simple things you can do: 183 00:11:25,470 --> 00:11:28,320 first contact our upstreams 184 00:11:28,320 --> 00:11:35,110 when you start maintaining something it's really important that you talk with your upstream, if you have an upstream. 185 00:11:35,110 --> 00:11:42,010 So talk to them, ask them to review your plans: if you plan to package a new upstream version 186 00:11:42,010 --> 00:11:43,780 it's good to send them an email beforehand 187 00:11:43,780 --> 00:11:50,070 so they can comment on whether you should do that or just wait for the next release or something like that. 188 00:11:50,070 --> 00:11:54,350 Provide them with feedback and bug reports, 189 00:11:54,350 --> 00:11:59,130 we have some things that are not very well known 190 00:11:59,130 --> 00:12:03,320 such as patch-tracker.debian.org that extracts 191 00:12:03,320 --> 00:12:04,980 patches from Debian packages 192 00:12:04,990 --> 00:12:08,140 so that upstream can easily integrate them. 193 00:12:09,920 --> 00:12:13,520 Ask them to subscribe to the packages in the BTS (Bug Tracking System). 194 00:12:13,520 --> 00:12:17,650 I know for few packages, for example core-utils, 195 00:12:17,650 --> 00:12:19,650 we have the upstream maintainers 196 00:12:19,650 --> 00:12:25,370 actually replying to bugs in the Debian bug tracking system; 197 00:12:25,370 --> 00:12:27,480 and that's just great because users 198 00:12:27,480 --> 00:12:31,380 report bugs in Debian, the upstream maintainer comments on the bug directly in the BTS. 199 00:12:31,380 --> 00:12:33,380 It's the perfect way to work. 200 00:12:33,380 --> 00:12:36,030 Not all upstreams want to work that way 201 00:12:36,030 --> 00:12:39,710 but when they do that way is just fantastic. 202 00:12:39,710 --> 00:12:45,590 LoOK at your downstreams' bugs and patches. 203 00:12:45,590 --> 00:12:50,910 And there's a panel tomorrow at DebConf about derivatives 204 00:12:51,000 --> 00:12:54,990 could be a good idea if we had a large audience attending. 205 00:12:56,260 --> 00:13:00,570 But more generally I think that we need to keep in mind that 206 00:13:00,570 --> 00:13:03,680 Debian is also about improving Free Software as a whole 207 00:13:03,680 --> 00:13:07,630 and we should not work... well, we should work on improving Debian but 208 00:13:07,630 --> 00:13:11,180 we should really keep that global picture 209 00:13:11,180 --> 00:13:14,050 of improving Free Software, improving the world generally. 210 00:13:14,050 --> 00:13:17,940 And for that we need to be a good player and collaborate with all entities. 211 00:13:19,680 --> 00:13:25,340 The ecosystem around us is changing 212 00:13:25,340 --> 00:13:28,730 everybody is talking about cloud, which is 213 00:13:28,730 --> 00:13:33,250 a nice buzzword, but not only a buzzword 214 00:13:33,250 --> 00:13:38,600 and it brings virtualization and elasticity of infrastructure and software. 215 00:13:38,600 --> 00:13:43,870 Ours model where you install a system once 216 00:13:43,870 --> 00:13:49,000 and then you upgrade it for ten years using several Debian releases 217 00:13:49,000 --> 00:13:53,740 becomes less relevant with that ecosystem because you just 218 00:13:53,740 --> 00:14:00,720 start a new virtual machine, you don't need to upgrade Debian that often anymore. 219 00:14:01,850 --> 00:14:04,490 And that raises many challenges for Debian. 220 00:14:04,490 --> 00:14:09,710 First, the cloud - as pointed out by many people - 221 00:14:09,710 --> 00:14:12,470 is taking freedom away from users. 222 00:14:12,470 --> 00:14:16,990 So we need to work towards preserving that freedom 223 00:14:16,990 --> 00:14:19,500 and we have several ways to do that. 224 00:14:19,610 --> 00:14:24,170 For example, we can package software 225 00:14:24,170 --> 00:14:27,670 so that the users can deploy their own private cloud, we are doing that. 226 00:14:28,570 --> 00:14:33,780 We have some margins for improvements there, 227 00:14:34,100 --> 00:14:37,970 those are really really hard software stacks 228 00:14:37,970 --> 00:14:41,290 many, well usually... 229 00:14:41,290 --> 00:14:45,110 many different packages with custom configurations and services 230 00:14:45,110 --> 00:14:50,830 and more manpower on that part would be really nice. 231 00:14:50,830 --> 00:14:58,560 Then we also should work on packaging PaaS stacks 232 00:14:58,560 --> 00:15:00,290 and SaaS stacks. 233 00:15:00,290 --> 00:15:05,430 And standardizing a development platform 234 00:15:05,430 --> 00:15:09,550 and I think a standard platform in Debian is really important. 235 00:15:09,920 --> 00:15:14,990 For SaaS actually we run into the usual problem of web applications packaging 236 00:15:14,990 --> 00:15:18,590 that's not something we're particularly strong at 237 00:15:18,590 --> 00:15:22,240 and it's increasingly important. 238 00:15:23,810 --> 00:15:27,930 But then on a more technical level 239 00:15:27,930 --> 00:15:32,420 the world is using Puppet and Chef everywhere 240 00:15:32,420 --> 00:15:35,230 or is trying to use Puppet and Chef everywhere 241 00:15:35,230 --> 00:15:39,180 and one can wonder what's the role of Debian packages, 242 00:15:39,180 --> 00:15:43,630 package managers and configurations using debconf in that world. 243 00:15:43,980 --> 00:15:48,550 And we might need to evaluate what we do and maybe 244 00:15:48,550 --> 00:15:52,470 adapt a bit to that to better integrate with those tools. 245 00:15:54,060 --> 00:15:58,790 And for public clouds there's also the question of 246 00:15:58,790 --> 00:16:01,030 official Debian images: 247 00:16:01,030 --> 00:16:05,920 what does it mean to provide Debian on a public cloud 248 00:16:05,920 --> 00:16:11,460 such as Google's or Amazon's clouds. 249 00:16:12,110 --> 00:16:15,920 If you loOK at this year's DebConf schedule 250 00:16:15,920 --> 00:16:20,470 there are 8 cloud related sessions at DebConf 251 00:16:20,470 --> 00:16:27,250 and I hope that we can address and work on all those topics. 252 00:16:31,200 --> 00:16:37,420 Probably something that will raise some discussions. 253 00:16:37,850 --> 00:16:43,170 I think we should loOK into meeting all our users' needs. 254 00:16:43,170 --> 00:16:48,930 We have Debian testing which is the first and the best rolling distribution 255 00:16:48,930 --> 00:16:52,120 and I think we should really acknowledge that 256 00:16:52,120 --> 00:16:56,600 and advertise testing as such, as a rolling distribution. 257 00:16:56,600 --> 00:16:58,970 Testing is already widely used: 258 00:16:58,970 --> 00:17:01,400 during the last few days I made some stats 259 00:17:01,420 --> 00:17:05,100 from a Debian mirror 260 00:17:05,100 --> 00:17:09,820 and actually if you loOK at the HTTP logs from that mirror 261 00:17:09,820 --> 00:17:14,950 you see that... well what I did was to take the logs, 262 00:17:14,950 --> 00:17:19,670 grep for people fetching the Packages file 263 00:17:19,670 --> 00:17:24,010 and then loOK at which IP fetches which Packages file. 264 00:17:24,010 --> 00:17:30,810 42% of the users of that mirror fetched 265 00:17:31,010 --> 00:17:33,770 the Squeeze Packages file, 266 00:17:33,770 --> 00:17:36,960 60% the Wheezy one, 12% the testing one, 267 00:17:37,010 --> 00:17:39,500 and 11% the unstable one. 268 00:17:39,500 --> 00:17:45,220 Clearly there are more users... Well, 269 00:17:45,420 --> 00:17:46,490 there are two possibilities: 270 00:17:46,520 --> 00:17:49,360 either we have very few users and many developers, 271 00:17:49,360 --> 00:17:53,650 or we have quite a lot of users using testing 272 00:17:53,650 --> 00:17:56,340 and/or unstable. 273 00:17:56,340 --> 00:17:59,370 If you loOK at the Popularity Contest submitters... 274 00:17:59,400 --> 00:18:02,820 (This doesn't add up to 100% because 275 00:18:02,820 --> 00:18:06,000 one specific IP can fetch several Packages files.) 276 00:18:06,760 --> 00:18:10,500 If you loOK at Popularity Contest submitters, 277 00:18:10,500 --> 00:18:13,540 loOKing at the version of the Popularity Contest package 278 00:18:13,540 --> 00:18:15,950 that is used to submit the results, 279 00:18:15,950 --> 00:18:20,250 we have about 10% of people using testing or unstable 280 00:18:20,250 --> 00:18:25,310 and actually that blue share 281 00:18:25,310 --> 00:18:29,480 varies quite a lot during cycles and 282 00:18:29,480 --> 00:18:32,640 at the end of the Wheezy cycle, just before the release, 283 00:18:32,640 --> 00:18:36,020 it was a lot more people using testing or unstable. 284 00:18:39,300 --> 00:18:44,830 That's not something new: we have lots of people using testing and unstable. 285 00:18:44,830 --> 00:18:50,230 But there are also many other good reasons to go in the direction of a rolling release. 286 00:18:50,230 --> 00:18:56,500 First it makes us provide more recent software to users 287 00:18:56,500 --> 00:18:59,730 so for the Free Software community in general it means 288 00:18:59,730 --> 00:19:02,500 that we build a shorter feedback loop 289 00:19:02,510 --> 00:19:05,660 between upstream projects and the user. 290 00:19:05,660 --> 00:19:10,610 Users can use recent software and report bugs on recent software 291 00:19:10,610 --> 00:19:12,800 because usually when you are an upstream developer 292 00:19:12,800 --> 00:19:15,280 you don't really care about bugs 293 00:19:15,320 --> 00:19:17,410 in software you developed two years ago: 294 00:19:17,410 --> 00:19:19,980 and probably that bug was found in the meantime. 295 00:19:21,310 --> 00:19:25,380 So, the more people we have using recent software 296 00:19:25,380 --> 00:19:27,250 the more bugs are fixed 297 00:19:27,250 --> 00:19:29,250 and the more in general Free Software is improved. 298 00:19:30,370 --> 00:19:34,570 It gets us more testers for the next stable release 299 00:19:34,570 --> 00:19:38,160 so usually what happens... well 300 00:19:40,060 --> 00:19:43,760 it's quite useful from a release management point of view to 301 00:19:43,760 --> 00:19:47,230 detect bugs earlier; this gives us more time to fix bugs. 302 00:19:47,230 --> 00:19:52,670 And actually if you loOK at Christian's stats about 303 00:19:52,670 --> 00:19:54,270 (I think it was Christian who made those stats) 304 00:19:54,270 --> 00:19:56,270 about bug reporting rate 305 00:19:56,270 --> 00:20:00,650 the Ubuntu bug reporting rate is much higher than Debian's 306 00:20:00,650 --> 00:20:01,810 which is a bit worrying 307 00:20:01,810 --> 00:20:07,230 of course if you are the - I don't know - Iceweasel maintainer 308 00:20:07,230 --> 00:20:09,170 you don't really care about receiving more bugs, 309 00:20:09,220 --> 00:20:13,520 probably you have enough and it's pretty well covered. 310 00:20:13,520 --> 00:20:17,260 But if you maintain a quite obscure Ruby library, 311 00:20:17,260 --> 00:20:21,810 it could help to have two times more users, because probably 312 00:20:21,810 --> 00:20:25,690 if you have only 100 users worldwide, 313 00:20:25,690 --> 00:20:27,690 not all of them will report bugs 314 00:20:28,660 --> 00:20:31,650 and it could be helpful to increase the number of users. 315 00:20:32,730 --> 00:20:38,790 Something else is that it makes attracting different users so 316 00:20:40,360 --> 00:20:44,150 if you loOK at the people using Arch Linux, for example 317 00:20:44,150 --> 00:20:49,060 most of them are quite young and enthusiastic Linux users 318 00:20:49,060 --> 00:20:52,910 and attracting more of this kind of users to Debian 319 00:20:52,910 --> 00:20:56,420 means that in the end some of them 320 00:20:56,420 --> 00:21:00,720 will turn into Debian contributors. 321 00:21:00,720 --> 00:21:04,110 Having the image of the old and boring distribution, 322 00:21:04,110 --> 00:21:08,730 which is not completely true but some of it is, 323 00:21:08,730 --> 00:21:10,730 doesn't really help us recruit new people. 324 00:21:11,430 --> 00:21:15,750 We can stay with the old and boring aspect 325 00:21:15,750 --> 00:21:21,380 but is better to have the other side of being young and really active. 326 00:21:23,180 --> 00:21:28,020 And also I think that actually it's a low-hanging fruit because 327 00:21:28,020 --> 00:21:31,220 there's no need to change anything: 328 00:21:31,220 --> 00:21:33,470 it's mainly about PR 329 00:21:33,470 --> 00:21:36,210 about communication, communicating to the public 330 00:21:36,210 --> 00:21:41,590 that testing is usable as a rolling distribution and 331 00:21:41,590 --> 00:21:47,360 just use it and stuff like that. 332 00:21:47,360 --> 00:21:50,820 I think everything is there 333 00:21:50,820 --> 00:21:53,570 we just need to advertise it. 334 00:21:54,240 --> 00:21:57,160 Of course a big challenge with that 335 00:21:57,160 --> 00:21:59,640 is to coexist with the stable release 336 00:21:59,650 --> 00:22:01,510 and to not harm the stable release: 337 00:22:01,510 --> 00:22:05,050 we need to work on... well we don't 338 00:22:05,050 --> 00:22:07,020 ...we should be really careful about 339 00:22:07,020 --> 00:22:14,000 not decreasing the quality and the workforce that goes into our stable release. 340 00:22:17,870 --> 00:22:22,880 About manpower, the challenge for the next few years 341 00:22:22,880 --> 00:22:27,690 as usual - as it was for the past 20 years probably - 342 00:22:27,690 --> 00:22:29,690 is to recruit new contributors. 343 00:22:29,690 --> 00:22:33,030 Everybody complains about manpower 344 00:22:33,030 --> 00:22:36,120 it's a regular complaint and I think it's a justified complaint: 345 00:22:36,120 --> 00:22:38,120 there are many areas in Debian 346 00:22:38,120 --> 00:22:40,740 where we could use a lot more manpower. 347 00:22:41,660 --> 00:22:44,990 As a DPL, I often have to pOKe people about 348 00:22:44,990 --> 00:22:49,460 why something is not working as expected 349 00:22:49,460 --> 00:22:56,990 and of course it's easy to blame the lack of manpower but 350 00:22:56,990 --> 00:22:59,960 sometimes when you don't have...well, 351 00:22:59,960 --> 00:23:01,960 sometimes just boils down to that 352 00:23:01,960 --> 00:23:03,960 and you can't do anything beside that. 353 00:23:04,900 --> 00:23:09,440 I made a survey of new contributors, 354 00:23:09,440 --> 00:23:13,370 you might have read the report on debian-project last week, 355 00:23:15,190 --> 00:23:18,250 and what it shows is that it's really hard to contribute to Debian. 356 00:23:18,250 --> 00:23:21,120 As a project we tend to build 357 00:23:21,120 --> 00:23:23,390 very efficient processes 358 00:23:23,390 --> 00:23:25,390 and tools, so we like to 359 00:23:25,390 --> 00:23:27,180 optimize stuff for ourselves, 360 00:23:27,180 --> 00:23:31,300 but as a result those processes and tools are often 361 00:23:31,300 --> 00:23:34,160 quite complex and difficult to learn for newcomers. 362 00:23:34,780 --> 00:23:38,630 That's a trade-off: 363 00:23:38,630 --> 00:23:42,380 we tend to be selfish about our processes and tools. 364 00:23:42,380 --> 00:23:47,850 It's hard to change, but keeping that in mind 365 00:23:47,850 --> 00:23:52,800 when designing processes and tools will already be a good thing. 366 00:23:54,320 --> 00:23:58,650 We have very high quality requirements, 367 00:23:58,710 --> 00:24:02,660 the attention to detail we put into our packages 368 00:24:02,660 --> 00:24:04,320 it's just incredible. 369 00:24:04,320 --> 00:24:08,960 Of course, that's something that contributes greatly to the success of Debian 370 00:24:10,250 --> 00:24:15,020 but still for new contributors it may be a bit surprising. 371 00:24:16,370 --> 00:24:19,700 We have a misalignment between 372 00:24:19,700 --> 00:24:22,540 our contributors' goals and our goals. 373 00:24:22,540 --> 00:24:25,950 What we want really is people who just join our teams 374 00:24:25,950 --> 00:24:27,570 and fix all the team's bugs 375 00:24:27,570 --> 00:24:29,780 and upgrade our packages to the new versions. 376 00:24:29,780 --> 00:24:30,770 That would be fantastic! 377 00:24:30,880 --> 00:24:33,530 Well, people come with an idea 378 00:24:33,530 --> 00:24:35,310 what they want to do inside Debian 379 00:24:35,320 --> 00:24:38,220 and usually it's to package this thing I use 380 00:24:38,220 --> 00:24:40,220 that may be nobody else uses but 381 00:24:40,220 --> 00:24:44,930 that's something that is important to the new contributor. 382 00:24:45,670 --> 00:24:52,220 We need to find a middle ground between what 383 00:24:52,220 --> 00:24:55,760 the new contributor wants and what we want. 384 00:24:56,350 --> 00:25:00,780 And also one thing that the survey showed 385 00:25:00,780 --> 00:25:03,490 it's that is very hard to get sponsored outside a team. 386 00:25:03,490 --> 00:25:05,490 So if you want to package something 387 00:25:05,490 --> 00:25:07,490 and there's a team 388 00:25:07,490 --> 00:25:09,490 where it fits 389 00:25:09,490 --> 00:25:11,490 it's fine: you will probably find 390 00:25:11,490 --> 00:25:15,000 someone willing to sponsor your software. 391 00:25:15,000 --> 00:25:17,240 If it doesn't fit in a team 392 00:25:17,240 --> 00:25:19,530 and you don't know, don't have a friend or colleague 393 00:25:19,530 --> 00:25:22,870 who is a Debian Developer and who will do the sponsoring for you, 394 00:25:22,870 --> 00:25:25,970 then it's really really hard. 395 00:25:27,250 --> 00:25:30,360 You can all help change that: I think it's really 396 00:25:30,360 --> 00:25:34,360 a collective responsibility to change that. 397 00:25:34,360 --> 00:25:39,530 First, subscribe to debian-mentors and 398 00:25:39,530 --> 00:25:42,170 do some sponsoring on debian-mentors 399 00:25:42,170 --> 00:25:45,390 if all of us do one 400 00:25:45,390 --> 00:25:49,710 sponsoring on debian-mentors per month, I think the problem is solved basically. 401 00:25:50,760 --> 00:25:54,470 Problem is, if you loOK at debian-mentors archives 402 00:25:54,470 --> 00:25:57,660 last month, I think it was like four or five 403 00:25:57,700 --> 00:26:01,190 different DDs doing reviews and sponsoring. 404 00:26:01,190 --> 00:26:04,710 We cannot point to something where only 405 00:26:04,780 --> 00:26:08,150 four or five different DDs are active. 406 00:26:09,220 --> 00:26:16,250 And something that is deep in the culture of Debian is that 407 00:26:16,250 --> 00:26:17,600 you cannot make mistakes. 408 00:26:17,600 --> 00:26:21,590 You're not allowed to make mistakes. 409 00:26:21,590 --> 00:26:23,920 And I think that for sponsoring that's really hard 410 00:26:23,950 --> 00:26:26,130 because you are asked to review something 411 00:26:26,130 --> 00:26:29,900 and you cannot read all the upstream code 412 00:26:29,900 --> 00:26:33,540 you cannot audit all the upstream code loOKing for possible bugs. 413 00:26:33,540 --> 00:26:37,330 At some point you have to take a risk to make the upload 414 00:26:37,330 --> 00:26:41,540 and sometimes it's true that mistakes will happen. 415 00:26:41,540 --> 00:26:45,050 I think we need to be better at accepting mistakes. 416 00:26:45,050 --> 00:26:47,470 It's OK to not know everything, 417 00:26:47,470 --> 00:26:54,510 it's OK to not be perfect right from the start, 418 00:26:54,510 --> 00:26:59,880 but it's better to be vocal about things you don't know 419 00:26:59,880 --> 00:27:01,090 things where you are unsure 420 00:27:01,090 --> 00:27:03,180 than to just hide it under the carpet 421 00:27:03,220 --> 00:27:05,190 and hope nobody will notice. 422 00:27:05,190 --> 00:27:08,830 Actually even reviewing packages is something quite hard because 423 00:27:08,830 --> 00:27:11,500 if you miss something, everybody will see it 424 00:27:11,500 --> 00:27:19,070 but I think that's OK, we should really increase the culture of this being OK. 425 00:27:19,150 --> 00:27:27,470 Someone mentioned that one of the people doing reviews on debian-mentors 426 00:27:27,470 --> 00:27:30,170 does a lot of reviews but never sponsors. 427 00:27:30,170 --> 00:27:31,740 So I'm not sure if that's because 428 00:27:31,770 --> 00:27:33,850 they fear that they're going to make a mistake 429 00:27:33,850 --> 00:27:35,840 by uploading something that... 430 00:27:35,840 --> 00:27:42,240 by missing something in their reviews, but that's really sad. 431 00:27:42,790 --> 00:27:44,620 It's OK to make mistakes from time to time: 432 00:27:44,660 --> 00:27:47,510 it's software and you can probably revert it somehow. 433 00:27:47,510 --> 00:27:54,250 It's really hard to break Debian badly by sponsoring something. 434 00:27:55,890 --> 00:28:00,010 There's some work to do on 435 00:28:00,040 --> 00:28:02,370 infrastructure around sponsoring: 436 00:28:02,370 --> 00:28:06,660 mentors.debian.net got re-written two years ago, I think 437 00:28:06,660 --> 00:28:12,020 the current version got the work started two years ago 438 00:28:12,050 --> 00:28:13,990 using a Summer of Code project, I think 439 00:28:14,830 --> 00:28:18,100 It really helps, but there's more to do 440 00:28:18,100 --> 00:28:22,060 for example in many cases 441 00:28:22,060 --> 00:28:25,730 the review is just "oh you forgot that Lintian error" 442 00:28:25,730 --> 00:28:30,160 if we had automated Lintian checks of packages uploaded to mentors 443 00:28:30,160 --> 00:28:35,490 probably the prospective contributor would notice and 444 00:28:36,840 --> 00:28:40,750 this would limit the need for reviews. 445 00:28:40,750 --> 00:28:44,670 Nicolas Dandrimont mentioned that 446 00:28:44,670 --> 00:28:49,760 work is underway there and I think Paul Tagliamonte is working on that. 447 00:28:55,010 --> 00:28:56,670 Something else that is related 448 00:28:56,670 --> 00:29:01,950 to this misalignment between contributors' goals and our goals: 449 00:29:01,950 --> 00:29:03,950 we need to be better at 450 00:29:03,950 --> 00:29:06,810 advertising tasks that are suitable for new contributors. 451 00:29:06,810 --> 00:29:10,570 So if we don't want new contributors to package 452 00:29:10,850 --> 00:29:14,030 another image viewer 453 00:29:14,030 --> 00:29:17,450 we need to provide them with ideas of things they could do. 454 00:29:17,450 --> 00:29:21,050 We have the wnpp-alert 455 00:29:21,050 --> 00:29:26,170 who in the room is running wnpp-alert on a regular basis? 456 00:29:27,940 --> 00:29:33,510 One person. Congratulations. [laughter] 457 00:29:34,420 --> 00:29:38,510 We need a way to make it easier to discover opportunities of contributions. 458 00:29:38,510 --> 00:29:41,190 There are lots of opportunities for contributions, actually. 459 00:29:41,190 --> 00:29:43,800 If you run wnpp-alert you will probably find 460 00:29:43,800 --> 00:29:45,800 two or three packages that you rely on 461 00:29:45,800 --> 00:29:47,380 that are orphaned. 462 00:29:47,460 --> 00:29:51,360 If you find someone to adopt them 463 00:29:51,360 --> 00:29:54,180 that solves your problems for those packages. 464 00:29:55,510 --> 00:29:58,270 We need to design better and simpler 465 00:29:58,270 --> 00:30:01,700 processes and tools and document them. 466 00:30:02,910 --> 00:30:06,860 For example everything related to 467 00:30:06,860 --> 00:30:10,910 using alioth, using Git, using SVN to maintain packages 468 00:30:10,910 --> 00:30:15,960 which is quite poorly documented, currently. 469 00:30:15,960 --> 00:30:19,000 Something that's really really... 470 00:30:19,000 --> 00:30:21,610 It was mentioned that something 471 00:30:21,610 --> 00:30:26,280 really useful is everything related to peer mentoring and internship projects. 472 00:30:26,280 --> 00:30:29,420 New contributors really like 473 00:30:29,420 --> 00:30:32,460 a human contact and having someone to ask questions to. 474 00:30:32,460 --> 00:30:35,970 That's something that... 475 00:30:35,970 --> 00:30:41,500 I don't know exactly how we can improve that, yet. 476 00:30:43,460 --> 00:30:45,690 Andreas Tille has some ideas 477 00:30:45,760 --> 00:30:47,290 he has a session about that 478 00:30:47,290 --> 00:30:51,780 about peer mentoring, but we need to work on that. 479 00:30:52,600 --> 00:30:55,700 In general, basically, what we need to do is 480 00:30:55,700 --> 00:30:58,160 have Debian become a more welcoming project 481 00:30:58,160 --> 00:31:01,690 where people can start contributing more easily 482 00:31:01,690 --> 00:31:03,900 because currently is really really hard. 483 00:31:03,900 --> 00:31:07,770 If you look at the schedule we have seven events related to that, so 484 00:31:07,770 --> 00:31:11,160 the good news is that people care about this 485 00:31:11,160 --> 00:31:15,010 now we just need to make progress on that. 486 00:31:17,900 --> 00:31:21,470 And then, before I conclude my talk, 487 00:31:21,470 --> 00:31:24,370 I want to talk a bit about Debian governance. 488 00:31:24,370 --> 00:31:28,320 I just learnt a new job 489 00:31:28,320 --> 00:31:31,280 and my vision of the new job is that 490 00:31:31,280 --> 00:31:34,820 many DPL tasks are quite short tasks 491 00:31:34,820 --> 00:31:39,600 where if you do them using low-latency 492 00:31:39,600 --> 00:31:44,160 like as soon as receive it it's done, it's much better. 493 00:31:44,160 --> 00:31:47,660 For example everything related to money handling, 494 00:31:47,660 --> 00:31:49,900 email redirection to the right people, 495 00:31:51,590 --> 00:31:53,710 pOKing people about something, 496 00:31:53,710 --> 00:31:54,840 everything related to legal, 497 00:31:54,840 --> 00:31:59,100 where there are some constraints about how long you take to answer, 498 00:31:59,100 --> 00:32:02,890 and all those tasks are quite hard to delegate or to share 499 00:32:02,890 --> 00:32:05,880 because there's a hard coordination overhead 500 00:32:05,880 --> 00:32:09,150 if you want to share them with a team, doesn't really work 501 00:32:09,150 --> 00:32:13,820 because you will spend a lot of time coordinating with the rest of the team 502 00:32:13,820 --> 00:32:16,360 and that doesn't really make sense, you can do it yourself. 503 00:32:16,670 --> 00:32:20,130 But there are also lot of tasks that can be delegated 504 00:32:20,130 --> 00:32:21,750 either totally or partially. 505 00:32:21,750 --> 00:32:25,330 Even writing a delegation, for example 506 00:32:25,330 --> 00:32:28,400 that's something that takes some time 507 00:32:28,400 --> 00:32:30,990 because you need to contact the team, 508 00:32:30,990 --> 00:32:35,560 figure out who they would like to see added to the team 509 00:32:35,600 --> 00:32:38,480 then you wait two weeks because nobody noticed your mail 510 00:32:38,480 --> 00:32:42,080 ping them again... It's quite time-consuming. 511 00:32:43,080 --> 00:32:47,420 And actually there's only the final act of sending a delegation email 512 00:32:47,420 --> 00:32:50,690 that can only be done by the DPL, currently. 513 00:32:50,690 --> 00:32:52,960 Everything else can be prepared by someone else 514 00:32:52,960 --> 00:32:56,280 and that kind of things can be really useful. 515 00:32:56,580 --> 00:33:00,360 So, Zack started the DPL helpers initiative 516 00:33:00,610 --> 00:33:05,360 to try to distribute those tasks to a team 517 00:33:05,360 --> 00:33:09,970 and to teach more people what DPL tasks are about. 518 00:33:13,880 --> 00:33:17,410 My view for that is that 519 00:33:17,410 --> 00:33:19,980 it could be a kind of government for the Debian Project: 520 00:33:19,980 --> 00:33:22,040 you have someone that is 521 00:33:22,040 --> 00:33:26,040 mainly responsible and doing that kind of short tasks, 522 00:33:26,040 --> 00:33:28,040 but then you have a group of people 523 00:33:28,040 --> 00:33:33,260 each with their own area of interest 524 00:33:33,260 --> 00:33:35,120 doing specific things. 525 00:33:35,120 --> 00:33:39,730 For example, we can have someone specializing in all 526 00:33:39,730 --> 00:33:44,580 legal stuff, in all new contributors related stuff, 527 00:33:44,580 --> 00:33:48,700 and those areas are quite easy to define and quite easy to delegate. 528 00:33:48,700 --> 00:33:51,900 With "delegating" in the informal sense of the word: 529 00:33:51,900 --> 00:33:56,690 it doesn't really need to be something official for most of the tasks. 530 00:33:57,690 --> 00:34:00,270 The problem with the DPL helpers is that is not very active. 531 00:34:00,270 --> 00:34:02,980 We had only two participants at the last meeting. 532 00:34:05,720 --> 00:34:08,160 I feel a bit trapped as a DPL 533 00:34:08,160 --> 00:34:12,230 I was hoping to rely on this to share the load 534 00:34:12,230 --> 00:34:16,700 and actually there are not that many people willing to share the load with me. 535 00:34:18,510 --> 00:34:21,890 But I wonder whether this could be the basis for 536 00:34:21,890 --> 00:34:24,400 the most sustainable government model for Debian 537 00:34:24,400 --> 00:34:26,370 something that could work, 538 00:34:26,370 --> 00:34:29,150 and that would allow someone not from French academia 539 00:34:29,150 --> 00:34:31,840 or not self-employed to be a DPL. 540 00:34:31,840 --> 00:34:36,920 Because we're running out of people from French academia! 541 00:34:36,920 --> 00:34:38,920 [laughter] 542 00:34:40,220 --> 00:34:42,750 So there's a BOF about that, 543 00:34:42,750 --> 00:34:51,290 we might mention things going on currently, active tasks, 544 00:34:51,290 --> 00:34:54,490 but I also would like to spend a lot of time discussing 545 00:34:54,490 --> 00:35:02,040 how we can move forward making it possible to move away from French academia. 546 00:35:03,320 --> 00:35:08,710 That is the end of my talk, 547 00:35:09,950 --> 00:35:11,940 thank you for coming to DebConf, 548 00:35:11,940 --> 00:35:13,940 enjoy DebConf, I hope it will be 549 00:35:13,940 --> 00:35:16,650 a very successful DebConf 550 00:35:16,650 --> 00:35:18,650 and I'm quite sure it will be. 551 00:35:18,650 --> 00:35:22,810 Please use DebConf to come and talk to me in person 552 00:35:22,810 --> 00:35:26,850 that's my leader email, which is archived, 553 00:35:26,850 --> 00:35:30,300 and my IRC nickname if you want to ping me 554 00:35:30,300 --> 00:35:32,300 and then we can meet somewhere. 555 00:35:32,840 --> 00:35:38,700 So that's a kind of reminder of what I talked about in my talk 556 00:35:38,700 --> 00:35:40,700 so that you don't need to ask question about 557 00:35:40,700 --> 00:35:43,580 only the last point or only about rolling. 558 00:35:44,460 --> 00:35:45,580 Thank you! 559 00:35:45,580 --> 00:35:57,320 [applause] 560 00:36:09,100 --> 00:36:11,500 [question] About the rolling distribution thing 561 00:36:11,500 --> 00:36:13,090 testing as rolling distribution, 562 00:36:13,090 --> 00:36:15,790 I see a potential problem that has already been discussed 563 00:36:15,790 --> 00:36:20,220 and that I've already raised in IRC: 564 00:36:20,220 --> 00:36:22,420 when the freeze comes, 565 00:36:22,420 --> 00:36:26,700 this rolling distribution would it be freezed? 566 00:36:26,700 --> 00:36:29,410 Would it be intermittently rolling? 567 00:36:29,410 --> 00:36:33,270 Would it be handled differently than maybe 568 00:36:33,270 --> 00:36:35,640 two overlapping testing distributions at the time? 569 00:36:35,670 --> 00:36:37,380 How might that be handled? 570 00:36:37,380 --> 00:36:39,380 [Lucas] Well, I think that 571 00:36:44,910 --> 00:36:49,330 With that freeze duration it's probably a big problem 572 00:36:49,330 --> 00:36:52,760 With that freeze duration, I think we can live 573 00:36:52,760 --> 00:36:56,550 with everything being frozen for three months. 574 00:36:56,550 --> 00:36:58,550 Almost four months. 575 00:37:00,170 --> 00:37:02,890 I think that everyone wants shorter freezes 576 00:37:02,890 --> 00:37:07,920 that would be useful for rolling distribution, so 577 00:37:08,750 --> 00:37:13,730 Let just aim for shorter freeze, let's not try to 578 00:37:13,730 --> 00:37:16,460 do something more complex that might hurt our stable releases. 579 00:37:16,460 --> 00:37:18,460 At this for now, maybe 580 00:37:18,460 --> 00:37:23,390 in five years from now we'll figure out something and 581 00:37:23,390 --> 00:37:27,650 to make everybody happy but 582 00:37:27,650 --> 00:37:31,470 what we do currently I think it's fine. 583 00:37:31,470 --> 00:37:34,820 [question] I don't think three months is an acceptable freeze 584 00:37:34,820 --> 00:37:38,840 I really don't: I mean we'd have this conversation at several DebConfs 585 00:37:38,840 --> 00:37:43,410 and I think a really good target direction for freeze is two or three weeks. 586 00:37:43,410 --> 00:37:48,810 If we can't run a process that allows us to 587 00:37:48,810 --> 00:37:53,910 return unstable to be unstable in much less than a month, then 588 00:37:53,910 --> 00:37:59,620 I think it really negatively impacts the ability of 589 00:37:59,620 --> 00:38:01,730 lots of things in the project to keep growing 590 00:38:01,730 --> 00:38:04,560 those stair steps that show up in many of our plots 591 00:38:04,560 --> 00:38:07,770 are just, you know, very frustrating. 592 00:38:07,770 --> 00:38:11,220 [Lucas] Yeah, but it also depends on what you call freeze actually. 593 00:38:11,450 --> 00:38:14,500 Our definition of freeze is... 594 00:38:14,500 --> 00:38:18,800 well, if we change our definition of freeze we can have shorter freeze. 595 00:38:18,800 --> 00:38:20,800 Shorter total freeze, for example. 596 00:38:20,800 --> 00:38:22,800 [laughter] 597 00:38:22,800 --> 00:38:24,800 [applause] 598 00:38:24,800 --> 00:38:27,530 There are things to explore in that area 599 00:38:27,530 --> 00:38:31,670 like making sure that key packages don't get 600 00:38:31,670 --> 00:38:35,180 upgraded to new upstream versions just before the freeze. 601 00:38:36,290 --> 00:38:39,780 [question] Yes, obviously this is all part of what it takes to 602 00:38:39,780 --> 00:38:41,350 makes something like that happen, 603 00:38:41,350 --> 00:38:43,170 I'm certainly not advocating 604 00:38:43,170 --> 00:38:45,370 a return to the very old process of 605 00:38:45,370 --> 00:38:47,370 "let's just grab a snapshot of unstable 606 00:38:47,370 --> 00:38:49,630 on a particular day and call it a release", but 607 00:38:49,980 --> 00:38:51,600 there has to be something in between 608 00:38:51,600 --> 00:38:53,730 because when we end up in a situation where 609 00:38:53,730 --> 00:38:56,290 for many many months we are not changing 610 00:38:56,290 --> 00:38:59,160 tools chains and core libraries and software 611 00:38:59,160 --> 00:39:02,340 it's very very easy for people to lose focus 612 00:39:02,340 --> 00:39:04,320 and for their attention to move elsewhere 613 00:39:04,320 --> 00:39:06,320 and I think it's very hard for us to get it back. 614 00:39:07,940 --> 00:39:12,030 [question] I clearly remember the talk of Anthony Towns in 2001 615 00:39:12,030 --> 00:39:16,550 at the first DebConf when he introduced the pool system 616 00:39:16,550 --> 00:39:20,340 where testing was introduced. 617 00:39:20,340 --> 00:39:23,630 And somebody else and me raised immediately their hand 618 00:39:23,630 --> 00:39:27,140 "what will happen with packages in testing 619 00:39:27,140 --> 00:39:30,300 and have a Release-Critical bug? Will they be removed again?" 620 00:39:30,300 --> 00:39:32,730 And the decision was "no". 621 00:39:32,730 --> 00:39:35,170 But I think that there's some tendency now 622 00:39:35,170 --> 00:39:37,650 to remove these packages, at least "leaf packages" 623 00:39:37,650 --> 00:39:41,700 which have a Release-Critical bug, and I think it's quite a good thing. 624 00:39:42,620 --> 00:39:44,560 [Lucas] I think that we 625 00:39:44,560 --> 00:39:46,360 should go further in that direction 626 00:39:46,360 --> 00:39:49,320 that is, well... 627 00:39:49,320 --> 00:39:53,050 we tend to treat all packages as equal, 628 00:39:53,050 --> 00:39:57,190 which is nice, because our users rely on all of our packages, 629 00:39:57,190 --> 00:40:00,180 but some of them are still more important than others 630 00:40:00,180 --> 00:40:06,470 and if we had a way to easily detect which are the bugs 631 00:40:06,470 --> 00:40:09,890 that really need to be fixed before the release 632 00:40:09,890 --> 00:40:12,990 and which are the ones that we could just remove the package 633 00:40:12,990 --> 00:40:17,110 that doesn't work, and OK some users will suffer, of course, but 634 00:40:17,110 --> 00:40:20,530 it doesn't block the release, 635 00:40:20,530 --> 00:40:22,530 it would be a good way. 636 00:40:22,530 --> 00:40:24,530 Maybe we should just 637 00:40:24,530 --> 00:40:26,870 go further than removing packages 638 00:40:26,870 --> 00:40:29,860 during the freeze, but also remove packages now 639 00:40:29,860 --> 00:40:31,860 if something is clearly unsuitable 640 00:40:31,860 --> 00:40:34,710 for the next release we could just remove it from testing now, 641 00:40:34,710 --> 00:40:36,390 and if it get fixed, it can get back. 642 00:40:36,390 --> 00:40:41,590 we have at least, almost two years to get it back in testing. 643 00:40:41,590 --> 00:40:45,120 To get it back in shape. 644 00:40:48,350 --> 00:40:51,420 We have very few Release Team members present at DebConf 645 00:40:51,420 --> 00:40:55,370 so it's a bit difficult to discuss that 646 00:40:55,370 --> 00:40:58,920 and it's their main responsibility to decide that 647 00:40:58,920 --> 00:41:00,730 of course they need to talk with the project, 648 00:41:00,730 --> 00:41:03,690 but it's their role to decide about that. 649 00:41:04,300 --> 00:41:08,600 [question] So Lucas, you made two proposals 650 00:41:08,600 --> 00:41:13,460 one is to make testing more rolling release, and the other is to remove more things from it 651 00:41:14,050 --> 00:41:17,620 How you'd reconcile those two? 652 00:41:17,620 --> 00:41:19,620 [laughter] 653 00:41:19,620 --> 00:41:23,630 [Lucas] I'm quite sure we can find the technical solution to that 654 00:41:23,630 --> 00:41:25,670 there are already technical solutions: 655 00:41:25,670 --> 00:41:29,830 people just install packages from unstable from time to time. 656 00:41:29,830 --> 00:41:33,200 And for the users that we are targetting anyway 657 00:41:33,200 --> 00:41:35,350 it's not really a problem if from time to time 658 00:41:35,350 --> 00:41:37,970 they need to take specific... 659 00:41:37,970 --> 00:41:40,300 Actually, if the package is not in testing 660 00:41:40,300 --> 00:41:42,300 and you have unstable in sources.list 661 00:41:42,300 --> 00:41:44,300 it just works. 662 00:41:51,050 --> 00:41:55,260 [question] But I don't think our main problems are leaf packages 663 00:41:57,160 --> 00:42:01,610 You can always say that if there's a bug in a library 664 00:42:01,610 --> 00:42:07,570 then let's remove it, so if there's a bug in libruby, let's remove Ruby and all its packages. 665 00:42:07,570 --> 00:42:10,620 [laughter] 666 00:42:10,620 --> 00:42:14,330 I mean leaf packages are not our problem... 667 00:42:14,330 --> 00:42:18,200 to remove leaf packages is easy and we do that. 668 00:42:19,120 --> 00:42:22,230 Question is what if there's a bug in Iceweasel. 669 00:42:22,230 --> 00:42:27,350 [Lucas] But I think bugs in Ruby - maybe I'm a bit biased about that - 670 00:42:27,350 --> 00:42:31,750 but Antonio can hit you and he's just next to you. 671 00:42:31,750 --> 00:42:36,250 But I think bugs in Ruby are probably the kind of bugs that should be fixed. 672 00:42:36,250 --> 00:42:41,110 Because a Debian release... we need to draw the line somewhere, 673 00:42:41,570 --> 00:42:47,080 but Ruby it's probably on the "let's fix it" side of the line. 674 00:42:51,110 --> 00:42:55,840 Some obscure Ruby library, like rubyfeedparser I'm upstream for that, 675 00:42:55,840 --> 00:42:59,810 nobody cares if it gets removed, well some people will care 676 00:43:01,300 --> 00:43:07,200 [question] So I'd like to propose a radical answer to that question 677 00:43:07,220 --> 00:43:13,090 which is that we should prepared to revert something like Ruby to the previous upstream version 678 00:43:13,090 --> 00:43:18,150 if it fixes Release-Critical regressions, and 679 00:43:18,150 --> 00:43:20,380 obviously that should be done with some care but 680 00:43:20,380 --> 00:43:23,970 it may be done as a NMU, so we need to develop some 681 00:43:23,970 --> 00:43:27,110 collective understanding of when that may be appropriate 682 00:43:27,110 --> 00:43:29,110 and how to manage the fallout. 683 00:43:29,110 --> 00:43:31,740 But if we're able to do that then 684 00:43:32,290 --> 00:43:35,690 we're in a much better position to fix bugs 685 00:43:35,690 --> 00:43:37,690 that are somehow intractable 686 00:43:37,690 --> 00:43:41,640 just by undoing the problematic upload effectively. 687 00:43:43,070 --> 00:43:45,550 [Lucas] But I think that is already happening in kind of 688 00:43:45,550 --> 00:43:48,430 during the freeze, sometimes, happens that 689 00:43:48,460 --> 00:43:51,350 we just revert something to the previous version because 690 00:43:51,400 --> 00:43:52,890 in the new version there are problems. 691 00:43:52,890 --> 00:43:57,100 Often is because the maintainer decided to update and 692 00:43:57,100 --> 00:43:59,100 that was not really a good idea, but 693 00:44:00,920 --> 00:44:03,570 we already have that possibility and we're using it from time to time 694 00:44:03,570 --> 00:44:10,250 I'm not sure it really helps fixing that many additional bugs. 695 00:44:12,520 --> 00:44:16,090 One thing that is related is a kind of 696 00:44:16,090 --> 00:44:20,810 having a feature branch for packages, and having a way to 697 00:44:20,810 --> 00:44:23,850 revert specific changes: 698 00:44:23,850 --> 00:44:27,310 currently we only have one development branch 699 00:44:27,310 --> 00:44:31,100 we could have a feature branch where every package 700 00:44:31,100 --> 00:44:33,100 every new version of a package 701 00:44:33,100 --> 00:44:36,150 lives or sets of packages live 702 00:44:36,150 --> 00:44:38,150 and have them merged into 703 00:44:38,150 --> 00:44:40,150 unstable or testing or something like that 704 00:44:41,990 --> 00:44:45,300 That's lot of technical development. 705 00:44:47,620 --> 00:44:51,440 [talkmeister] I think time is over, so if you want to discuss this further 706 00:44:51,440 --> 00:44:53,440 you have to use the "hallway track". 707 00:44:54,430 --> 00:45:02,920 [applause]