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:56.223 and it helps you to keep track of all of[br]the changes that have happened within 0:03:56.223,0:03:59.293 your packaging and within upstream to[br]make sure you are not accidentally 0:03:59.293,0:04:00.813 making other changes. 0:04:00.813,0:04:03.193 So it is very easy to go back and[br]review what you have done. 0:04:03.193,0:04:05.883 I find that really useful. 0:04:05.883,0:04:09.233 I definitely also like to keep[br]upstream's source code 0:04:09.233,0:04:11.213 in the same revision control system. 0:04:11.213,0:04:13.823 I like to keep the tarballs in the[br]revision control system 0:04:13.823,0:04:15.713 because it means that[br]if someone is interested, 0:04:15.713,0:04:18.243 they can uses a tool called[br]'debcheckout'. 0:04:18.243,0:04:20.713 You can use 'debcheckout' with[br]a name of a package: 0:04:20.713,0:04:23.383 you just say "I am really[br]interested in package 'foo', 0:04:23.383,0:04:27.053 let me see the source code for that":[br]'debcheckout foo' 0:04:27.053,0:04:30.373 You get the source code, and[br]you get the source code… 0:04:30.373,0:04:32.853 from a revision control system[br]that you can now track 0:04:32.853,0:04:36.243 and you can just propose changes on. 0:04:37.267,0:04:40.987 You can also extract the tarball from that[br]revision control system. 0:04:40.987,0:04:44.797 'debcheckout' actually works even if you[br]do not have upstream stuff in there, 0:04:44.797,0:04:47.527 but I like to keep it all in one[br]revision control system, 0:04:47.527,0:04:50.427 it is just easier to find everything[br]when you want. 0:04:50.707,0:04:53.697 Some of these things that[br]I prefer have to do with 0:04:53.697,0:04:55.847 what the upstream software[br]developer has done, 0:04:55.847,0:04:59.587 so I am less inclined to try the package,[br]an upstream software project, 0:04:59.587,0:05:02.017 if they just throw tarballs[br]here over the wall 0:05:02.017,0:05:03.827 to an FTP side every now and then. 0:05:03.827,0:05:06.287 It makes it more difficult for me to[br]know what they are doing, 0:05:06.287,0:05:07.577 and why they are doing it. 0:05:07.577,0:05:10.317 So i like it, I have already said,[br]when upstream uses Git, 0:05:10.317,0:05:12.657 I also like it when upstream[br]signs their releases, 0:05:12.657,0:05:15.457 and says "hey, this is specific release", 0:05:15.457,0:05:18.607 because that is a signal[br]that I can use,[br] 0:05:18.607,0:05:21.887 or somebody else that[br]understands the project. 0:05:23.077,0:05:25.987 As said, "we think that this is[br]something that other people can use", 0:05:25.987,0:05:29.097 or "this is a particular version that[br]we would like other people to test". 0:05:29.097,0:05:32.117 There are a lot of other situations where[br]maybe it is not so important. 0:05:32.117,0:05:35.127 And having that be cryptographically[br]signed is really useful. 0:05:35.127,0:05:38.257 I care about cryptographic signature on[br]software because I want to know that 0:05:38.257,0:05:44.027 what I am running is related to the code[br]that somebody else out should be run. 0:05:44.027,0:05:46.717 And if you don't verify your[br]software cryptographically, 0:05:46.717,0:05:48.977 anyone who can intercept[br]the network connection 0:05:48.977,0:05:52.520 between you and that software, can[br]modify the software before it gets to you. 0:05:52.520,0:05:54.300 And the cryptographic signature just says: 0:05:54.300,0:05:58.120 "look, this is a version[br]that I am OK with. 0:05:58.120,0:06:00.320 I am putting it out there[br]and it comes from me". 0:06:00.320,0:06:03.710 So I can have a trace back[br]to that point. 0:06:08.433,0:06:11.703 ??? just talk about briefly about how you[br]do cryptographic verification of upstream. 0:06:11.703,0:06:13.313 One is you might know upstream: 0:06:13.313,0:06:16.943 you might know them personally, you[br]know their key already, that is fine. 0:06:16.943,0:06:20.523 That is not the usual case:[br]we work on the Internet. 0:06:21.211,0:06:23.741 In the situation where your upstream[br]is signing their tarballs 0:06:23.741,0:06:26.501 and you have not met them,[br]you do not have to sign their key, 0:06:26.501,0:06:29.051 you do not have to say[br]"I announce this is their key". 0:06:29.051,0:06:32.562 But it is probably the same one[br]that is signing every release, 0:06:32.562,0:06:34.092 so you should keep track of that. 0:06:34.092,0:06:37.802 Debian has a nice way to[br]keep track of that: 0:06:37.802,0:06:41.982 you can tell Debian how to find the new[br]version of the upstream tarball. 0:06:41.982,0:06:43.722 This is in the Debian 'watch' file. 0:06:43.722,0:06:49.582 If you type 'man uscan', you can learn[br]more about Debian 'watch', 0:06:49.582,0:06:52.092 and Debian 'watch' now has[br]a feature that lets you say 0:06:52.092,0:06:54.772 "that is not only this way[br]you find the tarball, 0:06:54.772,0:06:58.492 but upstream publishes signatures[br]and the signatures look like this". 0:06:58.492,0:07:00.602 You know, they got a '.sig' at the end. 0:07:00.602,0:07:04.862 So there is a particular arcane way to[br]specify that, but if you specify that, 0:07:04.862,0:07:07.342 then 'uscan' can find[br]not only the upstream tarball, 0:07:07.342,0:07:09.262 it can find the upstream signature. 0:07:09.262,0:07:12.572 And, if you drop[br]upstream's signing key 0:07:12.572,0:07:14.792 - which of course I did not[br]put on the wiki page, 0:07:14.792,0:07:16.592 someone should[br]edit that and fix it - 0:07:16.592,0:07:20.572 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.