1 [16:03] <tumbleweed> ok, time to start, I guess
   2 [16:03] <tumbleweed> Hi, I am Stefano Rivera ( http://launchpad.net/~stefanor ), a recentish MOTU.
   3 [16:03] <tumbleweed> Most of what I do at the moment is sponsoring universe packages, so I'm talking about tools to help with sponsoring.
   4 [16:04] <tumbleweed> I've never given (or even watched) an #ubunt-classroom talk before, but feel free to heckle me via the chat channel (I have a thick skin)
   5 [16:04] <tumbleweed> I don't think this will be very long (more time for questions), I don't have that much to cover, but here's what I'm planning to talk about: sponsor-patch, ack-sync.
   6 [16:05] <tumbleweed> I suggest you check out lp:ubuntu-dev-tools and symlink ack-sync to ~/bin. That may also encourage you to contribute :)
   7 [16:05] <tumbleweed> right, so: Why do we want to use tools to help with sponsorship?
   8 [16:05] <tumbleweed> 1. They check for the obvious errors (like closing bugs, updating maintainers)
   9 [16:05] <tumbleweed> 2. They save time (you can do more sporsoring in the same amount of time)
  10 [16:05] <tumbleweed> 3. You make less mistakes. Personally, I do most of my Ubuntu development on Debian machines (my desktop PCs run Debian), so if I forgot to set DEB_VENDOR=Ubuntu I wouldn't automatically close bugs in changelogs.
  11 [16:06] <tumbleweed> sponsor-patch:
  12 [16:06] <tumbleweed> this is a tool recently written by bdrung (who seems to be on holiday atm)
  13 [16:06] <tumbleweed> You call it with a bug number, and it'll download the patch, the source, apply it, test build it, and ask you to confirm the upload.
  14 [16:06] <tumbleweed> For SRUs or other situations with multiple tasks / patches, you'll be prompted to select.
  15 [16:07] <tumbleweed> Example:
  16 [16:07] <tumbleweed> 1. I find this bug on the sponsor list http://launchpad.net/bugs/584997
  17 [16:07] <tumbleweed> 2. I read the bug, scan the patch, and see that it's good to go. (it seems a bit over the top to introduce quilt, but it's already got SRU approval)
  18 [16:07] <tumbleweed> 3. I call sponsor-patch -e 584997
  19 [16:08] <tumbleweed> err, -s
  20 [16:08] <tumbleweed> 4. http://paste.ubuntu.com/487288/
  21 [16:08] <tumbleweed> 5. You can see that I run into a mistake by the patch-author, so I fix it and let it try again.
  22 [16:09] <tumbleweed> 6. I read the debdiff and lintian output, and approve the upload
  23 [16:09] <tumbleweed> 7. mark uploaded on LP, manually, and unsubscribe sponsors
  24 [16:10] <tumbleweed> that's that, and it's all quite quick and painless. I find it faster than pulling source packages and curl | patch -p1
  25 [16:10] <tumbleweed> ack-sync:
  26 [16:11] <tumbleweed> ack-sync is pretty much the same thing, but for sync requests. It uses syncpackage to prepare a sync from debian, and (if it builds) allow you to upload to ubuntu.
  27 [16:12] <tumbleweed> there is still some uncertainty around whether syncpackage is archive-admin-friendly or not, but I haven't done any damage with it (yet?) so I'm using it until someone tells us not to.
  28 [16:12] <tumbleweed> If you don't approve of syncpackage, you could just not allow ack-sync to do the upload, and manually mark it ACKed.
  29 [16:13] <tumbleweed> The process:
  30 [16:13] <tumbleweed> 1. ack-sync $BUGNUMBER
  31 [16:13] <tumbleweed> ack-sync will find who requested the sync, and set them as the uploader for the synced package. It'll mark the bug as being "In progress" by you, and unsubscribe ubuntu-sponsors
  32 [16:14] <tumbleweed> once built, if you approve the upload, it'll mark it "Fix Committed"
  33 [16:14] <tumbleweed> (pretend those were numbered points)
  34 [16:15] <tumbleweed> ack-sync can take multiple bug numbers if you have a big pile of syncs to review, so reviewing syncs can be quite quick
  35 [16:15] <tumbleweed> one issue you may run into: If the sync requester doesn't have a public e-mail address on launchpad (and isn't an ubuntu member - who would have an ubuntu.com address), then it'll abort because it needs an e-mail address for the .changes
  36 [16:16] <tumbleweed> you can create a CSV file (Name, e-mail address) for such people as you encounter them. It'll read ~/.ack-sync-email.list
  37 [16:17] <tumbleweed> obviously we do more review on syncs than just testing that they build.
  38 [16:17] <tumbleweed> Personally, I use grab-merge to pull the debian and ubuntu source (and pre-generated patches)
  39 [16:18] <tumbleweed> Recently, when MoM was on an extended holiday (downtime) I wrote a tool that is equivalent to grab-merge, but uses the UDD branches we have for every package in Debian/Ubuntu (almost every package, some are out of date)
  40 [16:18] <tumbleweed> lp:~stefanor/ubuntu-dev-tools/grab-udd-merge
  41 [16:19] <tumbleweed> it does a bzr checkout of both the Debian and Ubuntu UDD branches, and performs a merge-package. Then it generates debdiff-like diffs.
  42 [16:19] <tumbleweed> I find this very useful as a review tool, but I'm a little hesitant about putting it in ubuntu-dev-tools, because I'm not sure we are ready for merge requests to come in the form of bzr branches
  43 [16:20] <tumbleweed> they are hard to review in launchpad's merge review system, because we are normally more interested in the diffs against debian than the diff against the previous ubuntu version
  44 [16:21] <tumbleweed> grab-udd-merge can be used to review such merges (it'll generate the patches you want to see), call grab-udd-merge lp:~some-developer/some-package/merge-XXXXX
  45 [16:21] <tumbleweed> and that's about all the material I have to cover. Questions?
  46 [16:24] <tumbleweed> the bot doesn't seem to have any questions for me (was anyone even listening?). Feel free to heckle me about this stuff any time :)


Packaging/Training/Logs/2010-09-02 (last edited 2010-09-03 21:09:47 by 99-21-107-94)