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