WEBVTT

00:00:00.000 --> 00:00:02.490
Thank you very much.

00:00:03.150 --> 00:00:05.060
Thanks everybody for coming,…

00:00:08.666 --> 00:00:12.186
If you are packaging software and you want
me to work on with you,

00:00:12.186 --> 00:00:13.526
this is how you can do that.

00:00:13.526 --> 00:00:15.156
It is a very self-??? talk:

00:00:15.156 --> 00:00:18.516
I just want to explain some of the things
that I like,

00:00:18.516 --> 00:00:21.366
some practice that I prefer
about Debian packaging,

00:00:21.366 --> 00:00:25.236
and I don't pretend this is any sort of…

00:00:25.236 --> 00:00:27.296
official, permanent or final thing.

00:00:27.296 --> 00:00:30.456
I just wanted to share some ideas
that I have about

00:00:30.456 --> 00:00:33.376
the way that I work with packages,
in the hope that maybe…

00:00:33.376 --> 00:00:34.616
For two hopes:

00:00:34.616 --> 00:00:38.207
One is that I hope that I can show you
something that you have not heard of,

00:00:38.207 --> 00:00:39.987
or maybe you were doing differently,

00:00:39.987 --> 00:00:42.137
or maybe you think it is
the right think to do

00:00:42.137 --> 00:00:44.467
and it is just nice to see
somebody else doing it.

00:00:44.467 --> 00:00:47.437
My second hope is that you can tell me
what I am doing wrong,

00:00:47.437 --> 00:00:51.047
and you can help me learn and improve
on my own packaging techniques.

00:00:51.047 --> 00:00:53.337
If you see something that
I am proposing up here,

00:00:53.337 --> 00:00:56.627
and you think there is a problem with it,
I would like to hear about it too.

00:00:56.627 --> 00:00:59.157
I just want to see more of the culture
within Debian,

00:00:59.157 --> 00:01:02.267
of people who are doing packaging,
explaining what they are doing,

00:01:02.267 --> 00:01:04.597
and so I thought I would
just step up and explain:

00:01:04.597 --> 00:01:06.557
"Here is some of the practice that I do",

00:01:06.557 --> 00:01:10.277
In the hope that other people will do the
same and explain what they are doing,

00:01:10.277 --> 00:01:13.047
and maybe they can learn from
me and I can learn from them.

00:01:13.047 --> 00:01:16.917
Without much further ????, I am
just going to dive into it.

00:01:16.917 --> 00:01:20.897
If you have questions, I am perfectly
happy to be interrupted,

00:01:20.897 --> 00:01:24.187
we have some folks with
walking mics in the crowd:

00:01:24.187 --> 00:01:26.517
you can just raise your hand.

00:01:26.517 --> 00:01:29.247
If you have got a question or an
interruption or whatever,

00:01:29.247 --> 00:01:30.347
that is fine.

00:01:30.347 --> 00:01:33.627
I doubt I will go the whole 15 minutes,
I think there are 20 minutes,

00:01:33.627 --> 00:01:36.217
I doubt I will go the whole time,
so there will be also

00:01:36.217 --> 00:01:38.337
time for questions at
the end if you prefer.

00:01:38.337 --> 00:01:40.137
But I do not mind being interrupted.

00:01:40.137 --> 00:01:41.977
So, this is all on this web page here,

00:01:41.977 --> 00:01:44.787
you could probably skip this talk and go
read the web page,

00:01:44.787 --> 00:01:47.227
but then you would not have the nice
??? actions,

00:01:47.227 --> 00:01:49.747
and it is easier to tell me that I am
wrong in person,

00:01:49.747 --> 00:01:51.477
so I would like to have that happen.

00:01:51.477 --> 00:01:53.427
I put this up on the Debian wiki,

00:01:53.427 --> 00:01:56.237
because I want anyone
to be able to find it.

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:

00:02:00.237 --> 00:02:05.007
other people can take advantage of the
ideas that you have got.

00:02:07.577 --> 00:02:11.087
First baseline is:
I really like revision control.

00:02:11.097 --> 00:02:14.267
And I know that it makes me
a certain flavor on nerd,

00:02:14.267 --> 00:02:19.007
but when we are working with things that
are as complicated as software packages,

00:02:19.010 --> 00:02:19.890
hmmm…

00:02:22.590 --> 00:02:25.430
I think a lot of people don't get
that in Debian you are not

00:02:25.430 --> 00:02:27.160
just working on one
software package:

00:02:27.160 --> 00:02:30.120
you are actually probably, if you
are doing a responsibly work,

00:02:30.120 --> 00:02:33.010
on at least two software packages,
and maybe 5.

00:02:33.010 --> 00:02:35.150
So you have got the version
that is unstable,

00:02:35.150 --> 00:02:39.260
and you have got the version that you
try to maintain for stable as well.

00:02:39.260 --> 00:02:45.170
And we are committing to
doing maintenance work.

00:02:45.170 --> 00:02:52.390
A lot of our work in the project is ???
in nature:

00:02:52.390 --> 00:02:55.490
we want to clean up the mess and
we want us to stay out of the way

00:02:55.490 --> 00:02:57.450
and make sure things work,
functionally,

00:02:57.450 --> 00:03:00.970
for people who are relying on the
operating system to not get in their way.

00:03:00.970 --> 00:03:04.260
So revision control I think is really
helpful because it means you can

00:03:04.260 --> 00:03:07.910
keep track of what changes you have done
on different branches of the project

00:03:07.910 --> 00:03:09.800
while you are maintaining both of them.

00:03:09.800 --> 00:03:14.440
Basically, ??? require working with
the revision system I am comfortable with,

00:03:14.440 --> 00:03:17.740
I prefer Git, I am not going to have a
religious word about it.

00:03:17.740 --> 00:03:21.290
If upstream uses Git, I am
even happier, and I try to make

00:03:21.290 --> 00:03:25.680
my packaging depend on
upstream's revision control.

00:03:29.342 --> 00:03:34.652
I like to use 'git-buildpackage', and I
like to use it with debhelper.

00:03:34.652 --> 00:03:36.793
If you have not tried out
'git-buildpackage',

00:03:36.793 --> 00:03:39.883
we are going to have a
'git-buildpackage' skill share session

00:03:39.883 --> 00:03:43.883
later on today, and I welcome you
to come and share your tricks with it,

00:03:43.883 --> 00:03:46.293
or learn some tricks from other people.

00:03:46.293 --> 00:03:50.483
It is a particular way that you can keep
your Debian packaging in a Git repository,

00:03:50.483 --> 00:03:55.893
and it helps you to keep track of all of
the changes that have happened within

00:03:55.893 --> 00:03:59.293
your packaging and within upstream to
make sure you are not accidentally

00:03:59.293 --> 00:04:00.813
making other changes.

00:04:00.813 --> 00:04:03.683
So it is very easy to go back and
review what you have done.

00:04:03.683 --> 00:04:05.883
I find that really useful.

00:04:05.883 --> 00:04:09.233
I definitely also like to keep
upstream's source code

00:04:09.233 --> 00:04:11.063
in the same revision control system.

00:04:11.063 --> 00:04:13.823
I like to keep the tarballs in the
revision control system

00:04:13.823 --> 00:04:16.033
because it means that
if someone is interested,

00:04:16.033 --> 00:04:18.243
they can uses a tool called
'debcheckout'.

00:04:18.243 --> 00:04:20.713
You can use 'debcheckout' with
a name of a package:

00:04:20.713 --> 00:04:23.383
you just say "I am really
interested in package 'foo',

00:04:23.383 --> 00:04:27.053
let me see the source code for that":
'debcheckout foo'

00:04:27.053 --> 00:04:30.373
You get the source code, and
you get the source code…

00:04:30.373 --> 00:04:32.853
from a revision control system
that you can now track

00:04:32.853 --> 00:04:36.243
and you can just propose changes on.

00:04:37.267 --> 00:04:40.987
You can also extract the tarball from that
revision control system.

00:04:40.987 --> 00:04:44.627
'debcheckout' actually works even if you
do not have upstream stuff in there,

00:04:44.627 --> 00:04:47.327
but I like to keep it all in one
revision control system,

00:04:47.327 --> 00:04:50.427
it is just easier to find everything
when you want.

00:04:50.707 --> 00:04:53.697
Some of these things that
I prefer have to do with

00:04:53.697 --> 00:04:55.847
what the upstream software
developer has done,

00:04:55.847 --> 00:04:59.587
so I am less inclined to try the package,
an upstream software project,

00:04:59.587 --> 00:05:01.777
if they just throw tarballs
here over the wall

00:05:01.777 --> 00:05:03.437
to an FTP side every now and then.

00:05:03.437 --> 00:05:06.337
It makes it more difficult for me to
know what they are doing,

00:05:06.337 --> 00:05:07.577
and why they are doing it.

00:05:07.577 --> 00:05:10.317
So i like it, I have already said,
when upstream uses Git,

00:05:10.317 --> 00:05:12.657
I also like it when upstream
signs their releases,

00:05:12.657 --> 00:05:15.217
and says "hey, this is specific release",

00:05:15.217 --> 00:05:18.767
because that is a signal
that I can use,

00:05:18.767 --> 00:05:21.887
or somebody else that
understands the project.

00:05:22.137 --> 00:05:25.427
As said, "we think that this is
something that other people can use",

00:05:25.427 --> 00:05:28.927
or "this is a particular version that
we would like other people to test".

00:05:28.927 --> 00:05:32.257
There are a lot of other situations where
maybe it is not so important.

00:05:32.257 --> 00:05:35.127
And having that be cryptographically
signed is really useful.

00:05:35.127 --> 00:05:38.727
I care about cryptographic signature on
software because I want to know that

00:05:38.727 --> 00:05:44.027
what I am running is related to the code
that somebody else out should be run.

00:05:44.027 --> 00:05:46.717
And if you don't verify your
software cryptographically,

00:05:46.717 --> 00:05:48.907
anyone who can intercept
the network connection

00:05:48.907 --> 00:05:52.520
between you and that software, can
modify the software before it gets to you.

00:05:52.520 --> 00:05:54.560
And the cryptographic signature just says:

00:05:54.560 --> 00:05:58.120
"look, this is a version
that I am OK with.

00:05:58.120 --> 00:06:00.390
I am putting it out there
and it comes from me".

00:06:00.390 --> 00:06:03.710
So I can have a trace back
to that point.

00:06:07.563 --> 00:06:11.703
??? just talk about briefly about how you
do cryptographic verification of upstream.

00:06:11.703 --> 00:06:13.313
One is you might know upstream:

00:06:13.313 --> 00:06:16.943
you might know them personally, you
know their key already, that is fine.

00:06:16.943 --> 00:06:20.523
That is not the usual case:
we work on the Internet.

00:06:20.751 --> 00:06:23.661
In the situation where your upstream
is signing their tarballs

00:06:23.661 --> 00:06:26.521
and you have not met them,
you do not have to sign their key,

00:06:26.521 --> 00:06:29.051
you do not have to say
"I announce this is their key".

00:06:29.051 --> 00:06:32.562
But it is probably the same one
that is signing every release,

00:06:32.562 --> 00:06:34.162
so you should keep track of that.

00:06:34.162 --> 00:06:37.802
Debian has a nice way to
keep track of that:

00:06:37.802 --> 00:06:41.982
you can tell Debian how to find the new
version of the upstream tarball.

00:06:41.982 --> 00:06:43.722
This is in the Debian 'watch' file.

00:06:43.722 --> 00:06:49.532
If you type 'man uscan', you can learn
more about Debian 'watch',

00:06:49.532 --> 00:06:52.092
and Debian 'watch' now has
a feature that lets you say

00:06:52.092 --> 00:06:54.772
"that is not only this way
you find the tarball,

00:06:54.772 --> 00:06:58.492
but upstream publishes signatures
and the signatures look like this".

00:06:58.492 --> 00:07:00.602
You know, they got a '.sig' at the end.

00:07:00.602 --> 00:07:04.862
So there is a particular arcane way to
specify that, but if you specify that,

00:07:04.862 --> 00:07:07.342
then 'uscan' can find
not only the upstream tarball,

00:07:07.342 --> 00:07:09.262
it can find the upstream signature.

00:07:09.262 --> 00:07:12.472
And, if you drop
upstream's signing key

00:07:12.472 --> 00:07:14.802
- which of course I did not
put on the wiki page,

00:07:14.802 --> 00:07:16.592
someone should
edit that and fix it -

00:07:16.592 --> 00:07:24.192
you can put the upstream signing
key in 'debian/upstream/signing-key.asc'.

00:07:25.982 --> 00:07:29.982
And then if you do that, when you say
'uscan', you can tell…

00:07:31.684 --> 00:07:34.214
Maybe some people here do not
know how to use 'uscan':

00:07:34.214 --> 00:07:35.644
'uscan' is a very simple tool,

00:07:35.644 --> 00:07:39.044
you run it from a software package
that has a 'debian' directory,

00:07:39.044 --> 00:07:43.084
or even one level up if you keep all of
your software packages in one folder.

00:07:43.084 --> 00:07:46.094
You can go one level up
and say 'uscan',

00:07:46.094 --> 00:07:49.594
and it will look in all of the folders
that are children of it,

00:07:49.594 --> 00:07:50.924
and look for new versions

00:07:50.924 --> 00:07:54.274
by trying to find a new upstream
version in 'debian/watch'.

00:07:54.274 --> 00:07:56.654
And if you have configured
'debian/watch' properly,

00:07:56.654 --> 00:07:58.584
it can find the new upstream signatures,

00:07:58.584 --> 00:08:02.084
and if you have got the
'upstream/signing-key.asc',

00:08:02.084 --> 00:08:04.484
then it will actually verify
the signatures for you

00:08:04.484 --> 00:08:06.674
as part of fetching the
new upstream tarball.

00:08:06.674 --> 00:08:09.784
So you can get all of those things just
by setting ???? that way.

00:08:09.784 --> 00:08:13.411
There is a hand up down there, could we
get the mic down to the hand ?


00:08:14.151 --> 00:08:15.101
Thanks.

00:08:15.101 --> 00:08:18.651
Or to the person who has that hand,
it is not just a hand.

00:08:18.651 --> 00:08:20.661
[public laugh]

00:08:21.381 --> 00:08:27.221
[attendee] Publish a tarball,
and a hash, '.sha1',

00:08:27.221 --> 00:08:31.751
and sign that hash,
'.sha1.asc'.

00:08:31.751 --> 00:08:36.137
Can 'uscan' cope with this and
check the signature on the hash

00:08:36.137 --> 00:08:38.397
and that the hash belongs
to that tarball ?

00:08:38.397 --> 00:08:41.357
[Daniel] I do not believe that 'uscan'
can do that currently.

00:08:41.357 --> 00:08:44.967
So anybody out there who wants to
make things better for the world

00:08:44.967 --> 00:08:48.067
should go hack on 'uscan': that is a
pretty straightforward thing

00:08:48.067 --> 00:08:51.137
that we should fix because
I agree that is common pattern.

00:08:53.715 --> 00:08:57.955
[attendee] I have no answer to this
question by I have another question:

00:08:57.955 --> 00:09:01.895
how do you convince upstreams
who do not release tarballs

00:09:01.895 --> 00:09:06.485
or who do not set tags in Git ?

00:09:06.485 --> 00:09:08.455
[Daniel] Who do not make tags in Git ?

00:09:08.455 --> 00:09:11.695
[someone] Yes, if there is no tags
you can not check out a tarball.

00:09:11.695 --> 00:09:15.795
Is there any good way to
convince upstream to do this ?

00:09:17.369 --> 00:09:20.849
[Daniel] Git has this nice feature, which
is that you can create a tag,

00:09:20.849 --> 00:09:23.729
which is associated with
a particular revision,

00:09:23.729 --> 00:09:26.979
and you would like to have a tag

00:09:26.979 --> 00:09:30.979
everywhere that a tarball
has been released from.

00:09:30.979 --> 00:09:34.979
I am tempted to pull up a Git
view and show people some tags.

00:09:34.979 --> 00:09:38.979
The question that you ask is a
social one, not just a technical one,

00:09:38.979 --> 00:09:42.289
and I actually find that my upstreams
are pretty responsive.

00:09:42.289 --> 00:09:44.509
Usually I frame my request as

00:09:44.509 --> 00:09:48.759
"hey, it like you made this tarball
from this particular commit 'id'.

00:09:48.759 --> 00:09:52.259
If you could tag you releases,
it would be really helpful to me,

00:09:52.259 --> 00:09:55.429
and here is the command
that I would use to tag the release".

00:09:55.429 --> 00:09:57.199
And I say "git tag…"

00:09:57.199 --> 00:09:59.939
and of course I can never
remember so first I look it up,

00:09:59.939 --> 00:10:03.039
but it is either 'tag name' 'commit id'
or 'commit id' 'tag name'.

00:10:03.039 --> 00:10:05.759
But I would look it up and
I would write the email so that

00:10:05.759 --> 00:10:07.489
all they have to do is they read it,

00:10:07.489 --> 00:10:08.599
understand my argument,

00:10:08.599 --> 00:10:09.829
and execute one command.

00:10:09.829 --> 00:10:13.299
And then it starts them ??????

00:10:16.239 --> 00:10:19.009
And if you say 'tag -s',

00:10:19.009 --> 00:10:23.179
then your tag will be
cryptographically signed,

00:10:23.179 --> 00:10:26.049
which I think is a really
good thing to do too.

00:10:27.179 --> 00:10:29.299
So, cryptographic verification
of upstream.

00:10:29.299 --> 00:10:33.649
As I said, I want to keep upstream's code
in the revision control system.

00:10:33.649 --> 00:10:35.559
I also like to keep…

00:10:35.559 --> 00:10:38.975
In my ideal case upstream is using Git:
I am using Git for packaging.

00:10:38.975 --> 00:10:44.575
I actually like to keep upsteam's Git
history fully in my repository,

00:10:44.575 --> 00:10:48.705
so that I do not just have the tarballs,
but I actually have all of their commits.

00:10:48.705 --> 00:10:52.137
And that turns out to be really useful
for two specific cases:

00:10:52.137 --> 00:10:55.557
In one case, there is a common scenario
where upstream will fix a bug,

00:10:55.557 --> 00:10:57.667
but they have not made a release yet.

00:10:57.667 --> 00:11:00.417
And that bug is really,
really obviously problematic

00:11:00.417 --> 00:11:02.197
for the folks who are using Debian,


00:11:02.197 --> 00:11:03.457
so I want to fix it.

00:11:03.457 --> 00:11:06.407
All I can do, because I have
their full revision history,

00:11:06.407 --> 00:11:10.477
I can use Git to "cherry pick"
the upstream commit.

00:11:10.477 --> 00:11:12.577
And then I "cherry pick"
that upstream commit

00:11:12.577 --> 00:11:14.767
and I can have it applied separately,

00:11:14.767 --> 00:11:17.107
and release a Debian version
that has the fix,

00:11:17.107 --> 00:11:19.747
even before upstream has made
a release with the fix.

00:11:19.747 --> 00:11:22.777
So one nice thing about
having upstream revision

00:11:22.777 --> 00:11:28.667
is that I can pull fixes from upstream
before they decided to release it.

00:11:28.667 --> 00:11:32.667
The other advantage is the other
way around.

00:11:32.667 --> 00:11:35.517
Often when I am doing packaging,
I discover a problem,

00:11:35.517 --> 00:11:37.787
and maybe I can fix the problem.

00:11:37.787 --> 00:11:41.787
And if that maybe I am already shipping
a Debian package that fixes the problem.

00:11:41.787 --> 00:11:45.027
If my Debian fixes can be
directly applied to upstream,

00:11:45.027 --> 00:11:50.017
then I can use whatever their preferred
upstream patch submission guidelines are,

00:11:50.017 --> 00:11:53.677
whether it is a Github pull request,
or a patch to a mailing list,

00:11:53.677 --> 00:11:58.377
or a "hey can you pull this from my Git
repository over here", e-mail…

00:11:58.377 --> 00:12:01.590
The fact that I am using the same
Git history that they are using

00:12:01.590 --> 00:12:05.520
makes it much easier for me
to push my changes back to them.

00:12:05.520 --> 00:12:09.311
So, it sort of smooths the interaction
if you can consolidate

00:12:09.311 --> 00:12:13.441
and use the same revision control
system as their.

00:12:13.441 --> 00:12:14.661
Towards that aim,

00:12:14.661 --> 00:12:16.691
I use a system now
called 'patch q',

00:12:16.691 --> 00:12:19.141
which is part of 'git-buildpackage'.

00:12:19.141 --> 00:12:21.521
So 'git buildpackage' is 'gbp',

00:12:21.521 --> 00:12:23.321
'patch q' is 'pq',

00:12:23.321 --> 00:12:28.784
so to deal with 'patch q'
you say 'gbp pq'

00:12:28.784 --> 00:12:30.644
and then you have some commands.

00:12:30.644 --> 00:12:34.067
And what that does, is it takes…

00:12:34.067 --> 00:12:36.087
How many of you are Debian packagers ?

00:12:36.087 --> 00:12:38.187
How many of you package
software for Debian ?

00:12:38.187 --> 00:12:40.097
[most attendees raise their hand]

00:12:40.097 --> 00:12:42.097
A very large percentage, but not everyone.

00:12:42.097 --> 00:12:46.557
I hope some folks are considering starting
packaging if you have not done it yet.

00:12:46.557 --> 00:12:48.617
Of those of you who package software,

00:12:48.617 --> 00:12:51.057
how many of you package software
with modifications,

00:12:51.057 --> 00:12:53.917
how many of you ship a
modified version of upstream sources ?

00:12:53.917 --> 00:12:55.597
[most attendees raise their hand]

00:12:55.597 --> 00:12:58.427
Beyond the 'debian' directory,
just Debian patches ?

00:12:58.427 --> 00:13:00.757
So the common way to do that,

00:13:00.757 --> 00:13:03.407
for the Debian 3.0 ???
packaging skill,

00:13:03.407 --> 00:13:07.088
is that in your 'debian' directory you
have a 'patches' sub-directory

00:13:07.088 --> 00:13:11.038
that has a set of individual patches
that apply certain changes,

00:13:11.038 --> 00:13:15.971
and they are applied in order based on
the file called 'debian/patches/series'.

00:13:15.971 --> 00:13:20.659
So maintaining that is kind of a drag
when upstream makes big changes:

00:13:20.659 --> 00:13:24.449
then all of sudden you have got this set
of patches and they do not quite apply…

00:13:24.449 --> 00:13:28.424
It is a drag even you do not have it
in the 'debian/patches/' directory.

00:13:28.424 --> 00:13:33.984
But what Debian 'patch q' does is
it maps that directory of patches

00:13:33.984 --> 00:13:38.314
into a little branch on your
Git revision history.

00:13:38.314 --> 00:13:43.164
So when you get a new upstream version,
you can say 'patch q rebase',

00:13:43.164 --> 00:13:47.067
and it treats it just as Git:
it takes the 'patch q'…

00:13:47.067 --> 00:13:51.537
You have already imported the new version,
and it re-applies your patches,

00:13:51.537 --> 00:13:53.777
and sometimes that means
some minor adjustments.

00:13:53.787 --> 00:13:58.417
Git is really good at figuring out what
the right minor adjustments are to make,

00:13:58.417 --> 00:14:01.587
and so all of the sudden
the 'patch q' is re-based,

00:14:01.587 --> 00:14:05.587
you refresh it in your revision
control system…

00:14:05.587 --> 00:14:08.217
and there you go.

00:14:08.217 --> 00:14:11.810
So I like to use
'git-buildpackage' 'patch q',

00:14:11.810 --> 00:14:14.830
tagging, as already brought up,
thank you for that,

00:14:14.830 --> 00:14:17.010
I like to to tag
everything that I release,

00:14:17.010 --> 00:14:18.730
I like to push that
as soon as I can,

00:14:18.730 --> 00:14:21.740
so that other people
who are following my work

00:14:21.740 --> 00:14:24.780
can know where my releases
come from.

00:14:24.780 --> 00:14:27.430
The reason that I like other people
following my work is

00:14:27.430 --> 00:14:30.616
they can fix my bugs easier.

00:14:30.616 --> 00:14:32.636
I make mistakes,
everybody makes mistakes,

00:14:32.636 --> 00:14:36.220
and it is really important to me that
if someone catches one of my mistakes,

00:14:36.220 --> 00:14:39.416
I can accept their feedback,
their criticism, their improvements,

00:14:39.416 --> 00:14:41.226
as easily as possible.

00:14:41.226 --> 00:14:45.606
I want a low barrier to entry for people
to help me fix my problems:

00:14:45.606 --> 00:14:46.826
it is selfishness.

00:14:46.826 --> 00:14:50.576
So I try to patch it and publish these
things for people can find it.

00:14:50.576 --> 00:14:54.326
I am ??? on these pretty fast because
were are almost at the time.


00:14:54.326 --> 00:14:57.656
I like to put my repo in some place
where other people get to the them,

00:14:57.656 --> 00:15:00.346
at the moment I like to put them in
'collab-maint',

00:15:00.346 --> 00:15:03.636
it has some problems but it is better
than not publishing your stuff,

00:15:03.636 --> 00:15:06.501
and it is nice because it is sort of
a public use.

00:15:07.777 --> 00:15:10.167
I like to standardize how of
my branches are named,

00:15:10.167 --> 00:15:13.187
so if I am working on something
that has got a stable version,

00:15:13.187 --> 00:15:15.697
that is for Jessie, I will
name the branch 'jessie',

00:15:15.697 --> 00:15:21.317
because I ???
???? multiple branches ???

00:15:21.317 --> 00:15:26.147
I try to push as frequently as I have made
something that looks sensible.

00:15:26.147 --> 00:15:29.737
I do not feel obliged to push
my commits to a public repository

00:15:29.737 --> 00:15:31.347
when I am still experimenting,

00:15:31.347 --> 00:15:33.167
I actually really like to
experiment,

00:15:33.167 --> 00:15:36.847
and I also like to keep track of my
experiments while I am doing them.

00:15:36.847 --> 00:15:40.067
So I try to push when there is
a sensible set of changes,

00:15:40.067 --> 00:15:41.917
and I am trying to get myself

00:15:41.917 --> 00:15:45.317
to a point where I can understand
what I have done, even if it is wrong.

00:15:45.317 --> 00:15:48.097
If I can get myself to a conceptual
point where it is done,

00:15:48.097 --> 00:15:51.287
I will push my changes so other people
can see what I am working on,

00:15:51.287 --> 00:15:52.627
and then work from there.

00:15:52.627 --> 00:15:54.877
That is OK to push something
that is wrong,

00:15:54.877 --> 00:15:57.907
as long as you push something that
people can understand.

00:15:57.907 --> 00:16:01.277
When you make a 'git commit'
(if you are working with Git),

00:16:01.277 --> 00:16:05.167
one of the things that helps me to think
about commit messages…

00:16:05.167 --> 00:16:08.637
People often think that commit messages
should say "what change you made".

00:16:08.647 --> 00:16:12.117
I think that the 'git patch' shows what
change what change you have made,

00:16:12.117 --> 00:16:16.677
and I thin your commit messages should
say "why you made the change".

00:16:16.677 --> 00:16:19.017
That is what people really want to read.

00:16:19.017 --> 00:16:22.977
If you need to explain technically
why the thing that you did

00:16:22.977 --> 00:16:25.677
maps to the conceptual thing
that you wanted to do,

00:16:25.677 --> 00:16:28.117
that is fine: do that in
your commit message too.

00:16:28.117 --> 00:16:31.067
But it is really important to say
why you made the change.

00:16:31.067 --> 00:16:34.287
It is not just like
"initialize variable to 'no'":

00:16:34.287 --> 00:16:36.405
OK, we can see that from the patch,

00:16:36.405 --> 00:16:39.815
but what you are really saying is
"there was a crash if someone did 'x',

00:16:39.815 --> 00:16:43.925
and we are avoiding that crash by
setting this to 'no'.

00:16:43.925 --> 00:16:46.345
So I like to send patches via email,

00:16:46.345 --> 00:16:47.985
so I try to configure Git email,

00:16:47.985 --> 00:16:51.565
which make it really easy to just
push patches back upstream.

00:16:51.565 --> 00:16:55.195
If I am starting taking over a project
that somebody else has past on,

00:16:55.195 --> 00:16:58.345
and they did not use Git,
I will try to restore all of the imports.

00:16:58.345 --> 00:17:01.065
I would be happy to talk with people
about how to do that,

00:17:01.065 --> 00:17:02.795
if you have questions come find me.

00:17:02.795 --> 00:17:04.525
I like to keep my files ???? simple:

00:17:04.525 --> 00:17:09.965
there is a tool 'wrap-and-sort',

00:17:09.965 --> 00:17:13.585
that just canonicalizes your files
to make them look

00:17:13.585 --> 00:17:16.395
in a simple and sensible way.

00:17:16.395 --> 00:17:20.575
And it is nice because it
means that everything is…

00:17:20.575 --> 00:17:23.675
It does things like alphabetize
your list of build depends,

00:17:23.675 --> 00:17:25.555
and brake them out one per line.

00:17:25.555 --> 00:17:29.054
The nice thing about that,
since you are using revision control,

00:17:29.054 --> 00:17:31.284
when you make a change
to your build depends,

00:17:31.284 --> 00:17:32.954
the changes become
very easy to see:

00:17:32.954 --> 00:17:36.371
"oh, they added one new package here,
there is a single '+'".

00:17:36.371 --> 00:17:40.051
When ????
so you can see that kind of thing.

00:17:40.051 --> 00:17:44.851
I like to use ??? deb five ??? to format
Debian copyright to be machine readable,

00:17:44.851 --> 00:17:47.701
it is nice for people who are
doing scans of the archive

00:17:47.701 --> 00:17:49.791
and try reason about
what the patterns are,

00:17:49.791 --> 00:17:51.275
and licensing of free software.

00:17:51.275 --> 00:17:54.905
And if I am doing something really crazy,
that is going to make a big change,

00:17:54.905 --> 00:17:57.325
I like to use a feature branch in
revision control.

00:17:57.325 --> 00:18:01.705
So we have got one minute left,
I want to open it up for other questions.

