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: