1
00:00:00,000 --> 00:00:02,490
Thank you very much.

2
00:00:03,150 --> 00:00:05,060
Thanks everybody for coming,…

3
00:00:08,666 --> 00:00:12,186
If you are packaging software and you want
me to work on with you,

4
00:00:12,186 --> 00:00:13,526
this is how you can do that.

5
00:00:13,526 --> 00:00:15,156
It is a very self-??? talk:

6
00:00:15,156 --> 00:00:18,516
I just want to explain some of the things
that I like,

7
00:00:18,516 --> 00:00:21,366
some practice that I prefer about Debian
packaging,

8
00:00:21,366 --> 00:00:25,236
and I don't pretend this is any sort of…

9
00:00:25,236 --> 00:00:27,296
official, permanent or final thing.

10
00:00:27,296 --> 00:00:30,456
I just wanted to share some ideas that I
have about the way that I work with

11
00:00:30,456 --> 00:00:34,976
packages, in the hope that maybe, hmm,
for two hopes:

12
00:00:34,976 --> 00:00:38,057
One is that I hope that I can show you
something that you have not heard of,

13
00:00:38,057 --> 00:00:40,677
or maybe you were doing differently,

14
00:00:40,677 --> 00:00:42,417
or maybe you think it is
the right think to do

15
00:00:42,417 --> 00:00:43,877
and it is just nice to see
somebody else doing it.

16
00:00:43,877 --> 00:00:47,047
My second hope is that you can tell me
what I am doing wrong,

17
00:00:47,047 --> 00:00:51,047
and you can help me learn and improve
on my own packaging techniques.

18
00:00:51,047 --> 00:00:52,907
If you see something that
I am proposing up here,

19
00:00:52,907 --> 00:00:55,507
and you think there is a problem with it,
I would like to hear about it too.

20
00:00:55,507 --> 00:00:58,227
I just want to see more of the culture
within Debian,

21
00:00:58,237 --> 00:01:00,627
of people who are doing packaging,
explaining what they are doing,

22
00:01:00,627 --> 00:01:02,787
and so I thought I would
just step up and explain:

23
00:01:02,787 --> 00:01:04,497
"Here is some of the practice that I do",

24
00:01:04,497 --> 00:01:08,717
In the hope that other people will do the
same and explain what they are doing,

25
00:01:08,717 --> 00:01:12,207
and maybe they can learn from
me and I can learn from them.

26
00:01:12,207 --> 00:01:16,917
Without much further ????, I am
just going to dive into it.

27
00:01:16,917 --> 00:01:20,897
If you have questions, I am perfectly
happy to be interrupted,

28
00:01:20,897 --> 00:01:24,187
we have some folks with walking mics
in the crowd:

29
00:01:24,187 --> 00:01:26,687
you can just raise your hand.

30
00:01:26,687 --> 00:01:29,247
If you have got a question or an
interruption or whatever,

31
00:01:29,247 --> 00:01:30,347
that is fine.

32
00:01:30,347 --> 00:01:33,037
I doubt I will go the whole 15 minutes,
I think there are 20 minutes,

33
00:01:33,037 --> 00:01:35,177
I doubt I will go the whole time,
so there will be also

34
00:01:35,177 --> 00:01:36,897
time for questions at
the end if you prefer.

35
00:01:36,897 --> 00:01:38,697
But I do not mind being interrupted.

36
00:01:38,697 --> 00:01:42,787
So, this is all on this web page here,

37
00:01:42,787 --> 00:01:44,787
you could probably skip this talk and go
read the web page,

38
00:01:44,787 --> 00:01:46,857
but then you would not have the nice
??? actions,

39
00:01:46,857 --> 00:01:48,857
and it is easier to tell me that I am
wrong in person,

40
00:01:48,857 --> 00:01:51,397
so I would like to have that happen.

41
00:01:51,397 --> 00:01:53,447
I put this up on the Debian wiki,

42
00:01:53,447 --> 00:01:56,237
because I want anyone
to be able to find it.

43
00:01:56,237 --> 00:02:00,237
If you think you have got some good ideas,
you should put it on the Debian Wiki too:

44
00:02:00,237 --> 00:02:05,007
other people can take advantage of the
ideas that you have got.

45
00:02:07,577 --> 00:02:11,087
First baseline is:
I really like revision control.

46
00:02:11,097 --> 00:02:14,267
And I know that it makes me
a certain flavor on nerd,

47
00:02:14,267 --> 00:02:19,007
but when we are working with things that
are as complicated as software packages,

48
00:02:19,010 --> 00:02:19,890
hmmm…

49
00:02:23,370 --> 00:02:25,670
I think a lot of people don't get
that in Debian you are not

50
00:02:25,670 --> 00:02:27,610
just working on one
software package:

51
00:02:27,610 --> 00:02:30,120
you are actually probably, if you
are doing a responsibly work,

52
00:02:30,120 --> 00:02:33,110
on at least two software packages,
and maybe 5.

53
00:02:33,110 --> 00:02:35,150
So you have got the version that is
unstable,

54
00:02:35,150 --> 00:02:39,260
and you have got the version that you
try to maintain for stable as well.

55
00:02:39,260 --> 00:02:45,170
And we are committing to
doing maintenance work.

56
00:02:45,170 --> 00:02:52,500
A lot of our work in the project is ???
in nature:

57
00:02:52,500 --> 00:02:55,490
we want to clean up the mess and
we want us to stay out of the way

58
00:02:55,490 --> 00:02:58,260
and make sure things work,
functionally,

59
00:02:58,260 --> 00:03:01,340
for people who are relying on the
operating system to not get in their way.

60
00:03:01,340 --> 00:03:04,110
So revision control I think is really
helpful because it means you can

61
00:03:04,110 --> 00:03:07,670
keep track of what changes you have done
on different branches of the project

62
00:03:07,670 --> 00:03:09,800
while you are maintaining both of them.

63
00:03:09,800 --> 00:03:14,440
Basically, ??? require working with
the revision system I am comfortable with,

64
00:03:14,440 --> 00:03:17,740
I prefer Git, I am not going to have a
religious word about it.

65
00:03:17,740 --> 00:03:21,290
If upstream uses Git, I am
even happier, and I try to make

66
00:03:21,290 --> 00:03:25,680
my packaging depend on
upstream's revision control.

67
00:03:29,342 --> 00:03:34,812
I like to use 'git-buildpackage', and I
like to use it with debhelper.

68
00:03:34,812 --> 00:03:36,793
If you have not tried out
'git-buildpackage',

69
00:03:36,793 --> 00:03:39,883
we are going to have a
'git-buildpackage' skill share session

70
00:03:39,883 --> 00:03:43,883
later on today actually, and I welcome
you to come and share your tricks with it,

71
00:03:43,883 --> 00:03:46,293
or learn some tricks from other people.

72
00:03:46,293 --> 00:03:50,483
It is a particular way that you can keep
your Debian packaging in a Git repository,

73
00:03:50,483 --> 00:03:55,843
and it helps you to keep track of all of
the changes that have happened within

74
00:03:55,843 --> 00:03:59,843
your packaging and within upstream to
make sure you are not accidentally

75
99:59:59,999 --> 99:59:59,999
making other changes.

76
99:59:59,999 --> 99:59:59,999
So it is very easy to go back and review
what you have done.

77
99:59:59,999 --> 99:59:59,999
I find that really useful.

78
99:59:59,999 --> 99:59:59,999
I definitely also like to keep upstream's
source code in the same revision control

79
99:59:59,999 --> 99:59:59,999
system.

80
99:59:59,999 --> 99:59:59,999
I like to keep the tarballs in the
revision control system because it means

81
99:59:59,999 --> 99:59:59,999
that if someone is interested, they can
uses a tool called 'debcheckout'.

82
99:59:59,999 --> 99:59:59,999
You can use 'debcheckout' with a name of
a package:

83
99:59:59,999 --> 99:59:59,999
you say just "I am really interested in
package 'foo',

84
99:59:59,999 --> 99:59:59,999
let me see the source code for that":

85
99:59:59,999 --> 99:59:59,999
debcheckout foo

86
99:59:59,999 --> 99:59:59,999
You get the source code, and you get the
source code from a revision control

87
99:59:59,999 --> 99:59:59,999
system that you can now track and you
can just propose changes on.

88
99:59:59,999 --> 99:59:59,999
You can also extract the tarball from that
revision control system.

89
99:59:59,999 --> 99:59:59,999
'debcheckout' actually works even if you
do not have upstream stuff in there,

90
99:59:59,999 --> 99:59:59,999
but I like to keep it all in one revision
control system,

91
99:59:59,999 --> 99:59:59,999
it is just easier to find everything when
you want.