00:18:01.705 --> 00:18:05.705
????

00:18:10.330 --> 00:18:13.764
[attendee] You said you are using
'wrap-and-sort' which is nice,

00:18:13.764 --> 00:18:18.931
I had learned that ???? editors
- 'cme' - do the same job,

00:18:18.931 --> 00:18:25.541
and somehow does a better job:
it also ??? standard version

00:18:25.541 --> 00:18:31.191
if it does not fit, or it makes VCS
fields properly has it should be.

00:18:31.191 --> 00:18:36.761
'cme fix dpkg-control' fixes your
control file.

00:18:36.761 --> 00:18:40.491
[Daniel] 'cme' ? And it is in
what package ?

00:18:40.491 --> 00:18:45.331
[attendee] The package 'cme', in
unstable ????. In Jessie it is ????

00:18:45.331 --> 00:18:47.763
[Daniel] You are developing in unstable,
that is OK.

00:18:47.763 --> 00:18:49.783
'cme'
OK, thank you.

00:18:49.783 --> 00:18:53.381
Other questions or suggestions,
or complains ?

00:18:56.793 --> 00:19:01.664
[attendee] If you change the original
source code, and do some commits,

00:19:01.664 --> 00:19:06.814
how do you convert that into a series
of ??? patches ?

00:19:06.818 --> 00:19:09.838
[Daniel] I use 'patch q' for that as well,
so what I do is I say

00:19:09.838 --> 00:19:12.788
"I want to move over to my 'patch q'
view of the tree",

00:19:12.788 --> 00:19:15.028
and then I make may changes, I make
my commits,

00:19:15.028 --> 00:19:18.058
and then I say
'gbp pq export',

00:19:18.058 --> 00:19:19.733
so that 'patch q export',

00:19:19.733 --> 00:19:21.563
and it takes the 'patch q'
that I am on

00:19:21.563 --> 00:19:24.263
and dumps it back into
the Debian patches directory.

00:19:24.263 --> 00:19:28.263
If you have not use 'gbp pq', I
recommend looking into it.

00:19:28.263 --> 00:19:31.913
It takes a little while to get used to,
and I still screwed it up sometimes,

00:19:31.913 --> 00:19:34.433
but it makes easy to fix your
mistakes too.

00:19:34.433 --> 00:19:36.833
[organizer] Last question ?

00:19:36.833 --> 00:19:38.673
[attendee] Do you think it is possible

00:19:38.673 --> 00:19:42.473
to make this 'patch q' branch
"pullable" by upstream ?

00:19:45.846 --> 00:19:49.056
[Daniel] I do not actually think it is
possible to make it directly

00:19:49.056 --> 00:19:52.536
"pullable" by upstream: I think upstream
can cherry pick patches from it,

00:19:52.536 --> 00:19:54.886
but I do not see how to
make it "pullable".

00:19:54.886 --> 00:19:58.156
If someone else does, I would be
happy to learn.

00:19:58.691 --> 00:20:02.721
[organizer] This was "before last",
so last.

00:20:02.721 --> 00:20:07.601
[attendee] Do you have a recording of
you using the tools that you mentioned,

00:20:07.601 --> 00:20:12.151
a video recording would be great,
just to show your workflow ?

00:20:12.151 --> 00:20:15.441
[Daniel] I do not really know how
to do that:

00:20:15.441 --> 00:20:20.321
if somebody wants to help me do that
I would be happy to do it.

00:20:20.321 --> 00:20:22.311
I am going to give one last plug,

00:20:22.311 --> 00:20:25.595
I know we are out of time here,
sorry.

00:20:25.595 --> 00:20:28.795
This tool is called 'gitk'.

00:20:28.795 --> 00:20:31.105
This is an example…

00:20:31.105 --> 00:20:32.415
- sorry we should leave -

00:20:32.415 --> 00:20:35.965
but this the way that I visualize
my revision control system.

00:20:35.965 --> 00:20:38.195
We could do a whole other session
about 'gitk'.

00:20:38.195 --> 00:20:41.045
If you do not try to visualize your
revision control system,

00:20:41.045 --> 00:20:42.085
you are missing out:

00:20:42.085 --> 00:20:44.385
I recommend try to find a way
to visualize stuff,

00:20:44.385 --> 00:20:45.725
find one that works for you.

00:20:45.725 --> 00:20:46.725
Thanks for coming.

00:20:46.725 --> 00:20:48.835
[organizer] Thank you.