[06:33] <vishu> hey guys
[16:03] <tumbleweed> ok, time to start, I guess
[16:03] <tumbleweed> Hi, I am Stefano Rivera ( http://launchpad.net/~stefanor ), a recentish MOTU.
[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.
[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)
[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.
[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 :)
[16:05] <tumbleweed> right, so: Why do we want to use tools to help with sponsorship?
[16:05] <tumbleweed> 1. They check for the obvious errors (like closing bugs, updating maintainers)
[16:05] <tumbleweed> 2. They save time (you can do more sporsoring in the same amount of time)
[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.
[16:06] <tumbleweed> sponsor-patch:
[16:06] <tumbleweed> this is a tool recently written by bdrung (who seems to be on holiday atm)
[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.
[16:06] <tumbleweed> For SRUs or other situations with multiple tasks / patches, you'll be prompted to select.
[16:07] <tumbleweed> Example:
[16:07] <tumbleweed> 1. I find this bug on the sponsor list http://launchpad.net/bugs/584997
[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)
[16:07] <tumbleweed> 3. I call sponsor-patch -e 584997
[16:08] <tumbleweed> err, -s
[16:08] <tumbleweed> 4. http://paste.ubuntu.com/487288/
[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.
[16:09] <tumbleweed> 6. I read the debdiff and lintian output, and approve the upload
[16:09] <tumbleweed> 7. mark uploaded on LP, manually, and unsubscribe sponsors
[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
[16:10] <tumbleweed> ack-sync:
[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.
[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.
[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.
[16:13] <tumbleweed> The process:
[16:13] <tumbleweed> 1. ack-sync $BUGNUMBER
[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
[16:14] <tumbleweed> once built, if you approve the upload, it'll mark it "Fix Committed"
[16:14] <tumbleweed> (pretend those were numbered points)
[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
[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
[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
[16:17] <tumbleweed> obviously we do more review on syncs than just testing that they build.
[16:17] <tumbleweed> Personally, I use grab-merge to pull the debian and ubuntu source (and pre-generated patches)
[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)
[16:18] <tumbleweed> lp:~stefanor/ubuntu-dev-tools/grab-udd-merge
[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.
[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
[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
[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
[16:21] <tumbleweed> and that's about all the material I have to cover. Questions?
[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 :)
[16:51] <ClassBot> There are are 10 minutes remaining in the current session.
[16:56] <ClassBot> There are are 5 minutes remaining in the current session.