92
99:59:59,999 --> 99:59:59,999
Some of these things that I prefer have
to do with what the upstream software

93
99:59:59,999 --> 99:59:59,999
developer has done, so I am less inclined
to try the package an upstream software

94
99:59:59,999 --> 99:59:59,999
project if they just throw tarballs here
over the wall to an FTP side

95
99:59:59,999 --> 99:59:59,999
every now and then.

96
99:59:59,999 --> 99:59:59,999
It makes it more difficult for me to know
what they are doing,

97
99:59:59,999 --> 99:59:59,999
and why they are doing it.

98
99:59:59,999 --> 99:59:59,999
So i like it, I have already said, when
upstream uses Git,

99
99:59:59,999 --> 99:59:59,999
I also like when upstream signs their
releases,

100
99:59:59,999 --> 99:59:59,999
and say "hey, this is specific release",

101
99:59:59,999 --> 99:59:59,999
Because that is a signal that I can use,
or somebody else that understands the

102
99:59:59,999 --> 99:59:59,999
project: as said "we think that this
something that other people can use",

103
99:59:59,999 --> 99:59:59,999
or "this is a particular version we would
like other people to test".

104
99:59:59,999 --> 99:59:59,999
There are a lot of other situations where
maybe it is not so important.

105
99:59:59,999 --> 99:59:59,999
And having that be cryptographically
signed is really useful.

106
99:59:59,999 --> 99:59:59,999
I care about cryptographic signature on
software because I want to know that

107
99:59:59,999 --> 99:59:59,999
what I am running is related to the code
that somebody else out should be run.

108
99:59:59,999 --> 99:59:59,999
And if you don't verify your software
cryptographically, anyone could

109
99:59:59,999 --> 99:59:59,999
intercept the network connection
between you and that software,

110
99:59:59,999 --> 99:59:59,999
and modify the software before it gets
to you.

111
99:59:59,999 --> 99:59:59,999
And the cryptographic signature just says:

112
99:59:59,999 --> 99:59:59,999
"look, this is a version that I am OK
with. I am putting it out there and

113
99:59:59,999 --> 99:59:59,999
it comes from me".

114
99:59:59,999 --> 99:59:59,999
And so I can have a trace back to that
point.

115
99:59:59,999 --> 99:59:59,999
??? just talk about briefly about how you
do cryptographic verification of upstream.

116
99:59:59,999 --> 99:59:59,999
You might know upstream: you might know
them personally, you know their key

117
99:59:59,999 --> 99:59:59,999
already, that is fine.

118
99:59:59,999 --> 99:59:59,999
That is not the usual case: we work on
the Internet.

119
99:59:59,999 --> 99:59:59,999
In the situation where your upstream is
signing their tarballs

120
99:59:59,999 --> 99:59:59,999
and you have not met them, you do not
have to sign their key,

121
99:59:59,999 --> 99:59:59,999
you do not have to say "I announce this
is their key".

122
99:59:59,999 --> 99:59:59,999
This is probably the same one that is
signing every release,

123
99:59:59,999 --> 99:59:59,999
so you should keep track of that.

124
99:59:59,999 --> 99:59:59,999
Debian has a nice way to keep track of
that:

125
99:59:59,999 --> 99:59:59,999
you can tell Debian how to find the new
version of the upstream tarball.

126
99:59:59,999 --> 99:59:59,999
This is in the Debian 'watch' file.

127
99:59:59,999 --> 99:59:59,999
If you type 'man uscan', you can learn
more about Debian 'watch',

128
99:59:59,999 --> 99:59:59,999
and Debian 'watch' has now a feature that
lets you say

129
99:59:59,999 --> 99:59:59,999
"that is not only this way you find the
tarball,

130
99:59:59,999 --> 99:59:59,999
but upstream publishes signatures
and the signatures look like this".

131
99:59:59,999 --> 99:59:59,999
You know, they got a '.sig' at the end.

132
99:59:59,999 --> 99:59:59,999
So there is a particular arcane way to
specify that, but if you specify that,

133
99:59:59,999 --> 99:59:59,999
then 'uscan' can find not only the
upstream tarball but can find the

134
99:59:59,999 --> 99:59:59,999
upstream signature and, if you drop
upstream's signing key -

135
99:59:59,999 --> 99:59:59,999
which of course I did not put on the wiki
page, someone should add it that and

