0:00:00.000,0:00:02.490
Thank you very much.

0:00:03.150,0:00:05.060
Thanks everybody for coming,…

0:00:08.666,0:00:12.186
If you are packaging software and you want[br]me to work on with you,

0:00:12.186,0:00:13.526
this is how you can do that.

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

0:00:15.156,0:00:18.516
I just want to explain some of the things[br]that I like,

0:00:18.516,0:00:21.366
some practice that I prefer about Debian[br]packaging,

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

0:00:25.236,0:00:27.296
official, permanent or final thing.

0:00:27.296,0:00:30.456
I just wanted to share some ideas that I[br]have about the way that I work with

0:00:30.456,0:00:34.976
packages, in the hope that maybe, hmm,[br]for two hopes:

0:00:34.976,0:00:38.057
One is that I hope that I can show you[br]something that you have not heard of,

0:00:38.057,0:00:40.677
or maybe you were doing differently,

0:00:40.677,0:00:42.417
or maybe you think it is[br]the right think to do

0:00:42.417,0:00:43.877
and it is just nice to see[br]somebody else doing it.

0:00:43.877,0:00:47.047
My second hope is that you can tell me[br]what I am doing wrong,

0:00:47.047,0:00:51.047
and you can help me learn and improve[br]on my own packaging techniques.

0:00:51.047,0:00:52.907
If you see something that[br]I am proposing up here,

0:00:52.907,0:00:55.507
and you think there is a problem with it,[br]I would like to hear about it too.

0:00:55.507,0:00:58.227
I just want to see more of the culture[br]within Debian,

0:00:58.237,0:01:00.627
of people who are doing packaging,[br]explaining what they are doing,

0:01:00.627,0:01:02.787
and so I thought I would[br]just step up and explain:

0:01:02.787,0:01:04.497
"Here is some of the practice that I do",

0:01:04.497,0:01:08.717
In the hope that other people will do the[br]same and explain what they are doing,

0:01:08.717,0:01:12.207
and maybe they can learn from[br]me and I can learn from them.

0:01:12.207,0:01:16.917
Without much further ????, I am[br]just going to dive into it.

0:01:16.917,0:01:20.897
If you have questions, I am perfectly[br]happy to be interrupted,

0:01:20.897,0:01:24.187
we have some folks with walking mics[br]in the crowd:

0:01:24.187,0:01:26.687
you can just raise your hand.

0:01:26.687,0:01:29.247
If you have got a question or an[br]interruption or whatever,

0:01:29.247,0:01:30.347
that is fine.

0:01:30.347,0:01:33.037
I doubt I will go the whole 15 minutes,[br]I think there are 20 minutes,

0:01:33.037,0:01:35.177
I doubt I will go the whole time,[br]so there will be also

0:01:35.177,0:01:36.897
time for questions at[br]the end if you prefer.

0:01:36.897,0:01:38.697
But I do not mind being interrupted.

0:01:38.697,0:01:42.787
So, this is all on this web page here,

0:01:42.787,0:01:44.787
you could probably skip this talk and go[br]read the web page,

0:01:44.787,0:01:46.857
but then you would not have the nice[br]??? actions,

0:01:46.857,0:01:48.857
and it is easier to tell me that I am[br]wrong in person,

0:01:48.857,0:01:51.397
so I would like to have that happen.

0:01:51.397,0:01:53.447
I put this up on the Debian wiki,

0:01:53.447,0:01:56.237
because I want anyone[br]to be able to find it.

0:01:56.237,0:02:00.237
If you think you have got some good ideas,[br]you should put it on the Debian Wiki too:

0:02:00.237,0:02:05.007
other people can take advantage of the[br]ideas that you have got.

0:02:07.577,0:02:11.087
First baseline is:[br]I really like revision control.

0:02:11.097,0:02:14.267
And I know that it makes me[br]a certain flavor on nerd,

0:02:14.267,0:02:19.007
but when we are working with things that[br]are as complicated as software packages,

0:02:19.010,0:02:19.890
hmmm…

0:02:23.370,0:02:25.670
I think a lot of people don't get[br]that in Debian you are not

0:02:25.670,0:02:27.610
just working on one[br]software package:

0:02:27.610,0:02:30.120
you are actually probably, if you[br]are doing a responsibly work,

0:02:30.120,0:02:33.110
on at least two software packages,[br]and maybe 5.

0:02:33.110,0:02:35.150
So you have got the version that is[br]unstable,

0:02:35.150,0:02:39.260
and you have got the version that you[br]try to maintain for stable as well.

0:02:39.260,0:02:45.170
And we are committing to[br]doing maintenance work.

0:02:45.170,0:02:52.500
A lot of our work in the project is ???[br]in nature:

0:02:52.500,0:02:55.490
we want to clean up the mess and[br]we want us to stay out of the way

0:02:55.490,0:02:58.260
and make sure things work,[br]functionally,

0:02:58.260,0:03:01.340
for people who are relying on the[br]operating system to not get in their way.

0:03:01.340,0:03:04.110
So revision control I think is really[br]helpful because it means you can

0:03:04.110,0:03:07.670
keep track of what changes you have done[br]on different branches of the project

0:03:07.670,0:03:09.800
while you are maintaining both of them.

0:03:09.800,0:03:14.440
Basically, ??? require working with[br]the revision system I am comfortable with,

0:03:14.440,0:03:17.740
I prefer Git, I am not going to have a[br]religious word about it.

0:03:17.740,0:03:21.290
If upstream uses Git, I am[br]even happier, and I try to make

0:03:21.290,0:03:25.680
my packaging depend on[br]upstream's revision control.

0:03:29.342,0:03:34.812
I like to use 'git-buildpackage', and I[br]like to use it with debhelper.

0:03:34.812,0:03:36.793
If you have not tried out[br]'git-buildpackage',

0:03:36.793,0:03:39.883
we are going to have a[br]'git-buildpackage' skill share session

0:03:39.883,0:03:43.883
later on today actually, and I welcome[br]you to come and share your tricks with it,

0:03:43.883,0:03:46.293
or learn some tricks from other people.

0:03:46.293,0:03:50.483
It is a particular way that you can keep[br]your Debian packaging in a Git repository,

0:03:50.483,0:03:55.843
and it helps you to keep track of all of[br]the changes that have happened within

0:03:55.843,0:03:59.843
your packaging and within upstream to[br]make sure you are not accidentally

9:59:59.000,9:59:59.000
making other changes.

9:59:59.000,9:59:59.000
So it is very easy to go back and review[br]what you have done.

9:59:59.000,9:59:59.000
I find that really useful.

9:59:59.000,9:59:59.000
I definitely also like to keep upstream's[br]source code in the same revision control

9:59:59.000,9:59:59.000
system.

9:59:59.000,9:59:59.000
I like to keep the tarballs in the[br]revision control system because it means

9:59:59.000,9:59:59.000
that if someone is interested, they can[br]uses a tool called 'debcheckout'.

9:59:59.000,9:59:59.000
You can use 'debcheckout' with a name of[br]a package:

9:59:59.000,9:59:59.000
you say just "I am really interested in[br]package 'foo',

9:59:59.000,9:59:59.000
let me see the source code for that":

9:59:59.000,9:59:59.000
debcheckout foo

9:59:59.000,9:59:59.000
You get the source code, and you get the[br]source code from a revision control

9:59:59.000,9:59:59.000
system that you can now track and you[br]can just propose changes on.

9:59:59.000,9:59:59.000
You can also extract the tarball from that[br]revision control system.

9:59:59.000,9:59:59.000
'debcheckout' actually works even if you[br]do not have upstream stuff in there,

9:59:59.000,9:59:59.000
but I like to keep it all in one revision[br]control system,

9:59:59.000,9:59:59.000
it is just easier to find everything when[br]you want.

9:59:59.000,9:59:59.000
Some of these things that I prefer have[br]to do with what the upstream software

9:59:59.000,9:59:59.000
developer has done, so I am less inclined[br]to try the package an upstream software

9:59:59.000,9:59:59.000
project if they just throw tarballs here[br]over the wall to an FTP side

9:59:59.000,9:59:59.000
every now and then.

9:59:59.000,9:59:59.000
It makes it more difficult for me to know[br]what they are doing,

9:59:59.000,9:59:59.000
and why they are doing it.

9:59:59.000,9:59:59.000
So i like it, I have already said, when[br]upstream uses Git,

9:59:59.000,9:59:59.000
I also like when upstream signs their[br]releases,

9:59:59.000,9:59:59.000
and say "hey, this is specific release",

9:59:59.000,9:59:59.000
Because that is a signal that I can use,[br]or somebody else that understands the

9:59:59.000,9:59:59.000
project: as said "we think that this[br]something that other people can use",

9:59:59.000,9:59:59.000
or "this is a particular version we would[br]like other people to test".

9:59:59.000,9:59:59.000
There are a lot of other situations where[br]maybe it is not so important.

9:59:59.000,9:59:59.000
And having that be cryptographically[br]signed is really useful.

9:59:59.000,9:59:59.000
I care about cryptographic signature on[br]software because I want to know that

9:59:59.000,9:59:59.000
what I am running is related to the code[br]that somebody else out should be run.

9:59:59.000,9:59:59.000
And if you don't verify your software[br]cryptographically, anyone could

9:59:59.000,9:59:59.000
intercept the network connection[br]between you and that software,

9:59:59.000,9:59:59.000
and modify the software before it gets[br]to you.

9:59:59.000,9:59:59.000
And the cryptographic signature just says:

9:59:59.000,9:59:59.000
"look, this is a version that I am OK[br]with. I am putting it out there and

9:59:59.000,9:59:59.000
it comes from me".

9:59:59.000,9:59:59.000
And so I can have a trace back to that[br]point.

9:59:59.000,9:59:59.000
??? just talk about briefly about how you[br]do cryptographic verification of upstream.

9:59:59.000,9:59:59.000
You might know upstream: you might know[br]them personally, you know their key

9:59:59.000,9:59:59.000
already, that is fine.

9:59:59.000,9:59:59.000
That is not the usual case: we work on[br]the Internet.

9:59:59.000,9:59:59.000
In the situation where your upstream is[br]signing their tarballs

9:59:59.000,9:59:59.000
and you have not met them, you do not[br]have to sign their key,

9:59:59.000,9:59:59.000
you do not have to say "I announce this[br]is their key".

9:59:59.000,9:59:59.000
This is probably the same one that is[br]signing every release,

9:59:59.000,9:59:59.000
so you should keep track of that.

9:59:59.000,9:59:59.000
Debian has a nice way to keep track of[br]that:

9:59:59.000,9:59:59.000
you can tell Debian how to find the new[br]version of the upstream tarball.

9:59:59.000,9:59:59.000
This is in the Debian 'watch' file.

9:59:59.000,9:59:59.000
If you type 'man uscan', you can learn[br]more about Debian 'watch',

9:59:59.000,9:59:59.000
and Debian 'watch' has now a feature that[br]lets you say

9:59:59.000,9:59:59.000
"that is not only this way you find the[br]tarball,

9:59:59.000,9:59:59.000
but upstream publishes signatures[br]and the signatures look like this".

9:59:59.000,9:59:59.000
You know, they got a '.sig' at the end.

9:59:59.000,9:59:59.000
So there is a particular arcane way to[br]specify that, but if you specify that,

9:59:59.000,9:59:59.000
then 'uscan' can find not only the[br]upstream tarball but can find the

9:59:59.000,9:59:59.000
upstream signature and, if you drop[br]upstream's signing key -

9:59:59.000,9:59:59.000
which of course I did not put on the wiki[br]page, someone should add it that and

9:59:59.000,9:59:59.000
fix it - you can put the upstream signing[br]key in 'debian/upstream/signing-key.asc'.

9:59:59.000,9:59:59.000
And then if you do that, when you say[br]'uscan', you can tell…

9:59:59.000,9:59:59.000
Maybe some people here do notk[br]now how to use 'uscan'.

9:59:59.000,9:59:59.000
'uscan' is a very simple tool,[br]you run it from a software package that

9:59:59.000,9:59:59.000
has a 'debian' directory, or even one[br]level up if you keep all of your software

9:59:59.000,9:59:59.000
packages in one folder. You can go one[br]level up and say 'uscan', and it will look

9:59:59.000,9:59:59.000
in all of the folder that are children[br]of it, and look for new version by

9:59:59.000,9:59:59.000
trying to find for new upstreams versions[br]in 'debian/watch'.

9:59:59.000,9:59:59.000
And if you have configured 'debian/watch'[br]properly, it can find the new upstream

9:59:59.000,9:59:59.000
signatures, and if you have got the[br]'upstream/signing-key.asc', then

9:59:59.000,9:59:59.000
it will actually verify the signature for[br]you as part of fetching the new

9:59:59.000,9:59:59.000
upstream tarball.

9:59:59.000,9:59:59.000
So you can get all of those things just[br]by setting ???? that way.

9:59:59.000,9:59:59.000
There is a hand up down there, could we[br]get the mic down to the hand ?[br]

9:59:59.000,9:59:59.000
Or to the person who has that hand, it is[br]not just a hand. [public laugh]

9:59:59.000,9:59:59.000
[someone] Publish a tarball and a hash, '.sha1',[br]and sign that hash, '.sha1.asc'.

9:59:59.000,9:59:59.000
Can 'uscan' cope with this and check the[br]signature on the hash and that the hash

9:59:59.000,9:59:59.000
belongs to that tarball ?

9:59:59.000,9:59:59.000
[Daniel] I do not believe that 'uscan' can[br]do that currently. So anybody out there

9:59:59.000,9:59:59.000
who wants to make things better for the[br]world should go hack on 'uscan':

9:59:59.000,9:59:59.000
that is a pretty straightforward thing[br]that we should fix because I agree

9:59:59.000,9:59:59.000
that is common pattern.

9:59:59.000,9:59:59.000
[someone] I have no answer to this[br]question by I have another question:

9:59:59.000,9:59:59.000
how do you convince upstreams who do[br]not release tarballs or who do

9:59:59.000,9:59:59.000
not set tags in Git ?

9:59:59.000,9:59:59.000
[Daniel] Who do not make tags in Git ?

9:59:59.000,9:59:59.000
[someone] Yes, if there is no tags you[br]can not check out a tarball.

9:59:59.000,9:59:59.000
Is there any good way to convince[br]upstream to do this ?

9:59:59.000,9:59:59.000
[Daniel] Git has this nice feature, which[br]is that you can create a tag,

9:59:59.000,9:59:59.000
which is associate with a particular[br]revision,

9:59:59.000,9:59:59.000
and you would like to have a tag[br]everywhere that a tarball has been

9:59:59.000,9:59:59.000
released from. I am tempted to pull up[br]a Git view and show people some tags.

9:59:59.000,9:59:59.000
The question that you ask is a social[br]one, not just a technical one,

9:59:59.000,9:59:59.000
and I actually find that my upstreams[br]are pretty responsive.

9:59:59.000,9:59:59.000
Usually I frame my request as "hey, it[br]looks like you made this tarball from

9:59:59.000,9:59:59.000
this particular commit 'id'. If you could[br]tag you releases, it would be really

9:59:59.000,9:59:59.000
helpful to me, and here is the command[br]that I would use to tag the release".

9:59:59.000,9:59:59.000
And I say "git tag…" and of course I[br]can never remember so first I look it up,

9:59:59.000,9:59:59.000
but it is either 'tag name' 'commit id' or[br]'commit id' 'tag name'.

9:59:59.000,9:59:59.000
But I would look it up and I would write[br]the e-mail so that all they have to do is

9:59:59.000,9:59:59.000
they read it, understand my argument,[br]and execute one command.

9:59:59.000,9:59:59.000
And then it starts them ??????

9:59:59.000,9:59:59.000
And if you say 'tag -s' then your tag will[br]be cryptographically signed, which

9:59:59.000,9:59:59.000
I think is a really good thing to do too.

9:59:59.000,9:59:59.000
So, cryptographic verification of[br]upstream.

9:59:59.000,9:59:59.000
As I said, I want to keep upstream's code[br]in the revision control system.

9:59:59.000,9:59:59.000
I also like to keep…

9:59:59.000,9:59:59.000
In my ideal case upstream is using Git:[br]I am using Git for packaging.

9:59:59.000,9:59:59.000
I actually like to keep upsteam's Git[br]history fully in my repository,

9:59:59.000,9:59:59.000
so that I do not just have the tarballs,[br]but I actually have all of their commits.

9:59:59.000,9:59:59.000
And that turns out to be really useful[br]for two specific cases:

9:59:59.000,9:59:59.000
In one case, there is a common scenario[br]where upstream will fix a bug,

9:59:59.000,9:59:59.000
but they have not made a release yet.

9:59:59.000,9:59:59.000
And that bug is really, really obviously[br]problematic for the folks who are

9:59:59.000,9:59:59.000
using Debian, so want to fix it.

9:59:59.000,9:59:59.000
All I can do, because I have their full[br]revision history, I can use Git to "cherry

9:59:59.000,9:59:59.000
pick" the upstream commit.

9:59:59.000,9:59:59.000
And then I "cherry pick" that upstream[br]commit and I can have it applied

9:59:59.000,9:59:59.000
separately and release an Debian version[br]that has the fix, even before upstream

9:59:59.000,9:59:59.000
has made a release with the fix.

9:59:59.000,9:59:59.000
So one nice thing about having upstream[br]revision is that I can pull fixes from

9:59:59.000,9:59:59.000
upstream before they decided[br]to release it.

9:59:59.000,9:59:59.000
The other advantage is the other[br]way around.

9:59:59.000,9:59:59.000
Often when I am doing packaging,[br]I discover a problem,

9:59:59.000,9:59:59.000
and maybe I can fix the problem.

9:59:59.000,9:59:59.000
And if that maybe I am already shipping[br]a Debian package that fixes the problem.

9:59:59.000,9:59:59.000
If my Debian fixes can be directly applied[br]to upstream, then I can use whatever

9:59:59.000,9:59:59.000
their preferred upstream patch[br]submission guidelines are,

9:59:59.000,9:59:59.000
whether it is a Github pull request, or[br]a patch to a mailing list,

9:59:59.000,9:59:59.000
or a "hey can you pull this from my Git[br]repository over here", e-mail…

9:59:59.000,9:59:59.000
The fact that I am using the same Git[br]history that they are using makes it

9:59:59.000,9:59:59.000
much easier for me to push my changes[br]back to them.

9:59:59.000,9:59:59.000
So, it sort of smooth the interaction if[br]you can consolidate and use the same

9:59:59.000,9:59:59.000
revision control system as their.

9:59:59.000,9:59:59.000
Towards that aim, I use a system now[br]called 'patch q',

9:59:59.000,9:59:59.000
which is part of 'git buildpackage'.

9:59:59.000,9:59:59.000
So 'git buildpackage' is 'gbp', 'patch q'[br]is 'pq',

9:59:59.000,9:59:59.000
so to deal with 'patch q' you say[br]'gbp pq'

9:59:59.000,9:59:59.000
and then you have some commands.

9:59:59.000,9:59:59.000
And what that does, is it takes…

9:59:59.000,9:59:59.000
How many of you are Debian packagers ?

9:59:59.000,9:59:59.000
How many of you package[br]software for Debian ?

9:59:59.000,9:59:59.000
A very large percentage, but not everyone.

9:59:59.000,9:59:59.000
I hope some folks are considering starting[br]packaging if you have not done it yet.

9:59:59.000,9:59:59.000
Of those of you who package software,[br]how many of you package software

9:59:59.000,9:59:59.000
with modifications, how many of you ship[br]a modified version of upstream sources ?

9:59:59.000,9:59:59.000
Beyond the 'debian' directory, just Debian[br]patches ?

9:59:59.000,9:59:59.000
So the common way to do that, for the[br]Debian 3.0 ??? packaging skill, is that in

9:59:59.000,9:59:59.000
your 'debian' directory you have a[br]'patches' sub-directory that has a set of

9:59:59.000,9:59:59.000
individual patches that apply certain[br]changes, and they are applied in order

9:59:59.000,9:59:59.000
based on the file called[br]'debian/patches/series'.

9:59:59.000,9:59:59.000
So maintaining that is kind of a drag[br]when upstream makes big changes:

9:59:59.000,9:59:59.000
then all of sudden you have got this set[br]of patches and they do not quite apply…

9:59:59.000,9:59:59.000
I is a drag even you do not have it in[br]the 'debian/patches/' directory.

9:59:59.000,9:59:59.000
But what Debian 'patch q' does is it maps[br]that directory of patches into a little

9:59:59.000,9:59:59.000
branch on your Git revision history.

9:59:59.000,9:59:59.000
So when you get a new upstream version,[br]you can say 'patch q rebase',

9:59:59.000,9:59:59.000
and it treats it just as Git: it takes the[br]'patch q'…

9:59:59.000,9:59:59.000
You have already imported the new version,[br]and it re-applies your patches,

9:59:59.000,9:59:59.000
and sometimes that means some minor[br]adjustments.

9:59:59.000,9:59:59.000
Git is really good at figuring out what[br]the right minor adjustments are to make,

9:59:59.000,9:59:59.000
and so all of the sudden the 'patch q' is[br]re-based, you refresh it in your revision

9:59:59.000,9:59:59.000
control system, and there you go.

9:59:59.000,9:59:59.000
So I like to use 'git-buildpackage' 'patch q',[br]tagging, as already brought up,

9:59:59.000,9:59:59.000
thank you for that, I like to to tag[br]everything that I release,

9:59:59.000,9:59:59.000
I like to push that as soon as I can,[br]so that other people who are following

9:59:59.000,9:59:59.000
my work can now where my releases[br]come from.

9:59:59.000,9:59:59.000
The reason that I like other people[br]following my work is

9:59:59.000,9:59:59.000
they can fix my bugs easier.

9:59:59.000,9:59:59.000
I make mistakes, everybody makes mistakes,[br]and it is really important to me that

9:59:59.000,9:59:59.000
if someone catches one of my mistakes,[br]I can accept their feedback,

9:59:59.000,9:59:59.000
their criticism, their improvements,[br]as easily as possible.

9:59:59.000,9:59:59.000
I want a low barrier to entry for people[br]to help me fix my problems,

9:59:59.000,9:59:59.000
it is selfishness. So I try to patch it[br]and publish this things for people

9:59:59.000,9:59:59.000
can find it.

9:59:59.000,9:59:59.000
I am ??? on these pretty fast because[br]were are almost at the time.[br]

9:59:59.000,9:59:59.000
I like to put in some place where other[br]people get to the them,

9:59:59.000,9:59:59.000
at the moment I like to put them in[br]'collab-maint',

9:59:59.000,9:59:59.000
it has some problems but it is better[br]than not publishing your stuff,

9:59:59.000,9:59:59.000
and it is nice because it is sort of[br]a public use.

9:59:59.000,9:59:59.000
I like to standardize how of my branches[br]are named, so if I am working on

9:59:59.000,9:59:59.000
something that has got a stable version,[br]that is for Jessie, I will name the branch

9:59:59.000,9:59:59.000
'jessie', because I ???

9:59:59.000,9:59:59.000
???? multiple branches ???

9:59:59.000,9:59:59.000
I try to push as frequently as I have made[br]something that looks sensible.

9:59:59.000,9:59:59.000
I do not feel obliged to push my commits[br]to a public repository when I am still

9:59:59.000,9:59:59.000
experimenting, I actually really like to[br]experiment, and I also like to keep track

9:59:59.000,9:59:59.000
of my experiments while I am doing them.

9:59:59.000,9:59:59.000
So I try to push when there is a sensible[br]set of changes, and I am trying to get

9:59:59.000,9:59:59.000
myself to a point where I can understand[br]what I have done, even if it wrong.

9:59:59.000,9:59:59.000
If I can get myself to a conceptual point[br]where it is done, I will push my changes

9:59:59.000,9:59:59.000
so other people can see what I am[br]working on, and then work from there.

9:59:59.000,9:59:59.000
That is OK to push something that is[br]wrong,

9:59:59.000,9:59:59.000
as long as you push something that[br]people can understand.

9:59:59.000,9:59:59.000
When you make a 'git commit' (if you are[br]working with Git),

9:59:59.000,9:59:59.000
One of the things that helps me to think[br]about commit messages…

9:59:59.000,9:59:59.000
People often think that commit messages[br]should say "what change you made".

9:59:59.000,9:59:59.000
I think that the 'git patch' shows what[br]change what change you have made,

9:59:59.000,9:59:59.000
and I thin your commit messages should[br]say "why you made the change".

9:59:59.000,9:59:59.000
That is what people really want to read.

9:59:59.000,9:59:59.000
If you need to explain technically why[br]the thing that you did

9:59:59.000,9:59:59.000
maps to the conceptual thing that you[br]wanted to do, that is fine:

9:59:59.000,9:59:59.000
do that in your commit message too.[br]But it is really important to say why

9:59:59.000,9:59:59.000
you made the change. It is not just like[br]"initialize variable to 'no'":

9:59:59.000,9:59:59.000
OK, we can see that from the patch,[br]but you what you are really saying

9:59:59.000,9:59:59.000
is "there was a crash if someone did 'x',

9:59:59.000,9:59:59.000
and we are avoiding that crash by[br]setting this to 'no'.

9:59:59.000,9:59:59.000
So I like to send patches via email,

9:59:59.000,9:59:59.000
so I try to configure Git email, which[br]make it really easy to just

9:59:59.000,9:59:59.000
push patches back upstream.

9:59:59.000,9:59:59.000
If I am starting taking over a project[br]that somebody else has past on,

9:59:59.000,9:59:59.000
and they did not use Git, I will try to[br]restore all of the imports.

9:59:59.000,9:59:59.000
I would be happy to talk with people[br]about how to do that,

9:59:59.000,9:59:59.000
if you have questions come find me.

9:59:59.000,9:59:59.000
I like to keep my files ???? simple:[br]there is a tool 'wrap-and-sort',

9:59:59.000,9:59:59.000
that just canonicalizes your files to[br]make them look in a simple and

9:59:59.000,9:59:59.000
sensible way. And it is nice because it[br]means that everything is…

9:59:59.000,9:59:59.000
It does things like alphabetize your[br]list of build depends,

9:59:59.000,9:59:59.000
and brake them out one per line.[br]The nice thing about that,

9:59:59.000,9:59:59.000
since you are using revision control,[br]when you make a change

9:59:59.000,9:59:59.000
to your build depends, the changes[br]become very easy to see:

9:59:59.000,9:59:59.000
"oh, they added one new package here,[br]there is a single '+'".

9:59:59.000,9:59:59.000
When ???? so you can see that kind of[br]thing.

9:59:59.000,9:59:59.000
I like to use ? deb five ? to format[br]Debian copyright to be machine readable,

9:59:59.000,9:59:59.000
it is nice for people who are doing scans[br]of the archive and try reason about

9:59:59.000,9:59:59.000
what the patterns are, and licensing of[br]free software.

9:59:59.000,9:59:59.000
And if I am doing something really crazy,[br]that is going to make a big change,

9:59:59.000,9:59:59.000
I like to use a feature branch in[br]revision control.

9:59:59.000,9:59:59.000
So we have got one minute left,[br]I want to open it up for other questions.

9:59:59.000,9:59:59.000
????

9:59:59.000,9:59:59.000
[attendee] You said you are using[br]'wrap-and-sort' which is nice,

9:59:59.000,9:59:59.000
I had learned that ???? editors[br]- 'cme' - do the same job,

9:59:59.000,9:59:59.000
and somehow does a better job:[br]it also ??? standard version

9:59:59.000,9:59:59.000
if it does not fit, or it makes VCS[br]fields properly has it should be.

9:59:59.000,9:59:59.000
'cme fix dpkg-control' fixes your[br]control file.

9:59:59.000,9:59:59.000
[Daniel] 'cme' ? And it is in[br]what package ?

9:59:59.000,9:59:59.000
[attendee] The package 'cme', in[br]unstable ????. In Jessie it is ????

9:59:59.000,9:59:59.000
[Daniel] You are developing in unstable,[br]that is OK.

9:59:59.000,9:59:59.000
'cme'[br]OK, thank you.

9:59:59.000,9:59:59.000
Other questions or suggestions,[br]or complains ?

9:59:59.000,9:59:59.000
[attendee] If you change the original[br]source code, and do some commits,

9:59:59.000,9:59:59.000
how do you convert that into a series[br]of ??? patches ?

9:59:59.000,9:59:59.000
[Daniel] I use 'patch q' for that as well,[br]so what I do is I say

9:59:59.000,9:59:59.000
"I want to move over to my 'patch q'[br]view of the tree",

9:59:59.000,9:59:59.000
and then I make may changes, I make[br]my commits,

9:59:59.000,9:59:59.000
and then I say[br]'gbp pq export',

9:59:59.000,9:59:59.000
and it takes the 'patch q' that I am on[br]and dumps it back

9:59:59.000,9:59:59.000
into the Debian patches directory.

9:59:59.000,9:59:59.000
If you have not use 'gbp pq', I[br]recommend looking into it.

9:59:59.000,9:59:59.000
It takes a little while to get used to,[br]and I still screwed it up sometimes,

9:59:59.000,9:59:59.000
but it makes easy to fix your[br]mistakes too.

9:59:59.000,9:59:59.000
[organizer] Last question ?

9:59:59.000,9:59:59.000
[attendee] Do you think it is possible to[br]make this 'patch q' branch

9:59:59.000,9:59:59.000
"pullable" by upstream ?

9:59:59.000,9:59:59.000
[Daniel] I do not actually think it is[br]possible to make it directly

9:59:59.000,9:59:59.000
"pullable" by upstream: I think upstream[br]can cherry pick patches from it,

9:59:59.000,9:59:59.000
but I do not see how to[br]make it "pullable".

9:59:59.000,9:59:59.000
If someone else does, I would be[br]happy to learn.

9:59:59.000,9:59:59.000
[organizer] This was "before last",[br]so last.

9:59:59.000,9:59:59.000
[attendee] Do you have a recording of[br]you using the tools that you mentioned,

9:59:59.000,9:59:59.000
a video recording would be great,[br]just to show your workflow ?

9:59:59.000,9:59:59.000
[Daniel] I do not really know how[br]to do that: if somebody wants to

9:59:59.000,9:59:59.000
help me do that I would be[br]happy to do it.

9:59:59.000,9:59:59.000
I am going to give one last plug,

9:59:59.000,9:59:59.000
I know we are out of time here,[br]sorry.

9:59:59.000,9:59:59.000
This tool is called 'gitk'.

9:59:59.000,9:59:59.000
This is an example - sorry we[br]should leave - but this the way

9:59:59.000,9:59:59.000
that I visualize my revision[br]control system.

9:59:59.000,9:59:59.000
We could do a whole other session[br]about 'gitk'.

9:59:59.000,9:59:59.000
If you do not try to visualize your[br]revision control system,

9:59:59.000,9:59:59.000
you are missing out: try to find a way[br]to visualize stuff,

9:59:59.000,9:59:59.000
find one that works for you.

9:59:59.000,9:59:59.000
Thanks for coming.

9:59:59.000,9:59:59.000
[organizer] Thank you.