1 00:00:00,000 --> 00:00:02,490 Thank you very much. 2 00:00:03,150 --> 00:00:05,060 Thanks everybody for coming,… 3 00:00:08,666 --> 00:00:12,186 If you are packaging software and you want me to work on with you, 4 00:00:12,186 --> 00:00:13,526 this is how you can do that. 5 00:00:13,526 --> 00:00:15,156 It is a very self-??? talk: 6 00:00:15,156 --> 00:00:18,516 I just want to explain some of the things that I like, 7 00:00:18,516 --> 00:00:21,366 some practice that I prefer about Debian packaging, 8 00:00:21,366 --> 00:00:25,236 and I don't pretend this is any sort of… 9 00:00:25,236 --> 00:00:27,296 official, permanent or final thing. 10 00:00:27,296 --> 00:00:30,456 I just wanted to share some ideas that I have about the way that I work with 11 00:00:30,456 --> 00:00:34,976 packages, in the hope that maybe, hmm, for two hopes: 12 00:00:34,976 --> 00:00:38,057 One is that I hope that I can show you something that you have not heard of, 13 00:00:38,057 --> 00:00:40,677 or maybe you were doing differently, 14 00:00:40,677 --> 00:00:42,417 or maybe you think it is the right think to do 15 00:00:42,417 --> 00:00:43,877 and it is just nice to see somebody else doing it. 16 00:00:43,877 --> 00:00:47,047 My second hope is that you can tell me what I am doing wrong, 17 00:00:47,047 --> 00:00:51,047 and you can help me learn and improve on my own packaging techniques. 18 00:00:51,047 --> 00:00:52,907 If you see something that I am proposing up here, 19 00:00:52,907 --> 00:00:55,507 and you think there is a problem with it, I would like to hear about it too. 20 00:00:55,507 --> 00:00:58,227 I just want to see more of the culture within Debian, 21 00:00:58,237 --> 00:01:00,627 of people who are doing packaging, explaining what they are doing, 22 00:01:00,627 --> 00:01:02,787 and so I thought I would just step up and explain: 23 00:01:02,787 --> 00:01:04,497 "Here is some of the practice that I do", 24 00:01:04,497 --> 00:01:08,717 In the hope that other people will do the same and explain what they are doing, 25 00:01:08,717 --> 00:01:12,207 and maybe they can learn from me and I can learn from them. 26 00:01:12,207 --> 00:01:16,917 Without much further ????, I am just going to dive into it. 27 00:01:16,917 --> 00:01:20,897 If you have questions, I am perfectly happy to be interrupted, 28 00:01:20,897 --> 00:01:24,187 we have some folks with walking mics in the crowd: 29 00:01:24,187 --> 00:01:26,687 you can just raise your hand. 30 00:01:26,687 --> 00:01:29,247 If you have got a question or an interruption or whatever, 31 00:01:29,247 --> 00:01:30,347 that is fine. 32 00:01:30,347 --> 00:01:33,037 I doubt I will go the whole 15 minutes, I think there are 20 minutes, 33 00:01:33,037 --> 00:01:35,177 I doubt I will go the whole time, so there will be also 34 00:01:35,177 --> 00:01:36,897 time for questions at the end if you prefer. 35 00:01:36,897 --> 00:01:38,697 But I do not mind being interrupted. 36 00:01:38,697 --> 00:01:42,787 So, this is all on this web page here, 37 00:01:42,787 --> 00:01:44,787 you could probably skip this talk and go read the web page, 38 00:01:44,787 --> 00:01:46,857 but then you would not have the nice ??? actions, 39 00:01:46,857 --> 00:01:48,857 and it is easier to tell me that I am wrong in person, 40 00:01:48,857 --> 00:01:51,397 so I would like to have that happen. 41 00:01:51,397 --> 00:01:53,447 I put this up on the Debian wiki, 42 00:01:53,447 --> 00:01:56,237 because I want anyone to be able to find it. 43 00:01:56,237 --> 00:02:00,237 If you think you have got some good ideas, you should put it on the Debian Wiki too: 44 00:02:00,237 --> 00:02:05,007 other people can take advantage of the ideas that you have got. 45 00:02:07,577 --> 00:02:11,087 First baseline is: I really like revision control. 46 00:02:11,097 --> 00:02:14,267 And I know that it makes me a certain flavor on nerd, 47 00:02:14,267 --> 00:02:19,007 but when we are working with things that are as complicated as software packages, 48 00:02:19,010 --> 00:02:19,890 hmmm… 49 00:02:23,370 --> 00:02:25,670 I think a lot of people don't get that in Debian you are not 50 00:02:25,670 --> 00:02:27,610 just working on one software package: 51 00:02:27,610 --> 00:02:30,120 you are actually probably, if you are doing a responsibly work, 52 00:02:30,120 --> 00:02:33,110 on at least two software packages, and maybe 5. 53 00:02:33,110 --> 00:02:35,150 So you have got the version that is unstable, 54 00:02:35,150 --> 00:02:39,260 and you have got the version that you try to maintain for stable as well. 55 00:02:39,260 --> 00:02:45,170 And we are committing to doing maintenance work. 56 00:02:45,170 --> 00:02:52,500 A lot of our work in the project is ??? in nature: 57 00:02:52,500 --> 00:02:55,490 we want to clean up the mess and we want us to stay out of the way 58 00:02:55,490 --> 00:02:58,260 and make sure things work, functionally, 59 00:02:58,260 --> 00:03:01,340 for people who are relying on the operating system to not get in their way. 60 00:03:01,340 --> 00:03:04,110 So revision control I think is really helpful because it means you can 61 00:03:04,110 --> 00:03:07,670 keep track of what changes you have done on different branches of the project 62 00:03:07,670 --> 00:03:09,800 while you are maintaining both of them. 63 00:03:09,800 --> 00:03:14,440 Basically, ??? require working with the revision system I am comfortable with, 64 00:03:14,440 --> 00:03:17,740 I prefer Git, I am not going to have a religious word about it. 65 00:03:17,740 --> 00:03:21,290 If upstream uses Git, I am even happier, and I try to make 66 00:03:21,290 --> 00:03:25,680 my packaging depend on upstream's revision control. 67 00:03:29,342 --> 00:03:34,812 I like to use 'git-buildpackage', and I like to use it with debhelper. 68 00:03:34,812 --> 00:03:36,793 If you have not tried out 'git-buildpackage', 69 00:03:36,793 --> 00:03:39,883 we are going to have a 'git-buildpackage' skill share session 70 00:03:39,883 --> 00:03:43,883 later on today actually, and I welcome you to come and share your tricks with it, 71 00:03:43,883 --> 00:03:46,293 or learn some tricks from other people. 72 00:03:46,293 --> 00:03:50,483 It is a particular way that you can keep your Debian packaging in a Git repository, 73 00:03:50,483 --> 00:03:55,843 and it helps you to keep track of all of the changes that have happened within 74 00:03:55,843 --> 00:03:59,843 your packaging and within upstream to make sure you are not accidentally 75 99:59:59,999 --> 99:59:59,999 making other changes. 76 99:59:59,999 --> 99:59:59,999 So it is very easy to go back and review what you have done. 77 99:59:59,999 --> 99:59:59,999 I find that really useful. 78 99:59:59,999 --> 99:59:59,999 I definitely also like to keep upstream's source code in the same revision control 79 99:59:59,999 --> 99:59:59,999 system. 80 99:59:59,999 --> 99:59:59,999 I like to keep the tarballs in the revision control system because it means 81 99:59:59,999 --> 99:59:59,999 that if someone is interested, they can uses a tool called 'debcheckout'. 82 99:59:59,999 --> 99:59:59,999 You can use 'debcheckout' with a name of a package: 83 99:59:59,999 --> 99:59:59,999 you say just "I am really interested in package 'foo', 84 99:59:59,999 --> 99:59:59,999 let me see the source code for that": 85 99:59:59,999 --> 99:59:59,999 debcheckout foo 86 99:59:59,999 --> 99:59:59,999 You get the source code, and you get the source code from a revision control 87 99:59:59,999 --> 99:59:59,999 system that you can now track and you can just propose changes on. 88 99:59:59,999 --> 99:59:59,999 You can also extract the tarball from that revision control system. 89 99:59:59,999 --> 99:59:59,999 'debcheckout' actually works even if you do not have upstream stuff in there, 90 99:59:59,999 --> 99:59:59,999 but I like to keep it all in one revision control system, 91 99:59:59,999 --> 99:59:59,999 it is just easier to find everything when you want. 92 99:59:59,999 --> 99:59:59,999 Some of these things that I prefer have to do with what the upstream software 93 99:59:59,999 --> 99:59:59,999 developer has done, so I am less inclined to try the package an upstream software 94 99:59:59,999 --> 99:59:59,999 project if they just throw tarballs here over the wall to an FTP side 95 99:59:59,999 --> 99:59:59,999 every now and then. 96 99:59:59,999 --> 99:59:59,999 It makes it more difficult for me to know what they are doing, 97 99:59:59,999 --> 99:59:59,999 and why they are doing it. 98 99:59:59,999 --> 99:59:59,999 So i like it, I have already said, when upstream uses Git, 99 99:59:59,999 --> 99:59:59,999 I also like when upstream signs their releases, 100 99:59:59,999 --> 99:59:59,999 and say "hey, this is specific release", 101 99:59:59,999 --> 99:59:59,999 Because that is a signal that I can use, or somebody else that understands the 102 99:59:59,999 --> 99:59:59,999 project: as said "we think that this something that other people can use", 103 99:59:59,999 --> 99:59:59,999 or "this is a particular version we would like other people to test". 104 99:59:59,999 --> 99:59:59,999 There are a lot of other situations where maybe it is not so important. 105 99:59:59,999 --> 99:59:59,999 And having that be cryptographically signed is really useful. 106 99:59:59,999 --> 99:59:59,999 I care about cryptographic signature on software because I want to know that 107 99:59:59,999 --> 99:59:59,999 what I am running is related to the code that somebody else out should be run. 108 99:59:59,999 --> 99:59:59,999 And if you don't verify your software cryptographically, anyone could 109 99:59:59,999 --> 99:59:59,999 intercept the network connection between you and that software, 110 99:59:59,999 --> 99:59:59,999 and modify the software before it gets to you. 111 99:59:59,999 --> 99:59:59,999 And the cryptographic signature just says: 112 99:59:59,999 --> 99:59:59,999 "look, this is a version that I am OK with. I am putting it out there and 113 99:59:59,999 --> 99:59:59,999 it comes from me". 114 99:59:59,999 --> 99:59:59,999 And so I can have a trace back to that point. 115 99:59:59,999 --> 99:59:59,999 ??? just talk about briefly about how you do cryptographic verification of upstream. 116 99:59:59,999 --> 99:59:59,999 You might know upstream: you might know them personally, you know their key 117 99:59:59,999 --> 99:59:59,999 already, that is fine. 118 99:59:59,999 --> 99:59:59,999 That is not the usual case: we work on the Internet. 119 99:59:59,999 --> 99:59:59,999 In the situation where your upstream is signing their tarballs 120 99:59:59,999 --> 99:59:59,999 and you have not met them, you do not have to sign their key, 121 99:59:59,999 --> 99:59:59,999 you do not have to say "I announce this is their key". 122 99:59:59,999 --> 99:59:59,999 This is probably the same one that is signing every release, 123 99:59:59,999 --> 99:59:59,999 so you should keep track of that. 124 99:59:59,999 --> 99:59:59,999 Debian has a nice way to keep track of that: 125 99:59:59,999 --> 99:59:59,999 you can tell Debian how to find the new version of the upstream tarball. 126 99:59:59,999 --> 99:59:59,999 This is in the Debian 'watch' file. 127 99:59:59,999 --> 99:59:59,999 If you type 'man uscan', you can learn more about Debian 'watch', 128 99:59:59,999 --> 99:59:59,999 and Debian 'watch' has now a feature that lets you say 129 99:59:59,999 --> 99:59:59,999 "that is not only this way you find the tarball, 130 99:59:59,999 --> 99:59:59,999 but upstream publishes signatures and the signatures look like this". 131 99:59:59,999 --> 99:59:59,999 You know, they got a '.sig' at the end. 132 99:59:59,999 --> 99:59:59,999 So there is a particular arcane way to specify that, but if you specify that, 133 99:59:59,999 --> 99:59:59,999 then 'uscan' can find not only the upstream tarball but can find the 134 99:59:59,999 --> 99:59:59,999 upstream signature and, if you drop upstream's signing key - 135 99:59:59,999 --> 99:59:59,999 which of course I did not put on the wiki page, someone should add it that and 136 99:59:59,999 --> 99:59:59,999 fix it - you can put the upstream signing key in 'debian/upstream/signing-key.asc'. 137 99:59:59,999 --> 99:59:59,999 And then if you do that, when you say 'uscan', you can tell… 138 99:59:59,999 --> 99:59:59,999 Maybe some people here do notk now how to use 'uscan'. 139 99:59:59,999 --> 99:59:59,999 'uscan' is a very simple tool, you run it from a software package that 140 99:59:59,999 --> 99:59:59,999 has a 'debian' directory, or even one level up if you keep all of your software 141 99:59:59,999 --> 99:59:59,999 packages in one folder. You can go one level up and say 'uscan', and it will look 142 99:59:59,999 --> 99:59:59,999 in all of the folder that are children of it, and look for new version by 143 99:59:59,999 --> 99:59:59,999 trying to find for new upstreams versions in 'debian/watch'. 144 99:59:59,999 --> 99:59:59,999 And if you have configured 'debian/watch' properly, it can find the new upstream 145 99:59:59,999 --> 99:59:59,999 signatures, and if you have got the 'upstream/signing-key.asc', then 146 99:59:59,999 --> 99:59:59,999 it will actually verify the signature for you as part of fetching the new 147 99:59:59,999 --> 99:59:59,999 upstream tarball. 148 99:59:59,999 --> 99:59:59,999 So you can get all of those things just by setting ???? that way. 149 99:59:59,999 --> 99:59:59,999 There is a hand up down there, could we get the mic down to the hand ? 150 99:59:59,999 --> 99:59:59,999 Or to the person who has that hand, it is not just a hand. [public laugh] 151 99:59:59,999 --> 99:59:59,999 [someone] Publish a tarball and a hash, '.sha1', and sign that hash, '.sha1.asc'. 152 99:59:59,999 --> 99:59:59,999 Can 'uscan' cope with this and check the signature on the hash and that the hash 153 99:59:59,999 --> 99:59:59,999 belongs to that tarball ? 154 99:59:59,999 --> 99:59:59,999 [Daniel] I do not believe that 'uscan' can do that currently. So anybody out there 155 99:59:59,999 --> 99:59:59,999 who wants to make things better for the world should go hack on 'uscan': 156 99:59:59,999 --> 99:59:59,999 that is a pretty straightforward thing that we should fix because I agree 157 99:59:59,999 --> 99:59:59,999 that is common pattern. 158 99:59:59,999 --> 99:59:59,999 [someone] I have no answer to this question by I have another question: 159 99:59:59,999 --> 99:59:59,999 how do you convince upstreams who do not release tarballs or who do 160 99:59:59,999 --> 99:59:59,999 not set tags in Git ? 161 99:59:59,999 --> 99:59:59,999 [Daniel] Who do not make tags in Git ? 162 99:59:59,999 --> 99:59:59,999 [someone] Yes, if there is no tags you can not check out a tarball. 163 99:59:59,999 --> 99:59:59,999 Is there any good way to convince upstream to do this ? 164 99:59:59,999 --> 99:59:59,999 [Daniel] Git has this nice feature, which is that you can create a tag, 165 99:59:59,999 --> 99:59:59,999 which is associate with a particular revision, 166 99:59:59,999 --> 99:59:59,999 and you would like to have a tag everywhere that a tarball has been 167 99:59:59,999 --> 99:59:59,999 released from. I am tempted to pull up a Git view and show people some tags. 168 99:59:59,999 --> 99:59:59,999 The question that you ask is a social one, not just a technical one, 169 99:59:59,999 --> 99:59:59,999 and I actually find that my upstreams are pretty responsive. 170 99:59:59,999 --> 99:59:59,999 Usually I frame my request as "hey, it looks like you made this tarball from 171 99:59:59,999 --> 99:59:59,999 this particular commit 'id'. If you could tag you releases, it would be really 172 99:59:59,999 --> 99:59:59,999 helpful to me, and here is the command that I would use to tag the release". 173 99:59:59,999 --> 99:59:59,999 And I say "git tag…" and of course I can never remember so first I look it up, 174 99:59:59,999 --> 99:59:59,999 but it is either 'tag name' 'commit id' or 'commit id' 'tag name'. 175 99:59:59,999 --> 99:59:59,999 But I would look it up and I would write the e-mail so that all they have to do is 176 99:59:59,999 --> 99:59:59,999 they read it, understand my argument, and execute one command. 177 99:59:59,999 --> 99:59:59,999 And then it starts them ?????? 178 99:59:59,999 --> 99:59:59,999 And if you say 'tag -s' then your tag will be cryptographically signed, which 179 99:59:59,999 --> 99:59:59,999 I think is a really good thing to do too. 180 99:59:59,999 --> 99:59:59,999 So, cryptographic verification of upstream. 181 99:59:59,999 --> 99:59:59,999 As I said, I want to keep upstream's code in the revision control system. 182 99:59:59,999 --> 99:59:59,999 I also like to keep… 183 99:59:59,999 --> 99:59:59,999 In my ideal case upstream is using Git: I am using Git for packaging. 184 99:59:59,999 --> 99:59:59,999 I actually like to keep upsteam's Git history fully in my repository, 185 99:59:59,999 --> 99:59:59,999 so that I do not just have the tarballs, but I actually have all of their commits. 186 99:59:59,999 --> 99:59:59,999 And that turns out to be really useful for two specific cases: 187 99:59:59,999 --> 99:59:59,999 In one case, there is a common scenario where upstream will fix a bug, 188 99:59:59,999 --> 99:59:59,999 but they have not made a release yet. 189 99:59:59,999 --> 99:59:59,999 And that bug is really, really obviously problematic for the folks who are 190 99:59:59,999 --> 99:59:59,999 using Debian, so want to fix it. 191 99:59:59,999 --> 99:59:59,999 All I can do, because I have their full revision history, I can use Git to "cherry 192 99:59:59,999 --> 99:59:59,999 pick" the upstream commit. 193 99:59:59,999 --> 99:59:59,999 And then I "cherry pick" that upstream commit and I can have it applied 194 99:59:59,999 --> 99:59:59,999 separately and release an Debian version that has the fix, even before upstream 195 99:59:59,999 --> 99:59:59,999 has made a release with the fix. 196 99:59:59,999 --> 99:59:59,999 So one nice thing about having upstream revision is that I can pull fixes from 197 99:59:59,999 --> 99:59:59,999 upstream before they decided to release it. 198 99:59:59,999 --> 99:59:59,999 The other advantage is the other way around. 199 99:59:59,999 --> 99:59:59,999 Often when I am doing packaging, I discover a problem, 200 99:59:59,999 --> 99:59:59,999 and maybe I can fix the problem. 201 99:59:59,999 --> 99:59:59,999 And if that maybe I am already shipping a Debian package that fixes the problem. 202 99:59:59,999 --> 99:59:59,999 If my Debian fixes can be directly applied to upstream, then I can use whatever 203 99:59:59,999 --> 99:59:59,999 their preferred upstream patch submission guidelines are, 204 99:59:59,999 --> 99:59:59,999 whether it is a Github pull request, or a patch to a mailing list, 205 99:59:59,999 --> 99:59:59,999 or a "hey can you pull this from my Git repository over here", e-mail… 206 99:59:59,999 --> 99:59:59,999 The fact that I am using the same Git history that they are using makes it 207 99:59:59,999 --> 99:59:59,999 much easier for me to push my changes back to them. 208 99:59:59,999 --> 99:59:59,999 So, it sort of smooth the interaction if you can consolidate and use the same 209 99:59:59,999 --> 99:59:59,999 revision control system as their. 210 99:59:59,999 --> 99:59:59,999 Towards that aim, I use a system now called 'patch q', 211 99:59:59,999 --> 99:59:59,999 which is part of 'git buildpackage'. 212 99:59:59,999 --> 99:59:59,999 So 'git buildpackage' is 'gbp', 'patch q' is 'pq', 213 99:59:59,999 --> 99:59:59,999 so to deal with 'patch q' you say 'gbp pq' 214 99:59:59,999 --> 99:59:59,999 and then you have some commands. 215 99:59:59,999 --> 99:59:59,999 And what that does, is it takes… 216 99:59:59,999 --> 99:59:59,999 How many of you are Debian packagers ? 217 99:59:59,999 --> 99:59:59,999 How many of you package software for Debian ? 218 99:59:59,999 --> 99:59:59,999 A very large percentage, but not everyone. 219 99:59:59,999 --> 99:59:59,999 I hope some folks are considering starting packaging if you have not done it yet. 220 99:59:59,999 --> 99:59:59,999 Of those of you who package software, how many of you package software 221 99:59:59,999 --> 99:59:59,999 with modifications, how many of you ship a modified version of upstream sources ? 222 99:59:59,999 --> 99:59:59,999 Beyond the 'debian' directory, just Debian patches ? 223 99:59:59,999 --> 99:59:59,999 So the common way to do that, for the Debian 3.0 ??? packaging skill, is that in 224 99:59:59,999 --> 99:59:59,999 your 'debian' directory you have a 'patches' sub-directory that has a set of 225 99:59:59,999 --> 99:59:59,999 individual patches that apply certain changes, and they are applied in order 226 99:59:59,999 --> 99:59:59,999 based on the file called 'debian/patches/series'. 227 99:59:59,999 --> 99:59:59,999 So maintaining that is kind of a drag when upstream makes big changes: 228 99:59:59,999 --> 99:59:59,999 then all of sudden you have got this set of patches and they do not quite apply… 229 99:59:59,999 --> 99:59:59,999 I is a drag even you do not have it in the 'debian/patches/' directory. 230 99:59:59,999 --> 99:59:59,999 But what Debian 'patch q' does is it maps that directory of patches into a little 231 99:59:59,999 --> 99:59:59,999 branch on your Git revision history. 232 99:59:59,999 --> 99:59:59,999 So when you get a new upstream version, you can say 'patch q rebase', 233 99:59:59,999 --> 99:59:59,999 and it treats it just as Git: it takes the 'patch q'… 234 99:59:59,999 --> 99:59:59,999 You have already imported the new version, and it re-applies your patches, 235 99:59:59,999 --> 99:59:59,999 and sometimes that means some minor adjustments. 236 99:59:59,999 --> 99:59:59,999 Git is really good at figuring out what the right minor adjustments are to make, 237 99:59:59,999 --> 99:59:59,999 and so all of the sudden the 'patch q' is re-based, you refresh it in your revision 238 99:59:59,999 --> 99:59:59,999 control system, and there you go. 239 99:59:59,999 --> 99:59:59,999 So I like to use 'git-buildpackage' 'patch q', tagging, as already brought up, 240 99:59:59,999 --> 99:59:59,999 thank you for that, I like to to tag everything that I release, 241 99:59:59,999 --> 99:59:59,999 I like to push that as soon as I can, so that other people who are following 242 99:59:59,999 --> 99:59:59,999 my work can now where my releases come from. 243 99:59:59,999 --> 99:59:59,999 The reason that I like other people following my work is 244 99:59:59,999 --> 99:59:59,999 they can fix my bugs easier. 245 99:59:59,999 --> 99:59:59,999 I make mistakes, everybody makes mistakes, and it is really important to me that 246 99:59:59,999 --> 99:59:59,999 if someone catches one of my mistakes, I can accept their feedback, 247 99:59:59,999 --> 99:59:59,999 their criticism, their improvements, as easily as possible. 248 99:59:59,999 --> 99:59:59,999 I want a low barrier to entry for people to help me fix my problems, 249 99:59:59,999 --> 99:59:59,999 it is selfishness. So I try to patch it and publish this things for people 250 99:59:59,999 --> 99:59:59,999 can find it. 251 99:59:59,999 --> 99:59:59,999 I am ??? on these pretty fast because were are almost at the time. 252 99:59:59,999 --> 99:59:59,999 I like to put in some place where other people get to the them, 253 99:59:59,999 --> 99:59:59,999 at the moment I like to put them in 'collab-maint', 254 99:59:59,999 --> 99:59:59,999 it has some problems but it is better than not publishing your stuff, 255 99:59:59,999 --> 99:59:59,999 and it is nice because it is sort of a public use. 256 99:59:59,999 --> 99:59:59,999 I like to standardize how of my branches are named, so if I am working on 257 99:59:59,999 --> 99:59:59,999 something that has got a stable version, that is for Jessie, I will name the branch 258 99:59:59,999 --> 99:59:59,999 'jessie', because I ??? 259 99:59:59,999 --> 99:59:59,999 ???? multiple branches ??? 260 99:59:59,999 --> 99:59:59,999 I try to push as frequently as I have made something that looks sensible. 261 99:59:59,999 --> 99:59:59,999 I do not feel obliged to push my commits to a public repository when I am still 262 99:59:59,999 --> 99:59:59,999 experimenting, I actually really like to experiment, and I also like to keep track 263 99:59:59,999 --> 99:59:59,999 of my experiments while I am doing them. 264 99:59:59,999 --> 99:59:59,999 So I try to push when there is a sensible set of changes, and I am trying to get 265 99:59:59,999 --> 99:59:59,999 myself to a point where I can understand what I have done, even if it wrong. 266 99:59:59,999 --> 99:59:59,999 If I can get myself to a conceptual point where it is done, I will push my changes 267 99:59:59,999 --> 99:59:59,999 so other people can see what I am working on, and then work from there. 268 99:59:59,999 --> 99:59:59,999 That is OK to push something that is wrong, 269 99:59:59,999 --> 99:59:59,999 as long as you push something that people can understand. 270 99:59:59,999 --> 99:59:59,999 When you make a 'git commit' (if you are working with Git), 271 99:59:59,999 --> 99:59:59,999 One of the things that helps me to think about commit messages… 272 99:59:59,999 --> 99:59:59,999 People often think that commit messages should say "what change you made". 273 99:59:59,999 --> 99:59:59,999 I think that the 'git patch' shows what change what change you have made, 274 99:59:59,999 --> 99:59:59,999 and I thin your commit messages should say "why you made the change". 275 99:59:59,999 --> 99:59:59,999 That is what people really want to read. 276 99:59:59,999 --> 99:59:59,999 If you need to explain technically why the thing that you did 277 99:59:59,999 --> 99:59:59,999 maps to the conceptual thing that you wanted to do, that is fine: 278 99:59:59,999 --> 99:59:59,999 do that in your commit message too. But it is really important to say why 279 99:59:59,999 --> 99:59:59,999 you made the change. It is not just like "initialize variable to 'no'": 280 99:59:59,999 --> 99:59:59,999 OK, we can see that from the patch, but you what you are really saying 281 99:59:59,999 --> 99:59:59,999 is "there was a crash if someone did 'x', 282 99:59:59,999 --> 99:59:59,999 and we are avoiding that crash by setting this to 'no'. 283 99:59:59,999 --> 99:59:59,999 So I like to send patches via email, 284 99:59:59,999 --> 99:59:59,999 so I try to configure Git email, which make it really easy to just 285 99:59:59,999 --> 99:59:59,999 push patches back upstream. 286 99:59:59,999 --> 99:59:59,999 If I am starting taking over a project that somebody else has past on, 287 99:59:59,999 --> 99:59:59,999 and they did not use Git, I will try to restore all of the imports. 288 99:59:59,999 --> 99:59:59,999 I would be happy to talk with people about how to do that, 289 99:59:59,999 --> 99:59:59,999 if you have questions come find me. 290 99:59:59,999 --> 99:59:59,999 I like to keep my files ???? simple: there is a tool 'wrap-and-sort', 291 99:59:59,999 --> 99:59:59,999 that just canonicalizes your files to make them look in a simple and 292 99:59:59,999 --> 99:59:59,999 sensible way. And it is nice because it means that everything is… 293 99:59:59,999 --> 99:59:59,999 It does things like alphabetize your list of build depends, 294 99:59:59,999 --> 99:59:59,999 and brake them out one per line. The nice thing about that, 295 99:59:59,999 --> 99:59:59,999 since you are using revision control, when you make a change 296 99:59:59,999 --> 99:59:59,999 to your build depends, the changes become very easy to see: 297 99:59:59,999 --> 99:59:59,999 "oh, they added one new package here, there is a single '+'". 298 99:59:59,999 --> 99:59:59,999 When ???? so you can see that kind of thing. 299 99:59:59,999 --> 99:59:59,999 I like to use ? deb five ? to format Debian copyright to be machine readable, 300 99:59:59,999 --> 99:59:59,999 it is nice for people who are doing scans of the archive and try reason about 301 99:59:59,999 --> 99:59:59,999 what the patterns are, and licensing of free software. 302 99:59:59,999 --> 99:59:59,999 And if I am doing something really crazy, that is going to make a big change, 303 99:59:59,999 --> 99:59:59,999 I like to use a feature branch in revision control. 304 99:59:59,999 --> 99:59:59,999 So we have got one minute left, I want to open it up for other questions. 305 99:59:59,999 --> 99:59:59,999 ???? 306 99:59:59,999 --> 99:59:59,999 [attendee] You said you are using 'wrap-and-sort' which is nice, 307 99:59:59,999 --> 99:59:59,999 I had learned that ???? editors - 'cme' - do the same job, 308 99:59:59,999 --> 99:59:59,999 and somehow does a better job: it also ??? standard version 309 99:59:59,999 --> 99:59:59,999 if it does not fit, or it makes VCS fields properly has it should be. 310 99:59:59,999 --> 99:59:59,999 'cme fix dpkg-control' fixes your control file. 311 99:59:59,999 --> 99:59:59,999 [Daniel] 'cme' ? And it is in what package ? 312 99:59:59,999 --> 99:59:59,999 [attendee] The package 'cme', in unstable ????. In Jessie it is ???? 313 99:59:59,999 --> 99:59:59,999 [Daniel] You are developing in unstable, that is OK. 314 99:59:59,999 --> 99:59:59,999 'cme' OK, thank you. 315 99:59:59,999 --> 99:59:59,999 Other questions or suggestions, or complains ? 316 99:59:59,999 --> 99:59:59,999 [attendee] If you change the original source code, and do some commits, 317 99:59:59,999 --> 99:59:59,999 how do you convert that into a series of ??? patches ? 318 99:59:59,999 --> 99:59:59,999 [Daniel] I use 'patch q' for that as well, so what I do is I say 319 99:59:59,999 --> 99:59:59,999 "I want to move over to my 'patch q' view of the tree", 320 99:59:59,999 --> 99:59:59,999 and then I make may changes, I make my commits, 321 99:59:59,999 --> 99:59:59,999 and then I say 'gbp pq export', 322 99:59:59,999 --> 99:59:59,999 and it takes the 'patch q' that I am on and dumps it back 323 99:59:59,999 --> 99:59:59,999 into the Debian patches directory. 324 99:59:59,999 --> 99:59:59,999 If you have not use 'gbp pq', I recommend looking into it. 325 99:59:59,999 --> 99:59:59,999 It takes a little while to get used to, and I still screwed it up sometimes, 326 99:59:59,999 --> 99:59:59,999 but it makes easy to fix your mistakes too. 327 99:59:59,999 --> 99:59:59,999 [organizer] Last question ? 328 99:59:59,999 --> 99:59:59,999 [attendee] Do you think it is possible to make this 'patch q' branch 329 99:59:59,999 --> 99:59:59,999 "pullable" by upstream ? 330 99:59:59,999 --> 99:59:59,999 [Daniel] I do not actually think it is possible to make it directly 331 99:59:59,999 --> 99:59:59,999 "pullable" by upstream: I think upstream can cherry pick patches from it, 332 99:59:59,999 --> 99:59:59,999 but I do not see how to make it "pullable". 333 99:59:59,999 --> 99:59:59,999 If someone else does, I would be happy to learn. 334 99:59:59,999 --> 99:59:59,999 [organizer] This was "before last", so last. 335 99:59:59,999 --> 99:59:59,999 [attendee] Do you have a recording of you using the tools that you mentioned, 336 99:59:59,999 --> 99:59:59,999 a video recording would be great, just to show your workflow ? 337 99:59:59,999 --> 99:59:59,999 [Daniel] I do not really know how to do that: if somebody wants to 338 99:59:59,999 --> 99:59:59,999 help me do that I would be happy to do it. 339 99:59:59,999 --> 99:59:59,999 I am going to give one last plug, 340 99:59:59,999 --> 99:59:59,999 I know we are out of time here, sorry. 341 99:59:59,999 --> 99:59:59,999 This tool is called 'gitk'. 342 99:59:59,999 --> 99:59:59,999 This is an example - sorry we should leave - but this the way 343 99:59:59,999 --> 99:59:59,999 that I visualize my revision control system. 344 99:59:59,999 --> 99:59:59,999 We could do a whole other session about 'gitk'. 345 99:59:59,999 --> 99:59:59,999 If you do not try to visualize your revision control system, 346 99:59:59,999 --> 99:59:59,999 you are missing out: try to find a way to visualize stuff, 347 99:59:59,999 --> 99:59:59,999 find one that works for you. 348 99:59:59,999 --> 99:59:59,999 Thanks for coming. 349 99:59:59,999 --> 99:59:59,999 [organizer] Thank you.