136
99:59:59,999 --> 99:59:59,999
fix it - you can put the upstream signing
key in 'debian/upstream/signing-key.asc'.

137
99:59:59,999 --> 99:59:59,999
And then if you do that, when you say
'uscan', you can tell…

138
99:59:59,999 --> 99:59:59,999
Maybe some people here do notk
now how to use 'uscan'.

139
99:59:59,999 --> 99:59:59,999
'uscan' is a very simple tool,
you run it from a software package that

140
99:59:59,999 --> 99:59:59,999
has a 'debian' directory, or even one
level up if you keep all of your software

141
99:59:59,999 --> 99:59:59,999
packages in one folder. You can go one
level up and say 'uscan', and it will look

142
99:59:59,999 --> 99:59:59,999
in all of the folder that are children
of it, and look for new version by

143
99:59:59,999 --> 99:59:59,999
trying to find for new upstreams versions
in 'debian/watch'.

144
99:59:59,999 --> 99:59:59,999
And if you have configured 'debian/watch'
properly, it can find the new upstream

145
99:59:59,999 --> 99:59:59,999
signatures, and if you have got the
'upstream/signing-key.asc', then

146
99:59:59,999 --> 99:59:59,999
it will actually verify the signature for
you as part of fetching the new

147
99:59:59,999 --> 99:59:59,999
upstream tarball.

148
99:59:59,999 --> 99:59:59,999
So you can get all of those things just
by setting ???? that way.

149
99:59:59,999 --> 99:59:59,999
There is a hand up down there, could we
get the mic down to the hand ?


150
99:59:59,999 --> 99:59:59,999
Or to the person who has that hand, it is
not just a hand. [public laugh]

151
99:59:59,999 --> 99:59:59,999
[someone] Publish a tarball and a hash, '.sha1',
and sign that hash, '.sha1.asc'.

152
99:59:59,999 --> 99:59:59,999
Can 'uscan' cope with this and check the
signature on the hash and that the hash

153
99:59:59,999 --> 99:59:59,999
belongs to that tarball ?

154
99:59:59,999 --> 99:59:59,999
[Daniel] I do not believe that 'uscan' can
do that currently. So anybody out there

155
99:59:59,999 --> 99:59:59,999
who wants to make things better for the
world should go hack on 'uscan':

156
99:59:59,999 --> 99:59:59,999
that is a pretty straightforward thing
that we should fix because I agree

157
99:59:59,999 --> 99:59:59,999
that is common pattern.

158
99:59:59,999 --> 99:59:59,999
[someone] I have no answer to this
question by I have another question:

159
99:59:59,999 --> 99:59:59,999
how do you convince upstreams who do
not release tarballs or who do

160
99:59:59,999 --> 99:59:59,999
not set tags in Git ?

161
99:59:59,999 --> 99:59:59,999
[Daniel] Who do not make tags in Git ?

162
99:59:59,999 --> 99:59:59,999
[someone] Yes, if there is no tags you
can not check out a tarball.

163
99:59:59,999 --> 99:59:59,999
Is there any good way to convince
upstream to do this ?

164
99:59:59,999 --> 99:59:59,999
[Daniel] Git has this nice feature, which
is that you can create a tag,

165
99:59:59,999 --> 99:59:59,999
which is associate with a particular
revision,

166
99:59:59,999 --> 99:59:59,999
and you would like to have a tag
everywhere that a tarball has been

167
99:59:59,999 --> 99:59:59,999
released from. I am tempted to pull up
a Git view and show people some tags.

168
99:59:59,999 --> 99:59:59,999
The question that you ask is a social
one, not just a technical one,

169
99:59:59,999 --> 99:59:59,999
and I actually find that my upstreams
are pretty responsive.

170
99:59:59,999 --> 99:59:59,999
Usually I frame my request as "hey, it
looks like you made this tarball from

171
99:59:59,999 --> 99:59:59,999
this particular commit 'id'. If you could
tag you releases, it would be really

172
99:59:59,999 --> 99:59:59,999
helpful to me, and here is the command
that I would use to tag the release".

173
99:59:59,999 --> 99:59:59,999
And I say "git tag…" and of course I
can never remember so first I look it up,

174
99:59:59,999 --> 99:59:59,999
but it is either 'tag name' 'commit id' or
'commit id' 'tag name'.

175
99:59:59,999 --> 99:59:59,999
But I would look it up and I would write
the e-mail so that all they have to do is

176
99:59:59,999 --> 99:59:59,999
they read it, understand my argument,
and execute one command.

177
99:59:59,999 --> 99:59:59,999
And then it starts them ??????

178
99:59:59,999 --> 99:59:59,999
And if you say 'tag -s' then your tag will
be cryptographically signed, which

179
99:59:59,999 --> 99:59:59,999
I think is a really good thing to do too.

180
99:59:59,999 --> 99:59:59,999
So, cryptographic verification of
upstream.

181
99:59:59,999 --> 99:59:59,999
As I said, I want to keep upstream's code
in the revision control system.

182
99:59:59,999 --> 99:59:59,999
I also like to keep…

183
99:59:59,999 --> 99:59:59,999
In my ideal case upstream is using Git:
I am using Git for packaging.

184
99:59:59,999 --> 99:59:59,999
I actually like to keep upsteam's Git
history fully in my repository,

185
99:59:59,999 --> 99:59:59,999
so that I do not just have the tarballs,
but I actually have all of their commits.

186
99:59:59,999 --> 99:59:59,999
And that turns out to be really useful
for two specific cases:

187
99:59:59,999 --> 99:59:59,999
In one case, there is a common scenario
where upstream will fix a bug,

188
99:59:59,999 --> 99:59:59,999
but they have not made a release yet.

189
99:59:59,999 --> 99:59:59,999
And that bug is really, really obviously
problematic for the folks who are

190
99:59:59,999 --> 99:59:59,999
using Debian, so want to fix it.

191
99:59:59,999 --> 99:59:59,999
All I can do, because I have their full
revision history, I can use Git to "cherry

192
99:59:59,999 --> 99:59:59,999
pick" the upstream commit.

193
99:59:59,999 --> 99:59:59,999
And then I "cherry pick" that upstream
commit and I can have it applied

194
99:59:59,999 --> 99:59:59,999
separately and release an Debian version
that has the fix, even before upstream

195
99:59:59,999 --> 99:59:59,999
has made a release with the fix.

196
99:59:59,999 --> 99:59:59,999
So one nice thing about having upstream
revision is that I can pull fixes from

197
99:59:59,999 --> 99:59:59,999
upstream before they decided
to release it.

198
99:59:59,999 --> 99:59:59,999
The other advantage is the other
way around.

199
99:59:59,999 --> 99:59:59,999
Often when I am doing packaging,
I discover a problem,

200
99:59:59,999 --> 99:59:59,999
and maybe I can fix the problem.

201
99:59:59,999 --> 99:59:59,999
And if that maybe I am already shipping
a Debian package that fixes the problem.

202
99:59:59,999 --> 99:59:59,999
If my Debian fixes can be directly applied
to upstream, then I can use whatever

203
99:59:59,999 --> 99:59:59,999
their preferred upstream patch
submission guidelines are,

204
99:59:59,999 --> 99:59:59,999
whether it is a Github pull request, or
a patch to a mailing list,

205
99:59:59,999 --> 99:59:59,999
or a "hey can you pull this from my Git
repository over here", e-mail…

206
99:59:59,999 --> 99:59:59,999
The fact that I am using the same Git
history that they are using makes it

207
99:59:59,999 --> 99:59:59,999
much easier for me to push my changes
back to them.

208
99:59:59,999 --> 99:59:59,999
So, it sort of smooth the interaction if
you can consolidate and use the same

209
99:59:59,999 --> 99:59:59,999
revision control system as their.

210
99:59:59,999 --> 99:59:59,999
Towards that aim, I use a system now
called 'patch q',

211
99:59:59,999 --> 99:59:59,999
which is part of 'git buildpackage'.

212
99:59:59,999 --> 99:59:59,999
So 'git buildpackage' is 'gbp', 'patch q'
is 'pq',

213
99:59:59,999 --> 99:59:59,999
so to deal with 'patch q' you say
'gbp pq'

214
99:59:59,999 --> 99:59:59,999
and then you have some commands.

215
99:59:59,999 --> 99:59:59,999
And what that does, is it takes…

216
99:59:59,999 --> 99:59:59,999
How many of you are Debian packagers ?

217
99:59:59,999 --> 99:59:59,999
How many of you package
software for Debian ?

218
99:59:59,999 --> 99:59:59,999
A very large percentage, but not everyone.

219
99:59:59,999 --> 99:59:59,999
I hope some folks are considering starting
packaging if you have not done it yet.

220
99:59:59,999 --> 99:59:59,999
Of those of you who package software,
how many of you package software

221
99:59:59,999 --> 99:59:59,999
with modifications, how many of you ship
a modified version of upstream sources ?

222
99:59:59,999 --> 99:59:59,999
Beyond the 'debian' directory, just Debian
patches ?

223
99:59:59,999 --> 99:59:59,999
So the common way to do that, for the
Debian 3.0 ??? packaging skill, is that in

224
99:59:59,999 --> 99:59:59,999
your 'debian' directory you have a
'patches' sub-directory that has a set of

225
99:59:59,999 --> 99:59:59,999
individual patches that apply certain
changes, and they are applied in order

226
99:59:59,999 --> 99:59:59,999
based on the file called
'debian/patches/series'.

227
99:59:59,999 --> 99:59:59,999
So maintaining that is kind of a drag
when upstream makes big changes:

228
99:59:59,999 --> 99:59:59,999
then all of sudden you have got this set
of patches and they do not quite apply…

229
99:59:59,999 --> 99:59:59,999
I is a drag even you do not have it in
the 'debian/patches/' directory.

230
99:59:59,999 --> 99:59:59,999
But what Debian 'patch q' does is it maps
that directory of patches into a little

231
99:59:59,999 --> 99:59:59,999
branch on your Git revision history.

232
99:59:59,999 --> 99:59:59,999
So when you get a new upstream version,
you can say 'patch q rebase',

233
99:59:59,999 --> 99:59:59,999
and it treats it just as Git: it takes the
'patch q'…

234
99:59:59,999 --> 99:59:59,999
You have already imported the new version,
and it re-applies your patches,

235
99:59:59,999 --> 99:59:59,999
and sometimes that means some minor
adjustments.

236
99:59:59,999 --> 99:59:59,999
Git is really good at figuring out what
the right minor adjustments are to make,

237
99:59:59,999 --> 99:59:59,999
and so all of the sudden the 'patch q' is
re-based, you refresh it in your revision

238
99:59:59,999 --> 99:59:59,999
control system, and there you go.

239
99:59:59,999 --> 99:59:59,999
So I like to use 'git-buildpackage' 'patch q',
tagging, as already brought up,

240
99:59:59,999 --> 99:59:59,999
thank you for that, I like to to tag
everything that I release,

241
99:59:59,999 --> 99:59:59,999
I like to push that as soon as I can,
so that other people who are following

242
99:59:59,999 --> 99:59:59,999
my work can now where my releases
come from.

243
99:59:59,999 --> 99:59:59,999
The reason that I like other people
following my work is

244
99:59:59,999 --> 99:59:59,999
they can fix my bugs easier.

245
99:59:59,999 --> 99:59:59,999
I make mistakes, everybody makes mistakes,
and it is really important to me that

246
99:59:59,999 --> 99:59:59,999
if someone catches one of my mistakes,
I can accept their feedback,

247
99:59:59,999 --> 99:59:59,999
their criticism, their improvements,
as easily as possible.

248
99:59:59,999 --> 99:59:59,999
I want a low barrier to entry for people
to help me fix my problems,

249
99:59:59,999 --> 99:59:59,999
it is selfishness. So I try to patch it
and publish this things for people

250
99:59:59,999 --> 99:59:59,999
can find it.

251
99:59:59,999 --> 99:59:59,999
I am ??? on these pretty fast because
were are almost at the time.


252
99:59:59,999 --> 99:59:59,999
I like to put in some place where other
people get to the them,

253
99:59:59,999 --> 99:59:59,999
at the moment I like to put them in
'collab-maint',

254
99:59:59,999 --> 99:59:59,999
it has some problems but it is better
than not publishing your stuff,

255
99:59:59,999 --> 99:59:59,999
and it is nice because it is sort of
a public use.

256
99:59:59,999 --> 99:59:59,999
I like to standardize how of my branches
are named, so if I am working on

257
99:59:59,999 --> 99:59:59,999
something that has got a stable version,
that is for Jessie, I will name the branch

258
99:59:59,999 --> 99:59:59,999
'jessie', because I ???

259
99:59:59,999 --> 99:59:59,999
???? multiple branches ???

260
99:59:59,999 --> 99:59:59,999
I try to push as frequently as I have made
something that looks sensible.

261
99:59:59,999 --> 99:59:59,999
I do not feel obliged to push my commits
to a public repository when I am still

