1
99:59:59,999 --> 99:59:59,999
Thank you very much.

2
99:59:59,999 --> 99:59:59,999
Thanks everybody for coming,…

3
99:59:59,999 --> 99:59:59,999
If you are packaging software and you want
me to work on with you,

4
99:59:59,999 --> 99:59:59,999
this is how you can do that.

5
99:59:59,999 --> 99:59:59,999
It is a very self-??? talk:

6
99:59:59,999 --> 99:59:59,999
I just want to explain some of the things
that I like,

7
99:59:59,999 --> 99:59:59,999
some practice that I prefer about Debian
packaging,

8
99:59:59,999 --> 99:59:59,999
and I don't pretend this is any sort of
official,

9
99:59:59,999 --> 99:59:59,999
permanent or final thing.

10
99:59:59,999 --> 99:59:59,999
I just wanted to share some ideas that I
have about the way that I work with

11
99:59:59,999 --> 99:59:59,999
packages, in the hope that maybe, hmm,
for two hopes:

12
99:59:59,999 --> 99:59:59,999
One is that I hope that I can show you
something that you have not heard of,

13
99:59:59,999 --> 99:59:59,999
or maybe you were doing differently,

14
99:59:59,999 --> 99:59:59,999
or maybe you think it is the right think
to do and it is just nice to see somebody

15
99:59:59,999 --> 99:59:59,999
somebody else doing it.

16
99:59:59,999 --> 99:59:59,999
My second hope is that you can tell me
what I am doing wrong,

17
99:59:59,999 --> 99:59:59,999
and you can help me learn and improve
on my own packaging techniques.

18
99:59:59,999 --> 99:59:59,999
If you see something that I am proposing
up here,

19
99:59:59,999 --> 99:59:59,999
and you think there is a problem with it,
I would like to hear about it too.

20
99:59:59,999 --> 99:59:59,999
I just want to see more of the culture
within Debian,

21
99:59:59,999 --> 99:59:59,999
of people who are doing packaging,
explaining what they are doing,

22
99:59:59,999 --> 99:59:59,999
and so I thought I would just step up and
explain:

23
99:59:59,999 --> 99:59:59,999
"Here is some of the practice that I do",

24
99:59:59,999 --> 99:59:59,999
In the hope that other people will do the
same and explain what they are doing,

25
99:59:59,999 --> 99:59:59,999
and maybe they can learn from me and
I can learn from them.

26
99:59:59,999 --> 99:59:59,999
Without much further ????, I am just going
to dive into it.

27
99:59:59,999 --> 99:59:59,999
If you have questions, I am perfectly
happy to be interrupted,

28
99:59:59,999 --> 99:59:59,999
we have some folks with walking mics
in the crowd:

29
99:59:59,999 --> 99:59:59,999
you can just raise your hand.

30
99:59:59,999 --> 99:59:59,999
I you have got a question or an
interruption or whatever,

31
99:59:59,999 --> 99:59:59,999
that is fine.

32
99:59:59,999 --> 99:59:59,999
I ??? I got the whole 15 minutes,
I think there are 20 minutes,

33
99:59:59,999 --> 99:59:59,999
I ??? the whole time, so there will be
also time for questions at the end

34
99:59:59,999 --> 99:59:59,999
if you prefer.

35
99:59:59,999 --> 99:59:59,999
But I do not mind being interrupted.

36
99:59:59,999 --> 99:59:59,999
So, this is all on this web page here,

37
99:59:59,999 --> 99:59:59,999
you could probably skip this talk and go
read the web page,

38
99:59:59,999 --> 99:59:59,999
but then you would not have the nice
??? actions,

39
99:59:59,999 --> 99:59:59,999
and it is easier to tell me that I am
wrong in person,

40
99:59:59,999 --> 99:59:59,999
so I would like to have that happen.

41
99:59:59,999 --> 99:59:59,999
I put this up on the Debian wiki,

42
99:59:59,999 --> 99:59:59,999
because I want anyone to be able to find
it.

43
99:59:59,999 --> 99:59:59,999
If you thing you have got some good ideas,
you should put it on the Debian Wiki too:

44
99:59:59,999 --> 99:59:59,999
other people can take advantage of the
ideas that you have got.

45
99:59:59,999 --> 99:59:59,999
First baseline is: I really like revision
control.

46
99:59:59,999 --> 99:59:59,999
And I know that it makes me a certain
flavor on nerd,

47
99:59:59,999 --> 99:59:59,999
but when we are working with things that
are as complicated as software packages,

48
99:59:59,999 --> 99:59:59,999
hmmm, I think a lot of people don't get
that in Debian we are not just working on

49
99:59:59,999 --> 99:59:59,999
one software package:

50
99:59:59,999 --> 99:59:59,999
you are actually probably, if you are doing
a responsibly work,

51
99:59:59,999 --> 99:59:59,999
on at least two software packages, and
maybe 5.

52
99:59:59,999 --> 99:59:59,999
So you have got the version that is
unstable and you have got

53
99:59:59,999 --> 99:59:59,999
the version that you try to maintain for
stable as well.

54
99:59:59,999 --> 99:59:59,999
And we are committing to doing maintenance
work.

55
99:59:59,999 --> 99:59:59,999
A lot of our work in the project is ???
in nature:

56
99:59:59,999 --> 99:59:59,999
we want to clean up the mess and we want
us to stay out of the way and

57
99:59:59,999 --> 99:59:59,999
to make sure things work, functionally,


58
99:59:59,999 --> 99:59:59,999
for people who are relying on the
operating system to not get in their way.

59
99:59:59,999 --> 99:59:59,999
So revision control I think is really
helpful because it means you can

60
99:59:59,999 --> 99:59:59,999
keep track of what changes you have done
on different branches of the project

61
99:59:59,999 --> 99:59:59,999
while you are maintaining both of them.

62
99:59:59,999 --> 99:59:59,999
Basically, ??? require working with
the revision system I am comfortable with,

63
99:59:59,999 --> 99:59:59,999
I prefer Git, I am not going to have a
religious word about it.

64
99:59:59,999 --> 99:59:59,999
If upstream uses Git, I am even happier,
and I try to make my packaging depend on

65
99:59:59,999 --> 99:59:59,999
upstream's revision control.

66
99:59:59,999 --> 99:59:59,999
I like to use 'git-buildpackage', and I
like to use it with debhelper.

67
99:59:59,999 --> 99:59:59,999
If you have not tried out
'git-buildpackage',

68
99:59:59,999 --> 99:59:59,999
we are going to have a
'git-buildpackage' skill share session

69
99:59:59,999 --> 99:59:59,999
later on today actually, and I welcome
you to come and share your tricks with it,

70
99:59:59,999 --> 99:59:59,999
or learn some tricks from other people.

71
99:59:59,999 --> 99:59:59,999
It is a particular way that you can keep
your Debian packaging in a Git repository,

72
99:59:59,999 --> 99:59:59,999
and it helps you to keep track of all of
the changes that ave happened within

73
99:59:59,999 --> 99:59:59,999
your packaging and within upstream to
make sure you are not accidentally

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

111
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

134
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

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

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

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

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

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

140
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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

172
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,

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

174
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

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

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

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

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

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

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

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

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

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

184
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.

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

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

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

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

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

190
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

222
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

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

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

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

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

227
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…

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

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

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

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

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

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

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

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

236
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

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

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

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

240
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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

260
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

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

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

263
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

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

265
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

305
99:59:59,999 --> 99:59:59,999
[attendee]