=== Mrokii_ is now known as Mrokii === zumbi is now known as _ === _ is now known as Guest45422 === zumbi_ is now known as zumbi [12:01] where can I find this channel's history? [12:01] !logs [12:01] For Ubuntu Classroom logs, please visit http://irclogs.ubuntu.com [12:02] thank you very much :) [14:58] Two minutes til start time... === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: When and how to schedule releases using Launchpad - Instructors: mterry [15:00] Looks like 14:00 UTC. Welcome to the "When and how to schedule releases using Launchpad" talk! [15:01] I've got some prepared notes that I'll go through, but feel free to ask questions in #ubuntu-classroom-chat [15:01] First a quick background of who I am. I'm Michael Terry, I work in the Desktop team at Canonical. But more relevant for this talk, I've maintained several projects in the past. I have maintained some small apps (xpad, gmult) as well as an app that has become more popular (deja-dup). [15:01] So I'll talk a bit about release management, different ways of scheduling releases, and a bit about how to use Launchpad to help with that [15:02] There are two common release strategies: feature based and time based. I've used both, sometimes on the same project at different times. [15:02] Feature based tends to be the strategy most application developers use when starting personal projects. You're just hacking away by yourself until it's functional. Then you release. [15:03] Maybe next you get some bug reports or an idea for a feature, and you hack away again until that new feature is done or some common crash bug is fixed. Then you release. [15:03] This is a pretty common cycle and is very good for getting stuff out the door. It's simple, easily understood, and only requires that you be able to decide what features or bugs a release will wait on. [15:03] Of course, you need agreement about what the release criteria are, but I'll get to that later [15:04] Another popular method is a time based release schedule. This is where you say, I'm going to make a new release every month, or every 3 months, or whatever. [15:04] This method is in vogue for many of the big open source projects, like Ubuntu, Fedora, and GNOME. [15:05] It makes it easy to plan releases with lots of moving parts and developers, since the schedule and release criteria are obvious to everyone. [15:05] Lots of joiners. Were you all interested in this talk? Should I briefly recap? [15:06] OK, moving on until I see some complaints [15:06] As for pros and cons... [15:06] I find that when I'm using a feature based schedule, I have a habit of making changes until the last minute and potentially introducing bad bugs. This tends to happen because the release can happen any time after the last feature gets committed [15:07] That's when I end up making 'brown paper bag' followup bug fix releases (i.e. you were a brown paper bag over your head in shame). [15:07] That's one benefit of the time based schedule: you can plan 'baking' time into your schedule and say, "no more feature work during the last month. Just bug fixes." [15:08] Of course, you can do this with feature releases too and just say that after the last feature is done, you'll just sit on the code for a month. But in practice, I find that doesn't happen. [15:08] But feature schedules are useful too. I generally prefer feature based releases for the first 6 months or year of a project. That's when the most churn happens and you have less users affected by potentially less careful releases. [15:09] It lets you iterate very fast on often incomplete code. I recommend it for most starting/small/personal projects. [15:10] If you do choose a time based schedule, don't make it stressful one. Most projects seem to use 6 months, and that's about right. Maybe with monthly checkpoint releases. And most of the feature work front-loaded. [15:11] But whatever, it's a matter of personal preference and what works for you. I've got a link to a really fascinating Ph.D paper studying how different projects have used different schedules, analyzing optimal cycle lengths for time based projects, and the like. http://www.cyrius.com/publications/michlmayr-phd.html [15:11] Any questions? Or is 14:00 UTC too early? :) [15:13] I've used feature releases early on several of my projects then switched to time based as it became popular, more polished [15:13] Time releases are very good for making sure regressions don't appear (easier for testers to plan on releases) [15:14] And generally good for a project in 'maintenance mode'. You can still add big features, it may just take more than one cycle to finish landing it [15:14] Especially once you get more contributors than just yourself, it really helps to have a common schedule [15:15] It can be frustrating as a maintainer to be holding a release for a feature from someone else in this inherently asynchronous development style that FOSS projects have [15:15] With time releases, they either get it in on time or not, but the release can go forward [15:16] Also, I highly recommend the Ph.D paper link I gave earlier if you're interested in this stuff. It's very interesting reading (once you get to the findings part) [15:17] OK, on to a quick introduction of Series and Milestones! [15:17] However you decide to release, Launchpad has some simple tools to make keeping track of planned work. Namely, Series and Milestones. [15:18] Series are just separate 'branches' of development. Say you release version 14 of your software and start work on version 15. Now you need to be able to separate maintenance work on 14 from new feature work in 15. [15:18] If a critical bug is found in 14, you want to be able to keep track of that fact and keep a snapshot of 14's code around to make it easy to make further bug fix releases from it. [15:19] That's what Series do. They're a place to keep code and bugs separate from other series. [15:19] If you want to play around with Launchpad's series or milestones, open https://staging.launchpad.net/ [15:19] It's a testing version of launchpad where they throw away any modifications each day [15:20] So you can screw around and create a project, add series and milestones, etc. [15:20] Just to get a feel for it [15:20] Anyway [15:20] Milestones are just planned releases. You may create a milestone for release 15 ahead of time and then you can mark bugs to be fixed by that release. Milestones are associated with a particular series. [15:21] I usually find it most convenient to keep a trunk series always around where I do development, and when I release a new stable version, to create a new series for its maintenance lifecycle. [15:21] This is called a trailing series. Each release gets spun off after I finish it in trunk. [15:22] You can also have leading series, where you create a separate unique series for your next release ahead of time. [15:22] I don't find this nearly as convenient, as a developer, but your mileage may vary [15:23] You can also mark series as obsolete once you're really done with them (say, you've released a newer stable release) [15:23] That way they won't show up in the UI. Otherwise, you'd be drowning in series [15:24] You can see an example of a more complicated series layout with my project deja-dup (https://launchpad.net/deja-dup/+series). You can also see that I used to use feature releases until version 14, when I switched to track GNOME's time based releases. [15:24] And right now, trunk is where the next version (18) is being developed [15:25] If you're using feature releases, you don't *need* to take full advantage of milestones. You really probably just care about the next unstable and next stable releases. So one 'future' milestone fore each series is fine. [15:26] But if you've got big plans and a whole project roadmap based around features (like 1.0 will have X, Y, and Z, but along the way, 0.5 will mean X is done, 0.7 will mean Y is done, etc), that can be useful [15:27] The projects I've seen try to do that never hit their targets and always push features back. Again, it's a lot more reliable to use time based releases, if you're going to be doing all that release planning overhead anyway. [15:27] Features still get pushed back, but you didn't promise features, only a timely release. ;) [15:28] For time based releases, I like to set up all the releases ahead of time as milestones so it's easy to keep track. I'll often assign bugs that I know I want to finish during this cycle to the last milestone, and adjust that milestone when I actually implement it to the actual release in which it got fixed. [15:28] Milestone pages on Launchpad are very nice. They tell you what bugs were/are targeted for the release and what their status is. Let me dig up a URL [15:28] https://launchpad.net/deja-dup/16/15.92 [15:29] So here you can see that there were 6 bugs I targeted for the release, the release notes, etc. Also useful when planning a future milestone, so the whole team can see what bugs the maintainer wants to see fixed for that release [15:30] For a nice overview of some of this same material, there's actually a nice LP help page: https://help.launchpad.net/Projects/SeriesMilestonesReleases It talks about leading/trailing series and how to set milestones up too. [15:31] That's all the prepared material I had. I've got *so* much time for your questions about the exciting field of release management! [15:32] Join #ubuntu-classroom-chat and ask questions like "QUESTION: what's the meaning of life, the universe, and everything?" [15:33] Again, I just want to pimp the case study done on several FOSS projects and their release methodologies. It's fascinating stuff! http://www.cyrius.com/publications/michlmayr-phd.html [15:34] I'll hang around a bit, in case anyone wakes up. If you see this talk in your chat logs later and want to talk release-shop, just grab me on IRC sometime or in person at UDS in Orlando [15:39] jledbetter_ just reiterated in the chat room that coding up to release can be dangerous. One way to mitigate that is automated tests. Which is a whole 'nother talk. But... [15:39] If you do have test-driven coding, so that features and tests land at the same time, you can be slightly more confident with feature-releases [15:40] Of course that requires good discipline, and even tiny changes that you don't think need a full test can break things unexpectedly right before a release [15:41] One thing you could do if you really like feature releases is do a 'testing/alpha release' before each release to let people test it and report back [15:42] But generally, smaller projects don't have enough of a community to do that. So I'd say if you're project is small/new, just pump out dangerous feature releases while you are energized and coding like a monkey, until you stabilize, then use time based releases [15:46] jledbetter_ asked: Just to be clear, I can do all kinds of experimentation with https://staging.launchpad.net/ and it'll go away nightly? [15:47] jledbetter_, Yup. It's pretty neat. I don't know when the cutoff is. 00:00 UTC? But it resyncs from the main instance every day or so [15:47] It's also pretty slow... [15:48] But it's a good way to experiment with some Launchpad button if you don't know what it will do first. :) [15:52] Alright, thanks everyone. Hope it was useful! I expect to see many more well-released projects keeping track of things using proper series and milestones! :) === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Pollka and the Ubuntu Women Mentoring Partnerships - Instructors: elky, nigelb [16:01] Hi folks! [16:02] * nigelb waves [16:03] hi all [16:05] Some of you might remember earlier this year when the Ubuntu Women team ran some competitions. [16:06] These competitions involved voting, and that voting was collected by a little bit of php that I whipped up over the course of a few mornings. [16:07] This code is what has become Pollka, and which was also used recently by AlanBell for the Ubuntu-UK logo selectoin [16:08] Currently the code resides on Launchpad, https://launchpad.net/pollka [16:09] Pollka is a relatively new project and we only have a few active committers. The aim of making pollka a project is to facilitate mentoring, using launchpad tools, etc. [16:11] ok, so pollka is a php application as elky said [16:11] it stores some information in a database, we are using mysql, but other databases should also work or be fairly easy to plug in [16:12] as it is a voting application on a set of images these also need to be stored somewhere, and we store them on the filesystem [16:12] there are both full size images and thumbnails [16:12] lets take a quick look at a running pollka instance [16:12] http://pollka.libertus.co.uk/ [16:12] this is the voting system we used in the UK loco for our new logo [16:13] we put up an assortment of design proposals and voted on the one we liked the best [16:13] I had a bit of fun hacking about with the code, thus the options were "full of win" for pictures you like and "meh" for those you don't like [16:14] part of the point of Pollka is a learning project to hack about with, not a shiny packaged solution where you don't look under the covers [16:14] so installing Pollka starts with getting the code, it is stored on Launchpad in a bzr repository [16:14] launchpad and Ubuntu work really really well together (unsurprisingly) [16:15] so to get the code you would run [16:15] bzr branch lp:pollka [16:15] you might need to install bzr first with sudo apt-get install bzr [16:16] another way to get the code is to use the most awesome groundcontrol project by doctormo [16:16] this is also in the repositories so you can look up groundcontrol in the software centre [16:17] then in /home/myname/Projects in nautilus you can get a project and it will download a copy of pollka for you [16:18] the file db.sql in the repository is a kind of starting database structure [16:18] you can import that into mysql to create a bunch of tables in the right places [16:18] I installed phpmyadmin and imported it through that because I suck at command line stuff [16:19] phpmyadmin is a web based interface to mysql and it makes things really easy [16:19] lets see, I wonder if I can let you have a play with it . . . [16:20] yes, OK [16:20] so I am going to let you log on to my server (which is sitting on top of the bookshelf behind me) [16:21] you will be logging in as the pollka user, so I don't think you will be able to damage anything other than the already closed logo vote [16:21] http://pollka.libertus.co.uk/phpmyadmin [16:21] username polka [16:21] nope [16:21] username is pollka [16:21] password is dmQdLQwsbunjtqwj1 [16:21] you might want to copy and paste that one [16:22] on the left you can click the pollka database and see the tables [16:22] everyone there? [16:23] right, everyone is poking about successfully [16:24] if you click on the browse icon next to the conf table you can see various bits of configuration [16:24] feel free to tweak bits, like the site status or the poll name [16:25] have a look at what it dose [16:25] does [16:25] oh noes some hacker has hacked it :) [16:26] have a look at the questions table [16:26] here we list the options available [16:26] I kinda misused the question_author field [16:27] as my poll didn't really have different authors for the 'photos' [16:27] I also hacked about with the image field because the thumbnails are .png files and you click to get the .svg which wasn't in the original poll design [16:28] ok, prevotes [16:28] so, flip back to the front of the site and cast your vote [16:28] what this does is populate the prevote table with a random key and the options you selected [16:29] you will then get an email (from me because of what is set in the conf table) [16:29] on that email will be a link with the random token in it [16:30] when you go to the token URL in the mail the token.php.active page will look up the votes in the prevote page and copy them to the votes table [16:31] there is a certain amount of anonymisation, in the voter table we have the timestamps and IP addresses and email addresses, these don't link directly to the votes cast [16:31] which is kinda good in some ways to voting geeks, but a bit of a drawback if you want to deal with someone who voted twice or something [16:32] it does check on submit that the email is unique [16:33] ok, lets go prod some code now [16:33] https://code.launchpad.net/~pollka-devs/pollka/trunk [16:33] of course if you have ideas on how to improve this, we're happy to help you implement [16:34] on that page you can see a summary of the bzr repostitory [16:34] at the bottom you can see that 8 revisions have been made by different people [16:34] bzr keeps all the versions in check and deals with branches and merges so you can have multiple people working on the code and they don't get in each others way too much [16:35] as nigelb mentioned in the chat, to commit to the repository you need to be in the pollka-devs launchpad team [16:35] anyone can read and take a branch of the repository though [16:36] the great thing about bzr is that you don't have to be scared of breaking anything. [16:37] you can poke about in the code, change things in a way that *you* like and it is easy to maintain your code or push it back to the core project if it is generally useful [16:37] some of my modifications (such as the .png/.svg image pairs) are probably of little interest outside of this particular instance [16:38] others however (like a security patch to prevent SQL injection hacks) are of general interest so got pushed back [16:38] QUESTION from daker: i see two conf keys, site_status and fave_status, what do they mean ? [16:39] daker: the fave_status controls the second vote you have at the bottom [16:39] so for each image you can give it +1 or +0 [16:39] The site can be enabled or disabled for voting, thats site_status [16:39] and then at the end you can give your absolute mostest favouritest picture an extra +1 [16:39] or turn that feature off [16:40] http://bazaar.launchpad.net/~pollka-devs/pollka/trunk/files [16:40] the main pollka branch has a basic admin panel, i dunno if AlanBell's mutant does or not though [16:40] my mutant has that removed [16:41] good point though, the admin.php was there so you don't have to go tweak too much directly in mysql [16:42] ok, so looking further into the repostory at the link above we can see the files that make up the application [16:42] there is admin.php which is the admin console [16:43] the main site is the index.php files (the site has two modes, index.php.active and index.php.inactive) [16:43] there are the results pages [16:43] http://pollka.libertus.co.uk/results.php [16:44] a stylesheet which I tweaked to fit with the new ubuntu branding, I think the default pollka one is less ubuntuish [16:44] and there are the token.php files for processing votes [16:45] in the includes folders there are some other files including the one that connects the php files to the mysql database [16:45] http://bazaar.launchpad.net/~pollka-devs/pollka/trunk/annotate/head:/includes/dbcon1234567890.php [16:45] which includes the classic elky code "die('Could not connect to the database. No pony for you: ' . mysql_error());" [16:46] it is also the file in which you edit to add the mysql username and password you want it to use when talking to the database [16:47] http://bazaar.launchpad.net/~pollka-devs/pollka/trunk/annotate/head:/index.php.active [16:47] that is the main file that does the work of presenting the list of options to the user [16:48] the observant will spot several places where there are hard coded references to the original competition [16:48] 38 [16:48] $subject = "Your World Play Day 2010 Photo Competition Vote"; [16:48] for example [16:48] these should all be recoded as stuff to go in the conf table [16:48] heh, i really should finish fixing all that some time [16:48] there are plenty of things that need doing with this code, which is fine [16:49] (note, hardcoding is bad. this was done in a hurry :P) [16:49] the project is now a mentoring and learning testbed [16:49] or sandpit [16:50] the project is kinda small, with little bugs here and there, ideal as a starter project to get to grips with php [16:50] and bzr [16:50] and relational databases [16:50] and ubuntu packaging [16:50] we should probably close up the tutorial bit now and move on to explaining the UW mentoring partnership program [16:50] and launchpad bug system [16:50] yup [16:50] so it is a lovely little project with lots of stuff to do on it [16:51] started in the Ubuntu-Women project and it is now a mentoring subject for that project [16:51] http://wiki.ubuntu-women.org/MentoringFAQ [16:52] Pollka is like a proof of concept project for the mentoring framework we're trying to morph ^that in to [16:52] https://blueprints.launchpad.net/ubuntu-women.org/+spec/community-n-ubuntu-women-mentor-partnerships [16:53] I'll be talking with people later this month at the Ubuntu Developer Summit on the topic of refining the mentoring partnershps blueprint [16:54] I'd love to see feed back from people on the wikipage linked from there. What do you want from mentoring, etc. [16:54] We're also open to hearing from other applications who may want to partner with us to provide clear pathways for the UW team to guide its members along. [16:56] Ok, any questions for the next 5 mins or so? [16:57] where can we find out more elky? [16:57] sbout? [16:57] pollka [16:57] pollka.net [16:58] yay, a wiki, so anyone can contribute to the documentation as well as the code [16:58] thanks for helping host this session AlanBell. its been much more coherent than my cold-addled brain would have managed [16:58] :) [16:59] I will be changing the mysql password on that database later === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || [17:20] QUESTION: where can I learn more about TCSH? === MSK61 is now known as MAfifi === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Posting into social networks from your app - Instructors: kenvandine [18:02] ok, so lets get started here [18:03] I am Ken VanDine, an engineer on the Ubuntu Desktop team and a Gwibber developer. Today we'll talk about desktop integration with social networks, by adding social features to desktop applications. [18:04] an introduction to libgwibber [18:04] What is libgwibber? [18:04] libgwibber is a library to provide applications access to the gwibber desktop service. It is very important to us to be able to integrate a wide variety of desktop applications with gwibber. The end goal being as transparent as possible, and simplifying the social experence on the desktop. We want the users to be able to easily interact with their friends via social networks while be contextually relevant. For example w [18:04] hen you are browsing photos of your kids 1st birthday party in shotwell, you might want to tag some of your friends that attended the party. Instead of going to the facebook website, uploading photos and then tagging, you should be able to do it right there while you are already viewing or even while importing the photos from your camera. [18:05] Let me give you a concrete example to help illustrate why you should care. [18:05] *you* being an application developer [18:05] Wouldn't this just rock? [18:05] * Plug in your camera [18:06] * shotwell (or your favorite photo library tool) pops up and prompts you to import photos [18:06] * You select the photos you want to import into your library [18:06] * Add comments below the previews [18:06] * Tag friends in the photos [18:06] * And choose to share or not automatically after importing (sharing being uploading to some default online album, like facebook) [18:07] in that scenario, the user is already doing something with their photos, so it makes sense to integrate other things they might want to do in the work flow [18:08] Ok, enough talking about why we want to do this... chances are if you are here you probably already understand. [18:08] Lets talk about how you can use libgwibber in your application. [18:08] Unfortunately the gtk-doc generated docs aren't very useful yet, and if someone wants to help get the annotations in the vala code to make it into the generated C code so gtk-doc can pick it up, please let me know :) [18:09] we really need to figure out how to generate developer docs for the API for C, vala, mono and python [18:09] tricky :) [18:10] There is libgwibber, and libgwibber-gtk. I think most people will just use libgwibber-gtk, which provides gtk widgets you can just drop into your application. [18:10] Currently libgwibber-gtk only includes an Entry widget, which includes: [18:11] * text input box [18:11] * character counter [18:11] * account target bar with toggle buttons for accounts [18:11] * send button [18:11] * url shortening [18:11] * and online/offline detection [18:11] to answer rooligan's question, libgwibber is written in vala which builds a shared library [18:12] which works with C, and we include mono bindings and with introspection python [18:12] moving on [18:12] Screenshot of the entry widget in use: [18:12] http://blogs.gnome.org/kenvandine/files/2010/08/libgwibber-entry-1.png [18:13] that is just a simple gtk window with the entry widget [18:14] This can be embedded anywhere you could put a VBox (Gwibber.Entry is based on Gtk.VBox). [18:15] you'll notice it looks very similar to the input on the bottom of the gwibber client UI [18:15] the goal has been to replace the python one with this one to consolidate the code base [18:16] but it didn't play too well with the gwibber client for some reason, related to introspection and gtk [18:16] it'll happen for gwibber 3.0 though [18:17] lets look at some snippets of code [18:17] embedding the gtk widget should be simple, and as we add more widgets we will make sure we keep it just as simple [18:17] Vala: [18:17] var entry = new Gwibber.Entry (); [18:17] your_container.add (entry); [18:18] C: [18:18] include [18:18] ... [18:18] GwibberEntry* entry = gwibber_entry_new (); [18:18] gtk_container_add ((GtkContainer*) your_container, (GtkWidget*) entry); === harrisonk is now known as harrisonk_away [18:19] and for getting the CFLAGS and all, if you are using autotools just added a pkgconfig check for gwibber-gtk [18:19] Mono: [18:19] Gwibber.Entry entry = new Gwibber.Entry (); [18:19] YourContainer.Add (entry); [18:19] and [18:19] Python: [18:19] from gi.repository import GwibberGtk [18:19] ... [18:19] entry = GwibberGtk.GwibberEntry() [18:19] your_container.add(entry) [18:20] in these examples, "your_container" could be anything gtk container [18:20] a window, etc [18:21] so could nest it in your app so it automatically shows/hides based on either what the user does or even if the gwibber service is available and configured [18:21] so you could hide it if there are no accounts available [18:22] this is what the MeMenu in Ubuntu does, that posting entry is only displayed if you have accounts configured in gwibber [18:22] so users that don't use gwibber won't even see it [18:22] libgwibber provides a signal to watch [18:23] for some complete examples, you can look in the examples directory in a bzr checkout of lp:gwibber/libgwibber [18:23] or [18:23] http://bazaar.launchpad.net/~gwibber-committers/gwibber/libgwibber/annotate/head%3A/examples/entry-vala.vala [18:23] http://bazaar.launchpad.net/~gwibber-committers/gwibber/libgwibber/annotate/head%3A/examples/entry-mono.cs [18:23] http://bazaar.launchpad.net/~gwibber-committers/gwibber/libgwibber/annotate/head%3A/examples/entry-c.c [18:23] http://bazaar.launchpad.net/~gwibber-committers/gwibber/libgwibber/annotate/head%3A/examples/entry-python.py [18:24] hopefully this is helpful [18:24] i think for most developers, embedding the entry widget will accomplish the goal [18:25] and add value to your application as well as helping us make ubuntu more social [18:25] for the natty cycle, we will be adding more widgets [18:25] i hope pieces needed to add the experience i described earlier to shotwell [18:26] we need image uploading added to gwibber and some sort of contact selector that aggregates sources for picking friends [18:26] there will also be account/stream selector widgets as well as stream view widgets [18:27] the stream view is what you see in the current gwibber client, where it renders the posts [18:27] and the navigation on the left is the stream selector [18:27] we'll make those into libgwibber-gtk widgets and then then client will just consume those widgets [18:28] hopefully that will come with a fresh new look to the client :) [18:29] now on to libgwibber [18:29] If you want to use the gwibber service without using the Entry widget, you can use libgwibber for more direct access. [18:30] i'll talk about a few of the most common tasks you might want in libgwibber [18:30] Gwibber.Service object includes: [18:31] * version() # returns the version of the currently running gwibber-service [18:31] * refresh() # triggers a refresh [18:31] * quit() # shuts down gwibber-service [18:31] * send_message("Some string to post") # posts a message to all account that have send_enabled = True [18:31] * is_available # signal you can connect to so you can find out when the service comes online (sends a bool) [18:32] Gwibber.Accounts object includes: [18:32] * list() # lists accounts [18:32] * send_enabled("account_id") # toggles send_enabled state of the given account [18:32] * lookup_by_id("account_id") # returns account attributes for a given account [18:32] * account_updated # signal which sends an account when it has been changed [18:33] Gwibber.Service is about interacting with the service, making it do things for you for example [18:34] Gwibber.Accounts is for retrieving or manipulating accounts [18:35] for example, if you want to show/hide a posting widget (like the entry widget we talked about earlier) [18:35] you would connect to the Gwibber.Service.is_available signal [18:35] when you get a True from that signal, you would query Gwibber.Accounts.list() and find accounts that are enabled [18:36] if there are any, then display it [18:36] on the converse, after you show the entry [18:36] if you get a False from Gwibber.Service.is_available, you can hide it [18:36] or destroy [18:36] whatever [18:37] also, you could connect to the account_updated signal, so you can see when accounts change and hide/destroy when there are no longer any accounts enabled [18:37] for example [18:37] libgwibber uses GObject introspection for python support, which is still quite new and some of the libgwibber methods don't behave well. Fortunately the Gwibber.Service methods, which are generally what most application developers will want, work fine. This will improve for natty. [18:38] so for example if you use python and want to get a list of accounts, it will crash :/ [18:38] it isn't handling the conversion of the resulting data type [18:39] a known problem area with python and gobject introspection [18:39] however, all the methods interacting with the service work [18:39] which is what you will most like care about [18:40] Here are some examples: [18:40] http://bazaar.launchpad.net/~gwibber-committers/gwibber/libgwibber/annotate/head%3A/examples/example-vala.vala [18:40] http://bazaar.launchpad.net/~gwibber-committers/gwibber/libgwibber/annotate/head%3A/examples/example-mono.cs [18:40] again, you can find those in a bzr checkout in the examples folder [18:40] rooligan asked: For which programming language is libgwibber? [18:40] whoops [18:41] rooligan asked "How to install libgwibber?" [18:41] libgwibber0 is included in maverick by default, to get the gtk widgets just install libgwibber-gtk0 [18:42] actually to build against it, you'll want libgwibber-gtk-dev or libgwibber-dev [18:43] to use it with python you'll need gir1.0-gwibber-gtk-0.0 and/or gir1.0-gwibber-0.0 [18:43] for mono you'll need libgwibber-gtk0.0-cil-dev and/or libgwibber0.0-cil-dev [18:44] any more questions? [18:44] or does anyone have applications in mind they might want to hack on adding social features? [18:45] i would love to find areas people are interested, especially if they might require adding functionality to gwibber/libgwibber that isn't already there [18:45] or maybe if anyone wants to work on shotwell :) [18:47] ok, no more questions then... [18:47] i'll post the bulk of the content from here on my blog later today, which you can find on planet.ubuntu.com [18:48] you can find me most anytime in #ubuntu-desktop [18:48] please feel free to ping me anytime with questions or suggestions [18:49] or if you want to contribute to gwibber, libgwibber or any other application [18:50] thanks everyone for your time! === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Automating tasks with Launchpad, Tarmac and Source Package Recipes - Instructors: rockstar [19:02] Hi folks. My name is Paul Hummer. I'm a contributer to the Launchpad project, and I happen to also get paid for it, so that works out nicely. [19:02] First, give me a second to read about this new-fangled ClassBot thing. [19:03] Okay, let's get started. [19:03] Today, I'm going to talk to you about automating the really menial tasks that come as part of working on a free software project.s [19:04] The less time you spend working on menial things, the more time you can use to write code and do awesome things. [19:04] DISCLAIMER: Date math is hard. It turns out that I signed up for a time that overlaps when I want to eat. [19:04] This means that if I paused for a bit, it's because I'm attempting to force food into my mouth. Feel free to ask questions during this time. It makes me look not quite as bad. :) [19:06] I'm assuming everyone here has a bit of understanding with regards to Launchpad. [19:06] If you don't have any idea what Launchpad is, well, you might be a little lost. [19:07] Some of the features of Launchpad that I'm going to talk about today are relatively new, and we still consider them either "in beta" or "we're just barely talking about making them." [19:07] Rest assured, those features are coming. [19:08] Does anyone here have a project they've got in mind as I talk about automating tasks with Launchpad? [19:09] (I ask because most of my projects already use a lot of these practices, so it's kinda hard to walk through the transition) [19:10] Okay, well, I guess we'll move ahead with a hypothetical project. [19:12] Let's say that Sarah Jane is an opportunistic hacker who used Quickly to set up her project. [19:13] She didn't realize that there would be so many contributors to her little project, but it becomes very popular. [19:13] Poor Sarah Jane spends more time reviewing code from merge proposals and merging the code than she does actually coding. [19:14] Sarah Jane will (not might) eventually get burned out playing gatekeeper. She likes to code (and she's better at that anyway). [19:14] Code reviews themselves can't be automated. They NEED a person to look at the code. [19:15] (This is because code is for people, not for computers.) [19:15] However, once the code has been approved by Sarah Jane, she doesn't want to futz with it anymore. [19:16] Sometimes she forgets to run the tests or check that the build is working before committing. [19:16] Side note: We live in a DVCS world. The days of having a broken trunk are over. If your trunk is broken, you are doing it wrong. [19:17] Okay, so Sarah Jane has a list of reviews she needs to do. She goes through, votes on them, and the ones that she approves can be set to "Approved." [19:18] Enter Tarmac, which you can find at http://launchpad.net/tarmac, with the code being found at lp:tarmac. [19:18] Tarmac is a really simple script that will automate merges for you. [19:19] QUESTION: Merges might still introduce a broken trunk, no? [19:19] No. They shouldn't. I will show you why. [19:19] Also, this ClassBot thing seems to be really helpful if you'll preface your questions with QUESTION. [19:20] So Sarah Jane sets up Tarmac to manage all the merges against lp:project. [19:21] When run manually, tarmac can be invoked like this: `tarmac land lp:project` [19:22] If you're going to manage multiple branches, you'll want to configure tarmac to know a bit more about the branches, which you can find out about in the documentation. [19:23] The docs can be found here: http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/head:/docs/introduction.txt [19:24] I have this on a cron job currently, and it runs every 5 minutes. [19:24] Tarmac self hosts itself too. [19:25] In this case, when Sarah Jane runs tarmac, it looks for all the branch merge proposals in a "Approved" status that ALSO have a commit message set, and will merge them all automatically, one by one. [19:25] But wait! What if these merges cause breaks in the trunk? [19:25] Tarmac can be configured to run a command AFTER the merge but before a commit. [19:26] For instance, let's say you want to make sure `make` completes. You can configure Tarmac to run make, and if everything is successful, it'll merge the branch. Otherwise, it'll kick it out and comment on the merge proposal, saying something like "Dude, your branch is broken. Get your act together." === zumbi_ is now known as zumbi [19:27] Tarmac itself has a small suite of tests that we never want to break, so when Tarmac does it's own merges, it makes sure to run the tests. If the tests fail, the branch fails, and doesn't get merged. [19:28] Robots are MUCH better at doing these menial things than we are. We get bored merging and make-ing and testing and all the things you have to do to maintain a pristine trunk. [19:28] There's also something else really awesome about this. [19:29] When I upgrade the Tarmac instance's OS from Lucid to Maverick, the tests underneath broke, so trunk was technically "broken" [19:30] Tarmac worked fine on Maverick, but the tests didn't. This meant that no branches could be merged until the tests were fixed. [19:30] It's kind of a "Stop the line" situation. [19:30] Sarah Jane pointed Tarmac at her branches and then went back to coding and reviewing code. Everything is automated. [19:31] CAVEAT: The system Tarmac uses to merge branches wasn't really meant for what Tarmac does to it. [19:31] Because of this, in the next little while, Launchpad will be gaining a feature called "merge queues." Basically, when you're ready for the branch to be merged, you stick it in the queue. [19:32] Then tarmac just looks at the queue and merges that way. [19:32] This is what I'm currently spending my days working on, so I'm quite excited about the feature. [19:33] Okay, so tarmac is merging branches automatically. [19:33] How does Sarah Jane get her software into the hands of people that use it. [19:33] As a practice now, I personally NEVER do `make install` or `setup.py install` or whatever. If it's not packaged, I'm not installing it. [19:34]