[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] English subtitles for "Bits from the DPL" DebConf13 talk



Francesca Ciceri wrote:
> Attached is my first one: "Bits from the DPL" by Lucas Nussbaum.
> You can just read the file, or load it with the video [2] using your favourite
> video player (I use "mplayer videoname -sub subtitlesname").

> 1
 ^
I'll assume that BOM is deliberate.  Sorry, no time to do a full
line-by-line commentary, but here's a revised version.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package
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, to start I want to

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

51
00:02:43,380 --> 00:02:46,990
that 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 decision 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 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 your 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 a 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 report bugs in Debian,

198
00:12:27,480 --> 00:12:31,380
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
Our 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 up 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
Nicholas 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
tool 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 a 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 be 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]


Reply to: