Preferred_Debian_Packaging.webm

Thank you very much.

Thanks everybody for coming,…

If you are packaging software and you want
me to work on with you,

this is how you can do that.

It is a very self-??? talk:

I just want to explain some of the things
that I like,

some practice that I prefer about Debian
packaging,

and I don't pretend this is any sort of
official,

permanent or final thing.

I just wanted to share some ideas that I
have about the way that I work with

packages, in the hope that maybe, hmm,
for two hopes:

One is that I hope that I can show you
something that you have not heard of,

or maybe you were doing differently,

or maybe you think it is the right think
to do and it is just nice to see somebody

somebody else doing it.

My second hope is that you can tell me
what I am doing wrong,

and you can help me learn and improve
on my own packaging techniques.

If you see something that I am proposing
up here,

and you think there is a problem with it,
I would like to hear about it too.

I just want to see more of the culture
within Debian,

of people who are doing packaging,
explaining what they are doing,

and so I thought I would just step up and
explain:

"Here is some of the practice that I do",

In the hope that other people will do the
same and explain what they are doing,

and maybe they can learn from me and
I can learn from them.

Without much further ????, I am just going
to dive into it.

If you have questions, I am perfectly
happy to be interrupted,

we have some folks with walking mics
in the crowd:

you can just raise your hand.

I you have got a question or an
interruption or whatever,

that is fine.

I ??? I got the whole 15 minutes,
I think there are 20 minutes,

I ??? the whole time, so there will be
also time for questions at the end

if you prefer.

But I do not mind being interrupted.

So, this is all on this web page here,

you could probably skip this talk and go
read the web page,

but then you would not have the nice
??? actions,

and it is easier to tell me that I am
wrong in person,

so I would like to have that happen.

I put this up on the Debian wiki,

because I want anyone to be able to find
it.

If you thing you have got some good ideas,
you should put it on the Debian Wiki too:

other people can take advantage of the
ideas that you have got.

First baseline is: I really like revision
control.

And I know that it makes me a certain
flavor on nerd,

but when we are working with things that
are as complicated as software packages,

hmmm, I think a lot of people don't get
that in Debian we are not just working on

one software package:

you are actually probably, if you are doing
a responsibly work,

on at least two software packages, and
maybe 5.

So you have got the version that is
unstable and you have got

the version that you try to maintain for
stable as well.

And we are committing to doing maintenance
work.

A lot of our work in the project is ???
in nature:

we want to clean up the mess and we want
us to stay out of the way and

to make sure things work, functionally,

for people who are relying on the
operating system to not get in their way.

So revision control I think is really
helpful because it means you can

keep track of what changes you have done
on different branches of the project

while you are maintaining both of them.

Basically, ??? require working with
the revision system I am comfortable with,

I prefer Git, I am not going to have a
religious word about it.

If upstream uses Git, I am even happier,
and I try to make my packaging depend on

upstream's revision control.

I like to use 'git-buildpackage', and I
like to use it with debhelper.

If you have not tried out
'git-buildpackage',

we are going to have a
'git-buildpackage' skill share session

later on today actually, and I welcome
you to come and share your tricks with it,

or learn some tricks from other people.

It is a particular way that you can keep
your Debian packaging in a Git repository,

and it helps you to keep track of all of
the changes that ave happened within

your packaging and within upstream to
make sure you are not accidentally

making other changes.

So it is very easy to go back and review
what you have done.

I find that really useful.

I definitely also like to keep upstream's
source code in the same revision control

system.

I like to keep the tarballs in the
revision control system because it means

that if someone is interested, they can
uses a tool called 'debcheckout'.

You can use 'debcheckout' with a name of
a package:

you say just "I am really interested in
package 'foo',

let me see the source code for that":

debcheckout foo

You get the source code, and you get the
source code from a revision control

system that you can now track and you
can just propose changes on.

You can also extract the tarball from that
revision control system.

'debcheckout' actually works even if you
do not have upstream stuff in there,

but I like to keep it all in one revision
control system,

it is just easier to find everything when
you want.

Some of these things that I prefer have
to do with what the upstream software

developer has done, so I am less inclined
to try the package an upstream software

project if they just throw tarballs here
over the wall to an FTP side

every now and then.

It makes it more difficult for me to know
what they are doing,

and why they are doing it.

So i like it, I have already said, when
upstream uses Git,

I also like when upstream signs their
releases,

and say "hey, this is specific release",

Because that is a signal that I can use,
or somebody else that understands the

project: as said "we think that this
something that other people can use",

or "this is a particular version we would
like other people to test".

There are a lot of other situations where
maybe it is not so important.

And having that be cryptographically
signed is really useful.