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-centered talk: 0:00:15.156,0:00:18.516 I just want to explain some of the things[br]that I like about, 0:00:18.516,0:00:21.366 some practice that I prefer[br]about Debian 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.406 I just wanted to share some ideas[br]that I have about 0:00:30.406,0:00:33.376 the way that I work with packages,[br]in the hope that maybe… 0:00:33.376,0:00:34.616 For two hopes: 0:00:34.616,0:00:38.207 One is that I hope that I can show you[br]something that you have not heard of, 0:00:38.207,0:00:39.987 or maybe you were doing differently, 0:00:39.987,0:00:42.137 or maybe you think it is[br]the right think to do 0:00:42.137,0:00:44.467 and it is just nice to see[br]somebody else doing it. 0:00:44.467,0:00:47.437 My second hope is that you can tell me[br]what I am doing wrong, 0:00:47.437,0:00:51.047 and you can help me learn and improve[br]on my own packaging techniques. 0:00:51.047,0:00:53.337 If you see something that[br]I am proposing up here, 0:00:53.337,0:00:56.627 and you think there is a problem with it,[br]I would like to hear about it too. 0:00:56.627,0:00:58.737 I just want to see more of the culture[br]within Debian, 0:00:58.737,0:01:00.887 of people who are doing packaging,[br]explaining what they are doing, 0:01:00.887,0:01:02.817 and so I thought I would[br]just step up and explain: 0:01:02.847,0:01:05.377 "Here is some of the practice that I do", 0:01:05.377,0:01:09.247 In the hope that other people will do the[br]same and explain what they are doing, 0:01:09.247,0:01:13.047 and maybe they can learn from[br]me and I can learn from them. 0:01:13.047,0:01:16.917 Without much further ado 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[br]walking mics in the crowd: 0:01:24.187,0:01:26.517 you can just raise your hand. 0:01:26.517,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.107 I doubt I will go the whole 15 minutes,[br]I think there are 20 minutes, 0:01:33.107,0:01:36.217 I doubt I will go the whole time,[br]so there will be also 0:01:36.217,0:01:38.337 time for questions at[br]the end if you prefer. 0:01:38.337,0:01:40.137 But I do not mind being interrupted. 0:01:40.137,0:01:41.977 So, this is all on this web page here, 0:01:41.977,0:01:44.787 you could probably skip this talk and go[br]read the web page, 0:01:44.787,0:01:47.227 but then you would not have the nice[br]in-person interactions, 0:01:47.227,0:01:49.747 and it is easier to tell me that I am[br]wrong in person, 0:01:49.747,0:01:51.477 so I would like to have that happen. 0:01:51.477,0:01:53.427 I put this up on the Debian wiki, 0:01:53.427,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:22.590,0:02:25.430 I think a lot of people don't get[br]that in Debian you are not 0:02:25.430,0:02:27.160 just working on one[br]software package: 0:02:27.160,0:02:30.120 you are actually probably, if you[br]are doing a responsibly work, 0:02:30.120,0:02:33.010 on at least two software packages,[br]and maybe 5. 0:02:33.010,0:02:35.150 So you have got the version[br]that is 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.390 A lot of our work in the project is[br]janitorial in nature: 0:02:52.390,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:57.450 and make sure things work,[br]functionally, 0:02:57.450,0:03:00.970 for people who are relying on the[br]operating system to not get in their way. 0:03:00.970,0:03:04.260 So revision control I think is really[br]helpful because it means you can 0:03:04.260,0:03:07.910 keep track of what changes you have done[br]on different branches of the project 0:03:07.910,0:03:09.800 while you are maintaining both of them. 0:03:09.800,0:03:14.440 Basically, I'd 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 war 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.652 I like to use 'git-buildpackage', and I[br]like to use it with debhelper. 0:03:34.652,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, and I welcome you[br]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.893 and it helps you to keep track of all of[br]the changes that have happened within 0:03:55.893,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.683 So it is very easy to go back and[br]review what you have done. 0:04:03.683,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.063 in the same revision control system. 0:04:11.063,0:04:13.823 I like to keep the tarballs in the[br]revision control system 0:04:13.823,0:04:16.033 because it means that[br]if someone is interested, 0:04:16.033,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.627 'debcheckout' actually works even if you[br]do not have upstream stuff in there, 0:04:44.627,0:04:47.327 but I like to keep it all in one[br]revision control system, 0:04:47.327,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:01.777 if they just throw tarballs[br]here over the wall 0:05:01.777,0:05:03.437 to an FTP side every now and then. 0:05:03.437,0:05:06.337 It makes it more difficult for me to[br]know what they are doing, 0:05:06.337,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.217 and says "hey, this is specific release", 0:05:15.217,0:05:18.767 because that is a signal[br]that I can use, 0:05:18.767,0:05:21.887 or somebody else that[br]understands the project. 0:05:22.137,0:05:25.427 As said, "we think that this is[br]something that other people can use", 0:05:25.427,0:05:28.927 or "this is a particular version that[br]we would like other people to test". 0:05:28.927,0:05:32.257 There are a lot of other situations where[br]maybe it is not so important. 0:05:32.257,0:05:35.127 And having that be cryptographically[br]signed is really useful. 0:05:35.127,0:05:38.727 I care about cryptographic signature on[br]software because I want to know that 0:05:38.727,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.907 anyone who can intercept[br]the network connection 0:05:48.907,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.560 And the cryptographic signature just says: 0:05:54.560,0:05:58.120 "look, this is a version[br]that I am OK with. 0:05:58.120,0:06:00.390 I am putting it out there[br]and it comes from me". 0:06:00.390,0:06:03.710 So I can have a trace back[br]to that point. 0:06:06.383,0:06:10.573 Just let me talk about briefly about[br]how you do cryptographic verification 0:06:10.573,0:06:13.313 of upstream[br]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:20.751,0:06:23.661 In the situation where your upstream[br]is signing their tarballs 0:06:23.661,0:06:26.521 and you have not met them,[br]you do not have to sign their key, 0:06:26.521,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.162 so you should keep track of that. 0:06:34.162,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.532 If you type 'man uscan', you can learn[br]more about Debian 'watch', 0:06:49.532,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.472 And, if you drop[br]upstream's signing key 0:07:12.472,0:07:14.802 - which of course I did not[br]put on the wiki page, 0:07:14.802,0:07:16.592 someone should[br]edit that and fix it - 0:07:16.592,0:07:24.192 you can put the upstream signing[br]key in 'debian/upstream/signing-key.asc'. 0:07:25.982,0:07:29.982 And then if you do that, when you say[br]'uscan', you can tell… 0:07:31.684,0:07:34.214 Maybe some people here do not[br]know how to use 'uscan': 0:07:34.214,0:07:35.644 'uscan' is a very simple tool, 0:07:35.644,0:07:39.044 you run it from a software package[br]that has a 'debian' directory, 0:07:39.044,0:07:43.084 or even one level up if you keep all of[br]your software packages in one folder. 0:07:43.084,0:07:46.094 You can go one level up[br]and say 'uscan', 0:07:46.094,0:07:49.594 and it will look in all of the folders[br]that are children of it, 0:07:49.594,0:07:50.924 and look for new versions 0:07:50.924,0:07:54.274 by trying to find a new upstream[br]version in 'debian/watch'. 0:07:54.274,0:07:56.654 And if you have configured[br]'debian/watch' properly, 0:07:56.654,0:07:58.584 it can find the new upstream signatures, 0:07:58.584,0:08:02.084 and if you have got the[br]'upstream/signing-key.asc', 0:08:02.084,0:08:04.484 then it will actually verify[br]the signatures for you 0:08:04.484,0:08:06.674 as part of fetching the[br]new upstream tarball. 0:08:06.674,0:08:10.364 So you can get all of those things just[br]by setting a pre-packaging that way. 0:08:10.364,0:08:13.411 There is a hand up down there, could we[br]get the mic down to the hand ?[br] 0:08:14.151,0:08:15.101 Thanks. 0:08:15.101,0:08:18.561 Or to the person who has that hand,[br]it is not just a hand. 0:08:18.561,0:08:20.661 [public laugh] 0:08:21.381,0:08:27.221 [attendee] Publish a tarball,[br]and a hash, '.sha1', 0:08:27.221,0:08:31.751 and sign that hash,[br]'.sha1.asc'. 0:08:31.751,0:08:36.137 Can 'uscan' cope with this and[br]check the signature on the hash 0:08:36.137,0:08:38.397 and that the hash belongs[br]to that tarball ? 0:08:38.397,0:08:41.357 [Daniel] I do not believe that 'uscan'[br]can do that currently. 0:08:41.357,0:08:44.967 So anybody out there who wants to[br]make things better for the world 0:08:44.967,0:08:48.067 should go hack on 'uscan': that is a[br]pretty straightforward thing 0:08:48.067,0:08:51.137 that we should fix because[br]I agree that is common pattern. 0:08:53.715,0:08:57.955 [attendee] I have no answer to this[br]question by I have another question: 0:08:57.955,0:09:01.895 how do you convince upstreams[br]who do not release tarballs 0:09:01.895,0:09:06.485 or who do not set tags in Git ? 0:09:06.485,0:09:08.455 [Daniel] Who do not make tags in Git ? 0:09:08.455,0:09:11.695 [someone] Yes, if there is no tags[br]you can not check out a tarball. 0:09:11.695,0:09:15.795 Is there any good way to[br]convince upstream to do this ? 0:09:17.369,0:09:20.849 [Daniel] Git has this nice feature, which[br]is that you can create a tag, 0:09:20.849,0:09:23.729 which is associated with[br]a particular revision, 0:09:23.729,0:09:26.979 and you would like to have a tag 0:09:26.979,0:09:30.979 everywhere that a tarball[br]has been released from. 0:09:30.979,0:09:34.979 I am tempted to pull up a Git[br]view and show people some tags. 0:09:34.979,0:09:38.979 The question that you ask is a[br]social one tho, not just a technical one, 0:09:38.979,0:09:42.289 and I actually find that my upstreams[br]are pretty responsive. 0:09:42.289,0:09:44.509 Usually I frame my request as 0:09:44.509,0:09:48.759 "hey, it like you made this tarball[br]from this particular commit 'id'. 0:09:48.759,0:09:52.259 If you could tag you releases,[br]it would be really helpful to me, 0:09:52.259,0:09:55.429 and here is the command[br]that I would use to tag the release". 0:09:55.429,0:09:57.199 And I say "git tag…" 0:09:57.199,0:09:59.939 and of course I can never[br]remember so first I look it up, 0:09:59.939,0:10:03.039 but it is either 'tag name' 'commit id'[br]or 'commit id' 'tag name'. 0:10:03.039,0:10:05.759 But I would look it up and[br]I would write the email so that 0:10:05.759,0:10:07.489 all they have to do is they read it, 0:10:07.489,0:10:08.599 understand my argument, 0:10:08.599,0:10:09.829 and execute one command. 0:10:09.829,0:10:13.299 I mean, it doesn't get them in the habit[br]but it start them towards it 0:10:16.239,0:10:19.009 And if you say 'tag -s', 0:10:19.009,0:10:23.179 then your tag will be[br]cryptographically signed, 0:10:23.179,0:10:26.049 which I think is a really[br]good thing to do too. 0:10:27.179,0:10:29.299 So, cryptographic verification[br]of upstream. 0:10:29.299,0:10:33.649 As I said, I want to keep upstream's code[br]in the revision control system. 0:10:33.649,0:10:35.559 I also like to keep… 0:10:35.559,0:10:38.975 In my ideal case upstream is using Git:[br]I am using Git for packaging. 0:10:38.975,0:10:44.575 I actually like to keep upsteam's Git[br]history fully in my repository, 0:10:44.575,0:10:48.705 so that I do not just have the tarballs,[br]but I actually have all of their commits. 0:10:48.705,0:10:52.137 And that turns out to be really useful[br]for two specific cases: 0:10:52.137,0:10:55.557 In one case, there is a common scenario[br]where upstream will fix a bug, 0:10:55.557,0:10:57.667 but they have not made a release yet. 0:10:57.667,0:11:00.417 And that bug is really,[br]really obviously problematic 0:11:00.417,0:11:02.197 for the folks who are using Debian,[br] 0:11:02.197,0:11:03.457 so I want to fix it. 0:11:03.457,0:11:06.407 All I can do, because I have[br]their full revision history, 0:11:06.407,0:11:10.477 I can use Git to "cherry pick"[br]the upstream commit. 0:11:10.477,0:11:12.577 And then I "cherry pick"[br]that upstream commit 0:11:12.577,0:11:14.767 and I can have it applied separately, 0:11:14.767,0:11:17.107 and release a Debian version[br]that has the fix, 0:11:17.107,0:11:19.747 even before upstream has made[br]a release with the fix. 0:11:19.747,0:11:22.777 So one nice thing about[br]having upstream revision 0:11:22.777,0:11:28.667 is that I can pull fixes from upstream[br]before they decided to release it. 0:11:28.667,0:11:32.667 The other advantage is the other[br]way around. 0:11:32.667,0:11:35.517 Often when I am doing packaging,[br]I discover a problem, 0:11:35.517,0:11:37.787 and maybe I can fix the problem. 0:11:37.787,0:11:41.787 And in fact maybe I am already shipping[br]a Debian package that fixes the problem. 0:11:41.787,0:11:45.027 If my Debian fixes can be[br]directly applied to upstream, 0:11:45.027,0:11:50.017 then I can use whatever their preferred[br]upstream patch submission guidelines are, 0:11:50.017,0:11:53.677 whether it is a Github pull request,[br]or a patch to a mailing list, 0:11:53.677,0:11:58.377 or a "hey can you pull this from my Git[br]repository over here", e-mail… 0:11:58.377,0:12:01.590 The fact that I am using the same[br]Git history that they are using 0:12:01.590,0:12:05.520 makes it much easier for me[br]to push my changes back to them. 0:12:05.520,0:12:09.311 So, it sort of smooths the interaction[br]if you can consolidate 0:12:09.311,0:12:13.441 and use the same revision control[br]system as their. 0:12:13.441,0:12:14.661 Towards that aim, 0:12:14.661,0:12:16.691 I use a system now[br]called 'patch queue', 0:12:16.691,0:12:19.141 which is part of 'git-buildpackage'. 0:12:19.141,0:12:21.521 So 'git buildpackage' is 'gbp', 0:12:21.521,0:12:23.321 'patch queue' is 'pq', 0:12:23.321,0:12:28.784 so to deal with 'patch queue'[br]you say 'gbp pq' 0:12:28.784,0:12:30.644 and then you have some commands. 0:12:30.644,0:12:34.067 And what that does, is it takes… 0:12:34.067,0:12:36.087 How many of you are Debian packagers ? 0:12:36.087,0:12:38.187 How many of you package[br]software for Debian ? 0:12:38.187,0:12:40.097 [most attendees raise their hand] 0:12:40.097,0:12:42.097 A very large percentage, but not everyone. 0:12:42.097,0:12:46.557 I hope some folks are considering starting[br]packaging if you have not done it yet. 0:12:46.557,0:12:48.617 Of those of you who package software, 0:12:48.617,0:12:51.057 how many of you package software[br]with modifications, 0:12:51.057,0:12:53.917 how many of you ship a[br]modified version of upstream sources ? 0:12:53.917,0:12:55.597 [most attendees raise their hand] 0:12:55.597,0:12:58.427 Beyond the 'debian' directory,[br]just Debian patches ? 0:12:58.427,0:13:00.757 So the common way to do that, 0:13:00.757,0:13:03.407 for the Debian 3.0 quilt[br]packaging skill, 0:13:03.407,0:13:07.088 is that in your 'debian' directory you[br]have a 'patches' sub-directory 0:13:07.088,0:13:11.038 that has a set of individual patches[br]that apply certain changes, 0:13:11.038,0:13:15.971 and they are applied in order based on[br]the file called 'debian/patches/series'. 0:13:15.971,0:13:20.659 So maintaining that is kind of a drag[br]when upstream makes big changes: 0:13:20.659,0:13:24.449 then all of sudden you have got this set[br]of patches and they do not quite apply… 0:13:24.449,0:13:28.424 It is a drag even you do not have it[br]in the 'debian/patches/' directory. 0:13:28.424,0:13:33.984 But what Debian 'patch queue' does is[br]it maps that directory of patches 0:13:33.984,0:13:38.314 into a little branch on your[br]Git revision history. 0:13:38.314,0:13:43.164 So when you get a new upstream version,[br]you can say 'patch queue rebase', 0:13:43.164,0:13:47.067 and it treats it just as Git:[br]it takes the 'patch queue'… 0:13:47.067,0:13:51.537 You have already imported the new version,[br]and it re-applies your patches, 0:13:51.537,0:13:53.777 and sometimes that means[br]some minor adjustments. 0:13:53.787,0:13:58.417 Git is really good at figuring out what[br]the right minor adjustments are to make, 0:13:58.417,0:14:01.587 and so all of the sudden[br]the patch queue is re-based, 0:14:01.587,0:14:05.587 you refresh it in your revision[br]control system… 0:14:05.587,0:14:08.217 and there you go. 0:14:08.217,0:14:11.810 So I like to use[br]git-buildpackage patch queue, 0:14:11.810,0:14:14.830 tagging, as already brought up,[br]thank you for that, 0:14:14.830,0:14:17.010 I like to to tag[br]everything that I release, 0:14:17.010,0:14:18.730 I like to push that[br]as soon as I can, 0:14:18.730,0:14:21.740 so that other people[br]who are following my work 0:14:21.740,0:14:24.780 can know where my releases[br]come from. 0:14:24.780,0:14:27.430 The reason that I like other people[br]following my work is 0:14:27.430,0:14:30.616 they can fix my bugs easier. 0:14:30.616,0:14:32.636 I make mistakes,[br]everybody makes mistakes, 0:14:32.636,0:14:36.220 and it is really important to me that[br]if someone catches one of my mistakes, 0:14:36.220,0:14:39.416 I can accept their feedback,[br]their criticism, their improvements, 0:14:39.416,0:14:41.226 as easily as possible. 0:14:41.226,0:14:45.606 I want a low barrier to entry for people[br]to help me fix my problems: 0:14:45.606,0:14:46.826 it is selfishness. 0:14:46.826,0:14:49.956 So I try to patch it and publish these[br]things for people can find it. 0:14:49.956,0:14:54.516 I'm going to rattle through some of these pretty[br]fast because were are almost out of time. 0:14:54.516,0:14:57.656 I like to put my repo in some place[br]where other people get to the them, 0:14:57.656,0:15:00.346 at the moment I like to put them in[br]'collab-maint', 0:15:00.346,0:15:03.636 it has some problems but it is better[br]than not publishing your stuff, 0:15:03.636,0:15:06.501 and it is nice because it is sort of[br]a public use. 0:15:07.777,0:15:10.167 I like to standardize how of[br]my branches are named, 0:15:10.167,0:15:13.187 so if I am working on something[br]that has got a stable version, 0:15:13.187,0:15:15.697 that is for Jessie, I will[br]name the branch 'jessie', 0:15:15.697,0:15:21.317 because I will probably making changes,[br]like I said, editing multiple of software 0:15:21.317,0:15:26.147 I try to push as frequently as I have made[br]something that looks sensible. 0:15:26.147,0:15:29.737 I do not feel obliged to push[br]my commits to a public repository 0:15:29.737,0:15:31.347 when I am still experimenting, 0:15:31.347,0:15:33.167 I actually really like to[br]experiment, 0:15:33.167,0:15:36.847 and I also like to keep track of my[br]experiments while I am doing them. 0:15:36.847,0:15:40.067 So I try to push when there is[br]a sensible set of changes, 0:15:40.067,0:15:41.917 and I am trying to get myself 0:15:41.917,0:15:45.317 to a point where I can understand[br]what I have done, even if it is wrong. 0:15:45.317,0:15:48.097 If I can get myself to a conceptual[br]point where it is done, 0:15:48.097,0:15:51.287 I will push my changes so other people[br]can see what I am working on, 0:15:51.287,0:15:52.627 and then work from there. 0:15:52.627,0:15:54.877 That is OK to push something[br]that is wrong, 0:15:54.877,0:15:57.907 as long as you push something that[br]people can understand. 0:15:57.907,0:16:01.277 When you make a 'git commit'[br](if you are working with Git), 0:16:01.277,0:16:05.167 one of the things that helps me to think[br]for commit messages… 0:16:05.167,0:16:08.637 People often think that commit messages[br]should say "what change you made". 0:16:08.647,0:16:12.117 I think that the 'git patch' shows what[br]change what change you have made, 0:16:12.117,0:16:16.677 and I thin your commit messages should[br]say "why you made the change". 0:16:16.677,0:16:19.017 That is what people really want to read. 0:16:19.017,0:16:22.977 If you need to explain technically[br]why the thing that you did 0:16:22.977,0:16:25.677 maps to the conceptual thing[br]that you wanted to do, 0:16:25.677,0:16:28.117 that is fine: do that in[br]your commit message too. 0:16:28.117,0:16:31.067 But it is really important to say[br]why you made the change. 0:16:31.067,0:16:34.287 It is not just like[br]"initialize variable to 'no'": 0:16:34.287,0:16:36.405 OK, we can see that from the patch, 0:16:36.405,0:16:39.815 but what you are really saying is[br]"there was a crash if someone did 'x', 0:16:39.815,0:16:43.925 and we are avoiding that crash by[br]setting this to 'no'. 0:16:43.925,0:16:46.345 So I like to send patches via email, 0:16:46.345,0:16:47.985 so I try to configure Git email, 0:16:47.985,0:16:51.565 which make it really easy to just[br]push patches back upstream. 0:16:51.565,0:16:55.195 If I am starting taking over a project[br]that somebody else has past on, 0:16:55.195,0:16:58.345 and they did not use Git,[br]I will try to restore all of the imports. 0:16:58.345,0:17:01.065 I would be happy to talk with people[br]about how to do that, 0:17:01.065,0:17:02.795 if you have questions come find me. 0:17:02.795,0:17:04.525 I like to keep my files[br]nice and simple: 0:17:04.525,0:17:09.965 there is a tool 'wrap-and-sort', 0:17:09.965,0:17:13.585 that just canonicalizes your files[br]to make them look 0:17:13.585,0:17:16.395 in a simple and sensible way. 0:17:16.395,0:17:20.575 And it is nice because it[br]means that everything is… 0:17:20.575,0:17:23.675 It does things like alphabetize[br]your list of build depends, 0:17:23.675,0:17:25.555 and brake them out one per line. 0:17:25.555,0:17:29.054 The nice thing about that,[br]since you are using revision control, 0:17:29.054,0:17:31.284 when you make a change[br]to your build depends, 0:17:31.284,0:17:32.954 the changes become[br]very easy to see: 0:17:32.954,0:17:36.371 "oh, they added one new package here,[br]there is a single '+'". 0:17:36.371,0:17:40.051 When ????[br]so you can see that kind of thing. 0:17:40.051,0:17:44.851 I like to use ??? deb five ??? to format[br]Debian copyright to be machine readable, 0:17:44.851,0:17:47.701 it is nice for people who are[br]doing scans of the archive 0:17:47.701,0:17:49.791 and try reason about[br]what the patterns are, 0:17:49.791,0:17:51.275 and licensing of free software. 0:17:51.275,0:17:54.905 And if I am doing something really crazy,[br]that is going to make a big change, 0:17:54.905,0:17:57.325 I like to use a feature branch in[br]revision control. 0:17:57.325,0:18:01.705 So we have got one minute left,[br]I want to open it up for other questions. 0:18:01.705,0:18:05.705 ???? 0:18:10.330,0:18:13.764 [attendee] You said you are using[br]'wrap-and-sort' which is nice, 0:18:13.764,0:18:18.931 I had learned that ???? editors[br]- 'cme' - do the same job, 0:18:18.931,0:18:25.541 and somehow does a better job:[br]it also ??? standard version 0:18:25.541,0:18:31.191 if it does not fit, or it makes VCS[br]fields properly has it should be. 0:18:31.191,0:18:36.761 'cme fix dpkg-control' fixes your[br]control file. 0:18:36.761,0:18:40.491 [Daniel] 'cme' ? And it is in[br]what package ? 0:18:40.491,0:18:45.331 [attendee] The package 'cme', in[br]unstable ????. In Jessie it is ???? 0:18:45.331,0:18:47.763 [Daniel] You are developing in unstable,[br]that is OK. 0:18:47.763,0:18:49.783 'cme'[br]OK, thank you. 0:18:49.783,0:18:53.381 Other questions or suggestions,[br]or complains ? 0:18:56.793,0:19:01.664 [attendee] If you change the original[br]source code, and do some commits, 0:19:01.664,0:19:06.814 how do you convert that into a series[br]of ??? patches ? 0:19:06.818,0:19:09.838 [Daniel] I use 'patch q' for that as well,[br]so what I do is I say 0:19:09.838,0:19:12.788 "I want to move over to my 'patch q'[br]view of the tree", 0:19:12.788,0:19:15.028 and then I make may changes, I make[br]my commits, 0:19:15.028,0:19:18.058 and then I say[br]'gbp pq export', 0:19:18.058,0:19:19.733 so that 'patch q export', 0:19:19.733,0:19:21.563 and it takes the 'patch q'[br]that I am on 0:19:21.563,0:19:24.263 and dumps it back into[br]the Debian patches directory. 0:19:24.263,0:19:28.263 If you have not use 'gbp pq', I[br]recommend looking into it. 0:19:28.263,0:19:31.913 It takes a little while to get used to,[br]and I still screwed it up sometimes, 0:19:31.913,0:19:34.433 but it makes easy to fix your[br]mistakes too. 0:19:34.433,0:19:36.833 [organizer] Last question ? 0:19:36.833,0:19:38.673 [attendee] Do you think it is possible 0:19:38.673,0:19:42.473 to make this 'patch q' branch[br]"pullable" by upstream ? 0:19:45.846,0:19:49.056 [Daniel] I do not actually think it is[br]possible to make it directly 0:19:49.056,0:19:52.536 "pullable" by upstream: I think upstream[br]can cherry pick patches from it, 0:19:52.536,0:19:54.886 but I do not see how to[br]make it "pullable". 0:19:54.886,0:19:58.156 If someone else does, I would be[br]happy to learn. 0:19:58.691,0:20:02.721 [organizer] This was "before last",[br]so last. 0:20:02.721,0:20:07.601 [attendee] Do you have a recording of[br]you using the tools that you mentioned, 0:20:07.601,0:20:12.151 a video recording would be great,[br]just to show your workflow ? 0:20:12.151,0:20:15.441 [Daniel] I do not really know how[br]to do that: 0:20:15.441,0:20:20.321 if somebody wants to help me do that[br]I would be happy to do it. 0:20:20.321,0:20:22.311 I am going to give one last plug, 0:20:22.311,0:20:25.595 I know we are out of time here,[br]sorry. 0:20:25.595,0:20:28.795 This tool is called 'gitk'. 0:20:28.795,0:20:31.105 This is an example… 0:20:31.105,0:20:32.415 - sorry we should leave - 0:20:32.415,0:20:35.965 but this the way that I visualize[br]my revision control system. 0:20:35.965,0:20:38.195 We could do a whole other session[br]about 'gitk'. 0:20:38.195,0:20:41.045 If you do not try to visualize your[br]revision control system, 0:20:41.045,0:20:42.085 you are missing out: 0:20:42.085,0:20:44.385 I recommend try to find a way[br]to visualize stuff, 0:20:44.385,0:20:45.725 find one that works for you. 0:20:45.725,0:20:46.725 Thanks for coming. 0:20:46.725,0:20:48.835 [organizer] Thank you.