262
99:59:59,999 --> 99:59:59,999
experimenting, I actually really like to
experiment, and I also like to keep track

263
99:59:59,999 --> 99:59:59,999
of my experiments while I am doing them.

264
99:59:59,999 --> 99:59:59,999
So I try to push when there is a sensible
set of changes, and I am trying to get

265
99:59:59,999 --> 99:59:59,999
myself to a point where I can understand
what I have done, even if it wrong.

266
99:59:59,999 --> 99:59:59,999
If I can get myself to a conceptual point
where it is done, I will push my changes

267
99:59:59,999 --> 99:59:59,999
so other people can see what I am
working on, and then work from there.

268
99:59:59,999 --> 99:59:59,999
That is OK to push something that is
wrong,

269
99:59:59,999 --> 99:59:59,999
as long as you push something that
people can understand.

270
99:59:59,999 --> 99:59:59,999
When you make a 'git commit' (if you are
working with Git),

271
99:59:59,999 --> 99:59:59,999
One of the things that helps me to think
about commit messages…

272
99:59:59,999 --> 99:59:59,999
People often think that commit messages
should say "what change you made".

273
99:59:59,999 --> 99:59:59,999
I think that the 'git patch' shows what
change what change you have made,

274
99:59:59,999 --> 99:59:59,999
and I thin your commit messages should
say "why you made the change".

275
99:59:59,999 --> 99:59:59,999
That is what people really want to read.

276
99:59:59,999 --> 99:59:59,999
If you need to explain technically why
the thing that you did

277
99:59:59,999 --> 99:59:59,999
maps to the conceptual thing that you
wanted to do, that is fine:

278
99:59:59,999 --> 99:59:59,999
do that in your commit message too.
But it is really important to say why

279
99:59:59,999 --> 99:59:59,999
you made the change. It is not just like
"initialize variable to 'no'":

280
99:59:59,999 --> 99:59:59,999
OK, we can see that from the patch,
but you what you are really saying

281
99:59:59,999 --> 99:59:59,999
is "there was a crash if someone did 'x',

282
99:59:59,999 --> 99:59:59,999
and we are avoiding that crash by
setting this to 'no'.

283
99:59:59,999 --> 99:59:59,999
So I like to send patches via email,

284
99:59:59,999 --> 99:59:59,999
so I try to configure Git email, which
make it really easy to just

285
99:59:59,999 --> 99:59:59,999
push patches back upstream.

286
99:59:59,999 --> 99:59:59,999
If I am starting taking over a project
that somebody else has past on,

287
99:59:59,999 --> 99:59:59,999
and they did not use Git, I will try to
restore all of the imports.

288
99:59:59,999 --> 99:59:59,999
I would be happy to talk with people
about how to do that,

289
99:59:59,999 --> 99:59:59,999
if you have questions come find me.

290
99:59:59,999 --> 99:59:59,999
I like to keep my files ???? simple:
there is a tool 'wrap-and-sort',

291
99:59:59,999 --> 99:59:59,999
that just canonicalizes your files to
make them look in a simple and

292
99:59:59,999 --> 99:59:59,999
sensible way. And it is nice because it
means that everything is…

293
99:59:59,999 --> 99:59:59,999
It does things like alphabetize your
list of build depends,

294
99:59:59,999 --> 99:59:59,999
and brake them out one per line.
The nice thing about that,

295
99:59:59,999 --> 99:59:59,999
since you are using revision control,
when you make a change

296
99:59:59,999 --> 99:59:59,999
to your build depends, the changes
become very easy to see:

297
99:59:59,999 --> 99:59:59,999
"oh, they added one new package here,
there is a single '+'".

298
99:59:59,999 --> 99:59:59,999
When ???? so you can see that kind of
thing.

299
99:59:59,999 --> 99:59:59,999
I like to use ? deb five ? to format
Debian copyright to be machine readable,

300
99:59:59,999 --> 99:59:59,999
it is nice for people who are doing scans
of the archive and try reason about

301
99:59:59,999 --> 99:59:59,999
what the patterns are, and licensing of
free software.

302
99:59:59,999 --> 99:59:59,999
And if I am doing something really crazy,
that is going to make a big change,

303
99:59:59,999 --> 99:59:59,999
I like to use a feature branch in
revision control.

304
99:59:59,999 --> 99:59:59,999
So we have got one minute left,
I want to open it up for other questions.

305
99:59:59,999 --> 99:59:59,999
????

306
99:59:59,999 --> 99:59:59,999
[attendee] You said you are using
'wrap-and-sort' which is nice,

307
99:59:59,999 --> 99:59:59,999
I had learned that ???? editors
- 'cme' - do the same job,

308
99:59:59,999 --> 99:59:59,999
and somehow does a better job:
it also ??? standard version

309
99:59:59,999 --> 99:59:59,999
if it does not fit, or it makes VCS
fields properly has it should be.

310
99:59:59,999 --> 99:59:59,999
'cme fix dpkg-control' fixes your
control file.

311
99:59:59,999 --> 99:59:59,999
[Daniel] 'cme' ? And it is in
what package ?

312
99:59:59,999 --> 99:59:59,999
[attendee] The package 'cme', in
unstable ????. In Jessie it is ????

313
99:59:59,999 --> 99:59:59,999
[Daniel] You are developing in unstable,
that is OK.

314
99:59:59,999 --> 99:59:59,999
'cme'
OK, thank you.

315
99:59:59,999 --> 99:59:59,999
Other questions or suggestions,
or complains ?

316
99:59:59,999 --> 99:59:59,999
[attendee] If you change the original
source code, and do some commits,

317
99:59:59,999 --> 99:59:59,999
how do you convert that into a series
of ??? patches ?

318
99:59:59,999 --> 99:59:59,999
[Daniel] I use 'patch q' for that as well,
so what I do is I say

319
99:59:59,999 --> 99:59:59,999
"I want to move over to my 'patch q'
view of the tree",

320
99:59:59,999 --> 99:59:59,999
and then I make may changes, I make
my commits,

321
99:59:59,999 --> 99:59:59,999
and then I say
'gbp pq export',

322
99:59:59,999 --> 99:59:59,999
and it takes the 'patch q' that I am on
and dumps it back

323
99:59:59,999 --> 99:59:59,999
into the Debian patches directory.

324
99:59:59,999 --> 99:59:59,999
If you have not use 'gbp pq', I
recommend looking into it.

325
99:59:59,999 --> 99:59:59,999
It takes a little while to get used to,
and I still screwed it up sometimes,

326
99:59:59,999 --> 99:59:59,999
but it makes easy to fix your
mistakes too.

327
99:59:59,999 --> 99:59:59,999
[organizer] Last question ?

328
99:59:59,999 --> 99:59:59,999
[attendee] Do you think it is possible to
make this 'patch q' branch

329
99:59:59,999 --> 99:59:59,999
"pullable" by upstream ?

330
99:59:59,999 --> 99:59:59,999
[Daniel] I do not actually think it is
possible to make it directly

331
99:59:59,999 --> 99:59:59,999
"pullable" by upstream: I think upstream
can cherry pick patches from it,

332
99:59:59,999 --> 99:59:59,999
but I do not see how to
make it "pullable".

333
99:59:59,999 --> 99:59:59,999
If someone else does, I would be
happy to learn.

334
99:59:59,999 --> 99:59:59,999
[organizer] This was "before last",
so last.

335
99:59:59,999 --> 99:59:59,999
[attendee] Do you have a recording of
you using the tools that you mentioned,

336
99:59:59,999 --> 99:59:59,999
a video recording would be great,
just to show your workflow ?

337
99:59:59,999 --> 99:59:59,999
[Daniel] I do not really know how
to do that: if somebody wants to

338
99:59:59,999 --> 99:59:59,999
help me do that I would be
happy to do it.

339
99:59:59,999 --> 99:59:59,999
I am going to give one last plug,

340
99:59:59,999 --> 99:59:59,999
I know we are out of time here,
sorry.

341
99:59:59,999 --> 99:59:59,999
This tool is called 'gitk'.

342
99:59:59,999 --> 99:59:59,999
This is an example - sorry we
should leave - but this the way

343
99:59:59,999 --> 99:59:59,999
that I visualize my revision
control system.

344
99:59:59,999 --> 99:59:59,999
We could do a whole other session
about 'gitk'.

345
99:59:59,999 --> 99:59:59,999
If you do not try to visualize your
revision control system,

346
99:59:59,999 --> 99:59:59,999
you are missing out: try to find a way
to visualize stuff,

347
99:59:59,999 --> 99:59:59,999
find one that works for you.

348
99:59:59,999 --> 99:59:59,999
Thanks for coming.

349
99:59:59,999 --> 99:59:59,999
[organizer] Thank you.