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 the way that I work with

00:00:30.456 --> 00:00:34.976
packages, in the hope that maybe, hmm,
for two hopes:

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,

00:00:38.057 --> 00:00:40.677
or maybe you were doing differently,

00:00:40.677 --> 00:00:42.417
or maybe you think it is
the right think to do

00:00:42.417 --> 00:00:43.877
and it is just nice to see
somebody else doing it.

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

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

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

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.

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

00:00:58.237 --> 00:01:00.627
of people who are doing packaging,
explaining what they are doing,

00:01:00.627 --> 00:01:02.787
and so I thought I would
just step up and explain:

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

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

00:01:08.717 --> 00:01:12.207
and maybe they can learn from
me and I can learn from them.

00:01:12.207 --> 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.687
you can just raise your hand.

00:01:26.687 --> 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.037
I doubt I will go the whole 15 minutes,
I think there are 20 minutes,

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

00:01:35.177 --> 00:01:36.897
time for questions at
the end if you prefer.

00:01:36.897 --> 00:01:38.697
But I do not mind being interrupted.

00:01:38.697 --> 00:01:42.787
So, this is all on this web page here,

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

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

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

00:01:48.857 --> 00:01:51.397
so I would like to have that happen.

00:01:51.397 --> 00:01:53.447
I put this up on the Debian wiki,

00:01:53.447 --> 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:23.370 --> 00:02:25.670
I think a lot of people don't get
that in Debian you are not

00:02:25.670 --> 00:02:27.610
just working on one
software package:

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

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

00:02:33.110 --> 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.500
A lot of our work in the project is ???
in nature:

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

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

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

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

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

00:03:07.670 --> 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.812
I like to use 'git-buildpackage', and I
like to use it with debhelper.

00:03:34.812 --> 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 actually, 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:56.223
and it helps you to keep track of all of
the changes that have happened within

00:03:56.223 --> 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.193
So it is very easy to go back and
review what you have done.

00:04:03.193 --> 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.213
in the same revision control system.

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

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

00:04:15.713 --> 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.797
'debcheckout' actually works even if you
do not have upstream stuff in there,

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

00:04:47.527 --> 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:02.017
if they just throw tarballs
here over the wall

00:05:02.017 --> 00:05:03.827
to an FTP side every now and then.

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

00:05:06.287 --> 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.457
and says "hey, this is specific release",

00:05:15.457 --> 00:05:18.607
because that is a signal
that I can use,


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

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

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

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

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

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

00:05:38.257 --> 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.977
anyone who can intercept
the network connection

00:05:48.977 --> 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.300
And the cryptographic signature just says:

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

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

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

00:06:08.433 --> 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:21.211 --> 00:06:23.741
In the situation where your upstream
is signing their tarballs

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

00:06:26.501 --> 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.092
so you should keep track of that.

00:06:34.092 --> 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.582
If you type 'man uscan', you can learn
more about Debian 'watch',

00:06:49.582 --> 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.572
And, if you drop
upstream's signing key

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

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

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

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

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

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

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

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
upstream tarball.

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

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


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

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

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

99:59:59.999 --> 99:59:59.999
belongs to that tarball ?

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

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

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

99:59:59.999 --> 99:59:59.999
that is common pattern.

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

99:59:59.999 --> 99:59:59.999
how do you convince upstreams who do
not release tarballs or who do

99:59:59.999 --> 99:59:59.999
not set tags in Git ?

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

99:59:59.999 --> 99:59:59.999
And then it starts them ??????

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

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

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

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

99:59:59.999 --> 99:59:59.999
I also like to keep…

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

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

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.

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

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

99:59:59.999 --> 99:59:59.999
but they have not made a release yet.

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

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

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

99:59:59.999 --> 99:59:59.999
pick" the upstream commit.

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

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

99:59:59.999 --> 99:59:59.999
has made a release with the fix.

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

99:59:59.999 --> 99:59:59.999
upstream before they decided
to release it.

99:59:59.999 --> 99:59:59.999
The other advantage is the other
way around.

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

99:59:59.999 --> 99:59:59.999
and maybe I can fix the problem.

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

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

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
revision control system as their.

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

99:59:59.999 --> 99:59:59.999
which is part of 'git buildpackage'.

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

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

99:59:59.999 --> 99:59:59.999
and then you have some commands.

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

99:59:59.999 --> 99:59:59.999
How many of you are Debian packagers ?

99:59:59.999 --> 99:59:59.999
How many of you package
software for Debian ?

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

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

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

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

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

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

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

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

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

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

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…

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

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

99:59:59.999 --> 99:59:59.999
branch on your Git revision history.

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

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

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

99:59:59.999 --> 99:59:59.999
and sometimes that means some minor
adjustments.

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
my work can now where my releases
come from.

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

99:59:59.999 --> 99:59:59.999
they can fix my bugs easier.

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
can find it.

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


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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
'jessie', because I ???

99:59:59.999 --> 99:59:59.999
???? multiple branches ???

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

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

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

99:59:59.999 --> 99:59:59.999
of my experiments while I am doing them.

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
as long as you push something that
people can understand.

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
That is what people really want to read.

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

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

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

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
push patches back upstream.

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

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

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

99:59:59.999 --> 99:59:59.999
if you have questions come find me.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
????

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

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

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

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

99:59:59.999 --> 99:59:59.999
'cme fix dpkg-control' fixes your
control file.

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

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

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

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

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

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

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
into the Debian patches directory.

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

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

99:59:59.999 --> 99:59:59.999
but it makes easy to fix your
mistakes too.

99:59:59.999 --> 99:59:59.999
[organizer] Last question ?

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

99:59:59.999 --> 99:59:59.999
"pullable" by upstream ?

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

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

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

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

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

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

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

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

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

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

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

99:59:59.999 --> 99:59:59.999
This tool is called 'gitk'.

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

99:59:59.999 --> 99:59:59.999
that I visualize my revision
control system.

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

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

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

99:59:59.999 --> 99:59:59.999
find one that works for you.

99:59:59.999 --> 99:59:59.999
Thanks for coming.

99:59:59.999 --> 99:59:59.999
[organizer] Thank you.