=== asac_ is now known as asac [15:52] Thank you [15:53] hiho [15:53] Nah.. Maybe it's better if random users can't spam here? [15:53] do you mean me? [15:53] hi Bodom [15:53] I mean generally [15:53] The users should use the #ubuntu-classroom-chat, so why do they have to have voice in here? [15:55] Ape3000: no worries, it'll quieten down soon [15:55] Ape3000: for the sake of volantary disciplin [15:55] works astonishingly well ;) [15:55] Ape3000: the channel will be most probably set +m soon [15:55] There is good sides with -m, too [15:56] it worked fine without it yesterday [15:56] and the other developer weeks before :) [15:56] Yeah.. [15:56] We can do: /me applauses [15:56] :) [15:57] OK my friends... who's here for Day 2 of the Week of Awesome? [15:57] Who's excited? :-) [15:57] me :D [15:57] Me :o [15:57] o/ [15:57] ö [15:58] is that everybody? or is the rest of the 172 people in here so shy? :-) [15:58] Welcome everybody to Day 2 of the Ubuntu Developer Week [15:58] intellectronica? [15:58] i'm not shy ;) [15:58] yeah!!!!! [15:58] The schedule is up here https://wiki.ubuntu.com/UbuntuDeveloperWeek [15:58] woo [15:58] date -u [15:59] use it :P [15:59] and we have Tom Berger, Mr intellectronica here who will talk to us about "Launchpad Bug Tracking" [15:59] rock and roll! [15:59] if you have questions, PLEASE ASK [15:59] but PLEASE ask in #ubuntu-classroom-chat [15:59] and prefix your questions with QUESTION: [15:59] ie. QUESTION: Tom, what is your favourite colour? [15:59] ALRIGHT [15:59] hi everone [15:59] have a great Day 2 everybody, hope you enjoy it! [16:00] intellectronica: the stage is yours :-) [16:00] thanks dholbach. hugs aplenty [16:00] :-) [16:00] so, we gathered here today to celebrate an historic event :) [16:00] thanks to everyone who joined despite the obvious competition [16:01] i'd like to introduce you to, and mainly answer your questions about, Malone, the Launchpad bug tracker [16:01] (which I am taking part in developing) [16:01] and which is the bug tracker ubuntu uses [16:02] i haven't prepared much in advance, since i don't know what's the level of familiarity you guys already have with LP [16:02] how does it compare with bugzilla from the administration and setting up side? [16:02] so let's start with a survey (you can answer here). on a scale of 1-10, how familiar are you guys with Malone [16:02] ? [16:02] 0 :( [16:02] 1 [16:02] 0 [16:02] 1 [16:02] 7 [16:03] 1 [16:03] 8 [16:03] 5 i guess [16:03] 1 [16:03] 5 [16:03] 0 [16:03] 1 [16:03] 7.99 [16:03] 8 [16:03] 0 [16:03] 0 [16:03] thekorn: give me a break, you're more like 11 :) [16:03] 0 [16:04] intellectronica: you're 11, we're all lowly -1 :( [16:04] intellectronica, hehe ;) [16:04] slavik: the obvious difference is that Launchpad is a hosted service. there's no set up at all for the users [16:05] unlike bugzilla, which you have to install on a server and administrate, launchpad runs off launchpad.net and the launchpad team takes care to maintain it [16:05] so the only setup procedure you might have, is registering a new project you might want to track. that's quite simple to do [16:06] and for your use of LP as a bug tracker for ubuntu, there's absolutely no setup you need to do. just create an account and start messing with bugs [16:06] intellectronica: I see. Can Launchpad authenticate against LDAP/AD? [16:07] slavik: can you please ask questions in #ubuntu-classroom-chat? [16:07] slavik: Just a note, we've been asked to prefix our questions in #ubuntu-classroom-chat with "QUESTION: Question to person?" there [16:07] slavik: no. launchpad provides its own authentication system, which can also be used as an Open ID provider, and is widely used across the ubuntu landscape [16:08] Ape3000 is asking whether LP is available for private installations. the answer not yet. LP will become free software this summer, at which point you'll be able to install it anywhere (and modify it and help developing it) === hggdh|away is now known as hggdh [16:08] but we very strongly believe that a lot of the value you get from Launchpad comes from it being a central hub in the middle of the free software ecosystem [16:09] the ability to track and and connect bugs from ubuntu, as well as many other projects, using the same site, makes launchpad.net a very powerful tool [16:09] one example of that, which we will look at shortly, is the ability to connect bugs in ubuntu to bugs upstream projects [16:10] slavik asks what tools and languages are used for the development of LP [16:11] LP is written in Python and uses Zope3 as its main web framework, Postgres as a database, Storm (the canonical-developed ORM) as a data layer and lots of other goodies [16:12] you can also access launchpad using a public web service API which uses the REST protocol, from any language. we provide a python library which helps you use that service (more about that later today, when Leonard Richardson will present the API and library right here) [16:13] and yes, Launchpad, obviously, runs on Ubuntu :) [16:13] let's get on with some action! [16:14] https://bugs.launchpad.net/ubuntu is the top level page in LP for ubuntu bugs [16:14] it gives you an overview, and allows you to run simple searches for bugs [16:15] for example, just type some (plausible) text into the text box and hit [Search] to get a bug listing [16:16] for all the following examples i will use staging.launchpad.net [16:17] staging.launchpad.net is a server we keep for testing and experimenting with LP. it has a copy of the launchpad database that is being restored daily [16:17] IMPORTANT: please use the staging for trying out anything that changes the data (like creating new bugs, adding bogus comments, etc) [16:17] that way you'll know that you can experiment freely without polluting LP itself with bad data [16:18] likewise, remember that any changes you make on the staging server will be wiped out. do not use it for real work [16:19] Chris` is asking whether data from staging will be wiped out after posting. the answer is yes - it is being wiped out daily, so you've got anything from a few minutes to whole day to still work with this data [16:20] so, you all see what a bug listing in LP looks like [16:21] you can choose a new sort order and search again [16:21] or, if you need a more complex search, you can click _Advanced search_ [16:21] let's do just that [16:22] i'm looking at https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 [16:23] the status and importance sections are obvious, i think. they will select any _inclusive_ combination of the values you tick [16:24] the people section allows you to select bugs that are related to certain people. for example, you might want to look only at bugs reported by someone, or assigned to someone, and so on [16:25] using the series and component section, you can filter so that only bugs specific to a series or a component within the distribution are selected. this is particularly relevant to you folks working with ubuntu, because as you might have noticed, dealing with all the bugs for ubuntu is pretty much impossible [16:26] the upstream status section is very useful when you try to get bugs found in ubuntu and see how they are connected to the upstream projects where they originated [16:27] this is, i think an especially important concept, so let's try and talk about it a bit more [16:28] many bugs that are found it ubuntu, are actually bugs that originated in some upstream project which is being distributed as part of ubuntu [16:28] reporting it in ubuntu itself is a great first step, but it's usually not enough. we have to make sure that the upstream project knows about it, if we hope to get it fixed one day [16:29] any questions so far? [16:30] Chris` is asking what is edge.launchpad.net and how it differs from staging [16:31] edge is a launchpad server which uses the _real_ data, just like launchpad.net [16:31] it is available to LP beta testers (which you are all very welcome to join - it's fun and gives you an opportunity to help and influence LP development) [16:32] launchpad is released monthly with new features and bug fixes to launchpad.net [16:32] on edge, these changes are released as soon as they are available [16:33] so, you can 'live on the edge' and use a constantly changing version of launchpad - giving you a chance to test (and comment on) the latest features, or you can use launchpad.net and get a very stable version that gets updated once a month [16:34] shankhs is asking whether it is the responsibility of upstream devs to look for bugs in ubuntu that may be related to their project, or the responsibility of ubuntu devs [16:35] the answer is that the relationship is collaborative, and anyone can deal with this, but you must remember that upstream devs have many things to deal with, and many other distributions. we can't expect them to always follow ubuntu [16:35] which is why we try to make it very easy for people to forward bugs upstream [16:36] let's look at https://bugs.staging.launchpad.net/ubuntu/+source/pidgin/+bug/162701 [16:36] Launchpad bug 162701 in pidgin "pidgin freezes while typing a message" [High,Triaged] [16:37] notice anything special about this bug? [16:38] this bug might look like it's affecting two packages, but that isn't really the case [16:38] we can see that it's affected the pidgin package in ubuntu [16:38] but above it, we see that it also affects PulseAudio, which is an upstream project, not part of ubuntu [16:39] this is a good example of how LP can represent the link between ubuntu and upstream projects [16:40] if you click the _Also affectes project_ link, you can mark a bug as affecting other projects [16:40] come on, give it a try (on STAGING) [16:41] if you clicked, you can see that the pidgin package is already associated with the pidgin upstream project. we sometimes know this in advance, which can help you [16:42] it also tells you that pidgin tracks its bug outside of launchpad, using Trac, and gives you the url to the trac server it uses [16:43] if you manage to find a relevant bug in trac, you can paste the url into the first box - launchpad will follow that bug on your behalf and update the status [16:43] launchpad can do this for many bug trackers: Trac, Bugzilla, Sourceforge (and some of its derivatives), Roundup, etc'... [16:44] for Trac and Bugzilla, we provide a plug in which makes the communication with Launchpad especially efficient, and allows the bug trackers to exchange comments too (but it's the responsibility of the upstream project to install that plugin) [16:45] ah, i can see that many of you experimented with creating new tasks for that bug, linking it to other projects, distros and packages. you guys are quick learners! :) [16:46] if you click the status of one of the lines that show the bug reported in an upstream project, you'll see that it's different from normal launchpad bugs [16:47] that's the stuff pertaining to bug watches, the mechanism LP uses for tracking bugs in external bug trackers [16:48] shall we quickly look at reporting a bug? we're rapidly running out of time, so in parallel, please go ahead and ask questions if you have any [16:49] i'm looking at https://bugs.staging.launchpad.net/ubuntu/+filebug [16:49] this is the start of the bug filing process, but it's way too general. it is very rare that you'll want to file a bug about ubuntu as a whole. it's almost always the case that a specific package would be more appropriate [16:51] you can always start from something like https://bugs.staging.launchpad.net/ubuntu/+source/pidgin/+filebug and report the bug directly on the package [16:52] notice how slow the staging server is, b.t.w :) obviously, it doesn't have the same amount of resources as the real launchpad servers [16:53] after i enter a bug description, LP tries to find similar bug descriptions, so that i don't unnecessarily report a bug that's already reported [16:53] if i don't identify the bug in the list of similar bugs, i can click 'No, i'd lke to report a new bug' and the details are shown [16:54] first, we're asked in what package the bug was found. it is really important to try and find out. otherwise, the ubuntu qa and development teams will have a very hard time dealing with it [16:55] you can also look at the instructions at the bottom of the page for what to do and not to do [16:56] you can include an attachment - perhaps some data for helping diagnose the problem [16:57] if you suspect that the bug is a security vulnerability, it's important that you indicate that using the checkbox. the bug will become private until further notice and will be treated more urgently in many cases [16:57] ongolaBoy is asking about the different bug statuses [16:57] New: the bug has just been reported [16:58] Incomplete: more information is needed for people to be able to work on the bug. the reporter, or other people, should add more information in comments [16:58] Invalid: actually, this bug isn't relevant, or is not really a bug. you can ignore it [16:59] Won't Fix: this bug will not be fixed. maybe it's impossible to fix it... [16:59] Confirmed: not used by ubuntu, but in some other projects it means that someone managed to reproduce the bug [17:00] Triaged: the relevant team has looked at the bug and decided what to do with it, what importance to give it, etc [17:00] In Progress: the bug is being worked on [17:00] Fix Commited: the fix is ready and commited to the source tree [17:00] Fix released: the latest version of the software no longer has the bug [17:01] i see that we're running out of time. of course, i managed to cover about 10% of what i wanted to :-/ [17:01] but let's take more questions before i'm being kicked out [17:02] and of course, i hang out in #launchpad all the time, and you are all very welcome to drop by, ask me or any of the other devs questions and enjoy the view [17:03] Ape3000 is asking what my favourite colour. black, at least for today [17:03] shankhs: is asking about patches and fixing bugs [17:04] when you upload an attachment to launchpad, you can mark it as a patch [17:04] it is later easy to search for patches (you may have noticed it in the bug search form) [17:05] if a project uses launchpad for code hosting, you can use bazaar for making fixes, which is really cool. there's a session on that later this week [17:05] oright, i think it's time for ara to start her show [17:06] thanks everyone, and please, do feel free to continue asking questions on #launchpad [17:06] -------------------------------------------- [17:07] next up is Ara Pulido who will talk about QA Tools! [17:07] let's hear a round of applause! :) [17:07] *cheers* [17:07] *applause* [17:07] *applause* [17:07] \o/ ara \o/ [17:07] *applause* [17:08] *applause* [17:08] *applause* [17:08] ok, enough, I am not Madonna [17:08] Thanks all for coming and the warm welcome ;-) [17:09] Questions in #ubuntu-classroom-chat, please [17:09] My name is Ara and I am part of the Ubuntu QA Team (https://wiki.ubuntu.com/QATeam/) [17:09] Do you guys know what are the duties of the QA team? [17:09] Quality Assurance ? [17:10] making sure the devs don't seriously break something for every Ubuntu user with an update [17:11] yes, yes, it is Quality Assurance, and yes we have to try to make sure that devs don't break many things (something always break...) [17:11] But the two most important duties are Triaging (https://wiki.ubuntu.com/BugSquad) and Testing (https://wiki.ubuntu.com/Testing). [17:12] triaging bugs is about making bugs report better, or ask for more information, or provide better information, etc. so the devs can start working on them [17:12] and testing gives a try to Ubuntu before it reaches the wider public [17:13] both the buqsquad team, and the testing team are open to new contributors ;-) [17:13] To perform our daily activities we have a set of tools to make the process easier and automate some of these tasks. [17:14] To be able to try some of the tools that I am going to present, you will need to have installed 'bzr' in your computers. If you don't have it, you can install it easly: [17:15] $ sudo apt-get install bzr [17:15] all set? [17:15] jup [17:15] Let's start grabbing the LP project (https://code.edge.launchpad.net/ubuntu-qa-tools) that contains several QA tools. [17:16] shankhs: complains that bzr doesnt support proxy and aythentication ... :( [17:17] shankhs: I am not a bzr expert, but I am sure there must be some workaround there [17:17] The trunk is the branch that it is better maintained, get the source using bzr: [17:17] $ bzr branch lp:ubuntu-qa-tools [17:18] The first set of scripts that we are going to visit are those that parse the bug mailing list. Those scripts are available in the newly created folder ./ubuntu-qa-tools/bug-mailinglist/ [17:18] all of these scripts are python scripts. be sure to have python on your machines [17:19] The mailing list that receive every bugmail generated in Ubuntu has a copy at http://people.ubuntu.com/~listarchive/ubuntu-bugs/ [17:20] To use the bug-mailinglist scripts you have to grab a copy of one of the available archives and save it locally. [17:20] this files are too big, for testing purposes you can just trim one of them [17:20] The first script, triager-query.py queries the mailing list archive for actions performed by a specific bug triager. [17:21] actions like "add tag", "set as incomplete", "set as triaged", etc [17:21] syntax go as [17:21] python triager-query.py [email] [file] [17:22] example: [17:22] python triager-query.py sinzui.is@verizon.net ../test_bugs_mailing_list.txt [17:22] From sinzui.is@verizon.net: 1 [17:22] sinzui.is@verizon.net triaged: 1 [17:22] this is the output of a trim of the January archive [17:22] why this information is useful? [17:23] As you might know, triagers in Ubuntu are divided in two teams. The bug-squad team is open to anyone, but to enter the bug-control team you have to be an experienced triager [17:23] because bug-control members have access to potentially sensitive data [17:24] If you're part of the bug-control team, one of your duties is to review new membership applications to the team [17:24] count-senders.py parses the mailing list archive and returns the quantity of messages sent by individuals. This includes any activity in the bugs. [17:24] python count-senders.py [email] [file] [17:24] body-searching.py searches the mailing list archive for a user defined string, sys.argv[1], and returns bug numbers containing that string. [17:24] python body-searching.py [string] [file] [17:25] tagged-bugs.py searches the mailing list for tags, and creates a HTML report with the date the tag was added to the bug [17:25] python tagged-bugs.py [tag] [file] [17:25] all this information can be retrieve directly through Launchpad, of course, but if you have to do it daily, it is much easier to use the scripts [17:25] and faster [17:26] not saying that the launchpad web interface is slow... (in case some of the LP is watching... [17:27] ls [17:27] any questions about the bugs-mailinglist scripts? If not I am going to move to a script to help testers [17:28] bullgard4: QUESTION: ':~$ python triager-query.py; python: can't open file 'triager-query.py': [Errno 2] No such file or directory'. What went wrong? [17:29] bullgard4: did you move to the right folder? once you branch you have to move to ubuntu-qa-tools/bugs-mailinglist [17:30] Let's move now to another tool, the dl-ubuntu-test-iso, a script that will help you keeping your testing images ISO up to date. [17:30] have you ever helped with ISO images testing? [17:32] then start now! ;-) https://wiki.ubuntu.com/Testing/ISO/ [17:32] each milestone released (alpha-1, alpha-2, point releases, etc.) need some ISO verification [17:33] to avoid having to download every single iso each time you can have them synced [17:33] dl-ubuntu-test-iso is based on rsync and can be configured to download only the necessary images. [17:34] shankhs: and it is not a python script. it is bash scripting ;-) [17:34] To configure the tool you need to save your configuration file as ~/iso/iso.cfg. You can see an example here: http://people.ubuntu.com/~ara/udw/qatools/iso.cfg [17:35] In the example configuration file we have set to download jaunty release, only for i386 architectures, and alternate, desktop and server. [17:35] Once you have set up the configuration file, and running ./dl-ubuntu-test-iso, the images will start to be download to the ~/iso folder. [17:36] Please, take into account that by default all the images are download, so if you do not have a configuration file, you will download every possible image. [17:37] If you run the script daily (or weekly), you will need to download only the changes between both images [17:37] saving you time [17:37] and bandwidth for your movies and music ;-) [17:38] If you want to start helping with Ubuntu, ISO testing is a great way to start. and really, really helpful [17:38] And now that we are talking about the dl-ubuntu-test-iso script to test ISO images, do you know the ISO tracker? [17:39] The ISO tracker is a web application that we, at the QA team, use to track the testing of the ISO images. It is located at http://iso.qa.ubuntu.com/ and it is updated with the ISO images that we should be focusing in (right now the focus is taking by Hardy's point release). [17:40] It is really helpful to create an account in the ISO tracker (if you have an account in the Brainstorm site, that one would work in the ISO tracker site as well) and submit your testing results. [17:41] On the menu on the left, you can select the flavour that you're testing. Let's select Ubuntu flavour. [17:41] Then you have to click on the ISO image that you're testing. Let's say that we are going to test Alternate i386 (the installer that does not have a Live session) [17:42] When you click in one of the options, a list of testcases will appear, and a link to the ISO image, in case you haven't downloaded yet. [17:42] Nice and easy [17:43] In the list of testcases you can see what it is outstanding and have your pick taking that into account. Click on the chosen testcase to read it and submit your results. [17:43] Any questions about the ISO testing site or ISO testing in general? (before I move back to bug triaging) [17:44] bullgard4: QUESTION: What is 'Hardy's point release'? [17:45] bullgard4: Hardy (Ubuntu 8.04) is a LTS release (Long Term Support) [17:46] bullgard4: we realease "point release" 8.04, 8.04.1, 8.04.2... that contain the latests updates already in the ISO images [17:47] let's move to some useful reports that will make triagers life easier. When triaging bugs is useful to have access to some important information through the reports. Here's a list of some of them: [17:47] Yesterday bugs: http://qa.ubuntu.com/reports/bugnumbers/yesterday.html [17:47] Bugs reported yesterday. Useful to Invalid, Mark as Duplicate or request more information. [17:48] With more duplicated bugs: http://qa.ubuntu.com/reports/launchpad-database/bugs-with-most-duplicates.html [17:48] this is really useful when you're reading a bug that you "feel" "sure, this has been reported before" === tate_ is now known as teskew [17:50] 25 oldest bug task that are : [17:50] new: http://qa.ubuntu.com/reports/launchpad-database/oldest-new-ubuntu-bug-tasks.html [17:50] Incomplete http://qa.ubuntu.com/reports/launchpad-database/oldest-incomplete-ubuntu-bug-tasks.html [17:50] Confirmed http://qa.ubuntu.com/reports/launchpad-database/oldest-confirmed-ubuntu-bug-tasks.html [17:50] Triaged http://qa.ubuntu.com/reports/launchpad-database/oldest-triaged-ubuntu-bug-tasks.html [17:50] Progress http://qa.ubuntu.com/reports/launchpad-database/oldest-in-progress-ubuntu-bug-tasks.html [17:50] Fix Committed http://qa.ubuntu.com/reports/launchpad-database/oldest-fix-committed-ubuntu-bug-tasks.html [17:51] Helpful if you want to clean Launchpad from obsolete bugs [17:51] The newest addition to the list, just announced a week ago, is the team assigned reports. As you might know, Canonical gives support to the packages in main, therefore, it is useful to have a list of the tasks assigned to one of this teams. The format of the URL of these reports is [17:51] http://qa.ubuntu.com/reports/team-assigned/canonical--assigned-bug-tasks.html [17:52] i.e. for the mobile team: [17:52] http://qa.ubuntu.com/reports/team-assigned/canonical-mobile-assigned-bug-tasks.html [17:52] A list of them can be found at http://qa.ubuntu.com/reports/team-assigned/ [17:52] http://qa.ubuntu.com/reports/team-assigned/ [17:53] These reports can be useful, in case a triager sees that an already assigned bug with high importance hasn't been touched in a while, he or she could ping the correct person directly, to try to push the resolution. [17:54] triaging bugs involves a lot of talking through the IRC. If you like IRC, you will love triaging bugs! [17:54] I am running out of time, I would like to move to testing again before I finish [17:54] any questions on the triaging side? [17:55] ok, let's move back to testing [17:55] we will talk a bit about SRU testing. Does anyone know what SRU stands for? [17:55] stable release update [17:56] SRU stands for Stable Release Updates. This is, those updates that are found in the Update Manager when we are running a stable release of Ubuntu. [17:56] davmor2: you're a great student! ;-) [17:57] Briefly, the process goes as: [17:57] * An important bug, that needs to be fixed through updates, is found in a stable release. [17:57] * A fixed is written and apply to the package. The package gets updated in the -proposed archive. [17:57] * A tester willing to help with the SRU process (and has the -proposed repositories enabled; https://wiki.ubuntu.com/Testing/EnableProposed) installs the package and verifies that the bug has been fixed. [17:57] * The fix is apply to the -updates repository. [17:57] For more information about the SRU process you can go to https://wiki.ubuntu.com/StableReleaseUpdates [17:57] To help tracking the outstanding bugs to test and help people coordinate the efforts, we have a very helpful tool, the SRU tracker: [17:58] http://people.ubuntu.com/~sbeattie/sru_todo.html [17:58] In this tracker you can easily spot what fixes need verification (and for which release) and a test case if available. [17:58] If you're running a stable release of Ubuntu (hardy, intrepid...) this is a great way to help the QA team to make Ubuntu better. [17:59] any questions before leonardr starts the following session? [18:00] counting down: [18:00] 5... [18:00] 4... [18:00] 3... [18:00] 2... [18:00] 1... [18:00] Thanks ara, That was GREAT! [18:00] Ok, that's it for today! I will be running another session on Thursday, to explain how to use Ubuntu Desktop Testing to create automated tests for the desktop. [18:00] thanks ara [18:01] cheers! [18:01] Thanks all for coming!! [18:01] Thank you, ara. [18:01] thank you ara === heikki_ is now known as heikki [18:02] ok, i'll get started now [18:02] Hi all. [18:02] My name is Leonard Richardson. I'm on the Launchpad Foundations team and I'm the co-author of the O'Reilly book "RESTful Web Services". [18:03] I'm here to talk about the Launchpad web service API--how to use it and what advances have been made since the last UDW. [18:03] I'll do an infodump and then take your questions. [18:03] If you have questions in the meantime just put them in #ubuntu-classroom-chat. [18:03] Most of this infodump will be familiar to those of you who were at this chat at the last UDW. I ask you to bear with me so I can get everyone up to speed. [18:03] [18:03] 1. Intro [18:03] First thing to know is that we've got docs talking about the API here: https://help.launchpad.net/API [18:03] Put simply, we've created an easy way for you to integrate Launchpad into your own applications. [18:03] If you perform the same tasks on Launchpad over and over again, you can now write a script that automates the tasks for you. [18:04] You don't have to rely on fragile screen-scraping. [18:04] If you're a developer of an IDE, testing framework, or some other program that has something to do with software development, you can integrate Launchpad into the program to streamline the development processes. [18:04] If you run a website for a project hosted on Launchpad, you can get project data from Launchpad and publish it on your website. [18:04] And so on. You'll eventually be able to use the API to do most of the things you can do through the Launchpad web site. [18:04] [18:04] 2. Tools [18:04] The simplest way to integrate is to use launchpadlib, a Python library we've written. [18:04] (see https://help.launchpad.net/API/launchpadlib) [18:04] This gives you a Pythonic interface to the Launchpad API, so you don't have to know anything about HTTP client programming: [18:05] >>> launchpad.me.name [18:05] u'leonardr' [18:05] >>> launchpad.bugs[1].title [18:05] u'Microsoft has a majority market share' [18:05] But it's also easy to learn the API's HTTP-based protocol and write your own client in some other language. [18:05] (see https://help.launchpad.net/API/Hacking) [18:05] [18:05] 3. Progress and Roadmap [18:05] At the last UDW I said that the web service publishes information about people, bugs, and the Launchpad registry, (the projects, milestones, etc.). [18:05] Since then, the bugs work has been more or less completed. CVEs have also been published through the web service. [18:05] Code branches have come online. [18:06] Merge proposals have been published but are currently read-only. They should be read-write within a week. [18:06] Additional bits of the registry, like milestones, have been published since the last UDW. [18:06] Some of the Soyuz functionality has come online: archives and archive permissions. [18:06] The hardware database will be the next thing to be published, hopefully within a month. [18:06] Publication through the web service is still not a priority for translations, answers, and blueprints. [18:06] so, that's the infodump, i invite your questions [18:07] QUESTION: do you plan write API for Rosetta? [18:08] so, the team that does some part of launchpad, like rosetta, is also responsible for publishing that part of launchpad through the web service [18:08] i talked to the translations team today and they don't have plans to publish translations through the web service, per se [18:09] however, we will also be using the web service to add ajax functionality to the launchpad website [18:09] and they will be publishing some of the translations functionality for that, so you will get at least some of the translations [18:09] but there's no plan right now to publish the whole things as there was for bugs--what they publish might be useful to you, it might not [18:10] QUESTION: What is a " Pythonic interface "? [18:10] a pythonic interface is one that "looks like python". it presents objects that act like built-in python data structures, as opposed to (eg.) one with a lot of getters and setters [18:11] Question: can you please explain (in short) the different access-level? [18:11] and especially: why is there a "no access level" [18:11] is there a no access level? let me check [18:11] i'm opening up the list of access levels [18:12] all right [18:12] so, we've set up authorization to the launchpad web service using the oauth standard [18:12] which is basically a way for the end-user to delegate a certain amount of authority to a program [18:13] the problem is that although you trust your web browser enough to type in your launchpad password [18:13] you probably don't extend that same level of trust to other programs, like IDEs or "portal" websites that promise to show you a dashboard of your launchpad activity [18:14] you shouldn't trust those sites with your launchpad password [18:14] oauth is a way to delegate a certain amount of power to those sites, without giving them your password [18:14] in that context, the access levels are the different amounts you can trust a particular site or application [18:14] if a site promises to make a dashboard for you, then you can give the site read-only access to your data [18:15] it has no business modifying your data [18:15] similarly, you can authorize an application to only access public data on your behalf [18:15] as for the 'no access' level, flacoste said in classroom-chat: [18:15] thekorn: say a rogue application try to ask for a token, the user can click on no access level to dismiss the request [18:15] it's a 'cancel' button [18:16] hopefully that provides at least some enlightenment [18:16] QUESTION: Will it become possible to use launchpadlib without needing to login, if all you want is read-only programmatic access to public data? [18:16] our initial decision was to prohibit this altogether. we're now reconsidering but we haven't made a decision one way or the other yet [18:17] QUESTION: could you just name, please, a few apps, which uses LP API? [18:17] i think thekorn could name more than i can [18:17] i'm also bad with names [18:17] there are some tools switching from screenscraping to lplib, [18:17] the is a bzr plugin for eclipse [18:18] like ubuntu-dev-tools [18:19] also, for every publicly available tool there are several private scripts [18:19] people write everyday scripts to get around whatever annoys them about launchpad or to do batch operations [18:19] QUESTION: Rationale for prohibiting launchpadlib access to data which can be screen-scraped without auth would be interesting? [18:20] there's a general worry about access to the web service getting out of control [18:21] we have various ways to throttle usage for different scenarios, and one of the scenarios is when one person is using too many resources, whether by accident, due to a bug, or maliciously [18:21]