=== IsoLnCHiP is now known as IsoLinCHiP === DonKult_ is now known as DonKult [02:54] I went through logs due to my absence from yesterday's and today's Ubu Dev Week discussions/tutorials. I took notes and important stuff and it would be a lot quicker to read my notes than go through the logs yourself. If you are interested in Ubuntu/Debian bug fixing/code management, etc, let me know and I'll post the notes on Pastebin for you :) [02:55] Setup (tools and such), upstream, common commands, basic process of getting things patched, etc is what I have for you... [03:41] Took notes on "Ubuntu Developer Week 8/28/12 - 8/29/12 : Getting started" (went through the logs, took notes on it).If you would like to see the notes, go to the following link : http://pastebin.com/J1Za9cNW === smartboyhw is now known as Guest59018 === smartboyhw_ is now known as smartboyhw === matt_ is now known as Guest99005 [10:45] ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS === yofel_ is now known as yofel === Pendulum_ is now known as Pendulum === smile is now known as Guest79925 === Guest79925 is now known as smile4 === keffie_jayx is now known as effiejayx === smile4 is now known as smile === jussi01 is now known as jussi [14:56] Hello everybody, welcome to the last day of Ubuntu Developer Week! [14:56] Here are just a few organisational bits and pieces before David Planella takes over: [14:56] #ubuntu-classroom is used just for the sessions themselves, but you can use #ubuntu-classroom-chat to discuss everything and ask all your questions. [14:56] If you do ask questions, please make sure you prefix them with QUESTION: [14:58] ie: QUESTION: Is it true some of your teammates can discuss Metallica albums for hours? [14:58] Also: all logs will be available at https://wiki.ubuntu.com/UbuntuDeveloperWeek - currently you can see all the logs from yesterday and the day before. [14:58] If you would like to stop notices about people joining and parting coming in, please review https://wiki.ubuntu.com/UbuntuDeveloperWeek/JoiningIn [14:58] To stay up to date with initiatives like this one, consider following @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to [14:58] You still have 3 minutes to grab a tea, coffee or glass of water before dpm gets cracking :) [14:58] Enjoy! [14:59] dholbach, running to the kitchen! === smile is now known as smile-lekkereten === 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 Developer Week - Current Session: Getting started with app development - Instructors: dpm [15:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html following the conclusion of the session. [15:01] Hello everyone! [15:01] welcome to the first session of Ubuntu Developer Week Day 3! [15:02] it's a short session today, so let's just go for it :) [15:02] My name is David Planella and I work in the Community Team at Canonical, today with my Ubuntu App Developers Liaison hat on [15:03] This is a bit of a different session than most of the topics this week. [15:03] I want to tell you about building upon the Ubuntu platform and create apps that run on it, [15:03] rather than developing and maintaining the platform itself. [15:03] To put it simple, the subject of this session will be how to get started [15:03] with the process of creating apps that run on Ubuntu, rather than how to developing the Ubuntu platform itself [15:04] Both are equally fun, so feel free to pick your poison ;) [15:04] Therefore, during the next half hour I'll be talking about how to submit your apps to Ubuntu, so [15:04] that they get published in the Software Centre, to be distributed to millions of [15:04] users that will surely enjoy your cool software :) [15:05] But it will not be just a talk: I'd like everyone to participate and ask their questions at the end. [15:05] However, feel free to interrrupt me during the rest of the session too, if you've got any questions. [15:05] Just remember to prepend them with QUESTION: on the #ubuntu-classroom-chat channel [15:05] Throughout the talk I will be referring to different places in the Ubuntu App Developer site, [15:05] which is the central place for anyone wanting to create and publish their apps in Ubuntu. [15:05] Here's where it lives: [15:05] http://developer.ubuntu.com [15:06] So let's get cracking [15:06] [15:06] Creating your app [15:06] ================= [15:06] Well, the first step is obvious, you have to create your app, which is basically [15:06] the time when you materialise that cool idea into beautiful software. [15:06] I will not dwell too much on this subject, as it's beyond the scope of the session, [15:06] However, I'll just add a couple of tips for app authors. [15:07] If you're considering writing a new application for Ubuntu, I'd recommend to use [15:07] the standard set of tools available from the Ubuntu archive. [15:07] They are an extremely powerful and versatile bunch of tools that will not only put everything you need to write software at your fingertips, [15:07] but also will help you following good development practices. [15:07] And they're all Free Software and also free as in free beer! [15:07] You've got an overview of them here: [15:07] http://developer.ubuntu.com/get-started/quickly-workflow/ [15:08] What we've also got is a tool called Quickly, which puts all those technologies together [15:08] If you want to know more about it, mterry did a nice session during this UDW [15:08] so remember to check out the logs [15:09] You can learn more about it here too, it's got a nice and short video tutorial to show [15:09] you how to write a basic functional template for your app in a matter of minutes: [15:09] http://developer.ubuntu.com/get-started/ [15:09] === Jesus is now known as Guest36959 [15:09] Which types of apps qualify [15:09] =========================== [15:09] There are thousands of apps available in the Ubuntu archive already, which usually get in there through other means. [15:09] Many of these fall into the category of system software, or big applications that are part of the Ubuntu platform. [15:10] They are also subject to strict policies to ensure the security and quality of the software, [15:10] as well as to ensure that they are indeed Free Software and can be distributed with Ubuntu. [15:10] So in order to differentiate from these archive applications, I'll call the process we'll be talking about today, "the app developer process". [15:10] Ultimately though, they are all published through the Software Centre [15:10] So to answer the first question, these are the 3 broad categories in which apps to be submitted through the app developer process fall: [15:11] * Paid for apps [15:11] * Gratis apps with proprietary licenses [15:11] * Gratis apps with Open Source licenses [15:11] Notice that as well as open source, we're also embracing commercial applications to give the opportunity to app authors and Canonical to make revenue of application sales. [15:11] [15:11] 1. Submitting your app [15:11] ====================== [15:12] Ok, so all that cleared up, by this point you've already have a working app you'd like the world to see and enjoy. [15:12] The good news is that we've got an easy, streamlined and web-based process to make it easy for you to to publish, keep track of, monitor and update your apps. [15:12] For this, we've developed a tool especially for app developers. [15:12] It's called My Apps and you'll find it on the app developer site: [15:12] https://myapps.developer.ubuntu.com [15:13] You'll see that it's easy and intuitive to use, and the first thing you'll want to do is to sign up for it to enter the Ubuntu app developer programme and start using it straight away. [15:13] Signing up it's free, and again, it's a matter of a couple of minutes. The process is based on Ubuntu's single login, so if you've got an Ubuntu SSO account already, it will be even quicker :) [15:13] Also, before you continue the process of submitting the app, you might want to read the quickstart guide on: [15:14] http://developer.ubuntu.com/publish/ [15:14] It will show you the basic steps you will be following and give you some useful tips along the way. [15:14] Let's go quickly through them: [15:14] 1 - Set up your My Apps account - you've already done that :) [15:14] 2 - Prepare your app's icons and screenshots - you will want your app to be appealing to users, so make sure you've got nice screenshots and icons, in all recommended sizes [15:15] 3 - Add your application details - here you'll be describing your app and making it easily discoverable in the Software Centre. Make sure the description is clear and use a spell-checker to avoid typos [15:15] 4 - Choose your price - if your app is paid for, you'll have to decide the price in USD at this point. The minimum price is $2.99 [15:15] (actually, I'd need to check if that has changed recently) [15:16] 5 - Have a source package or a PPA for your application ready to upload - here's where you upload your actual app to MyApps. [15:16] If you use Quickly, it will do that for you [15:16] so that you don't have to worry about packaging [15:16] 6 - Your app will be reviewed - before it gets into the wild, your app needs to be reviewed and QAd. [15:17] nja asked: Why is the minimum price $2.99? [15:17] I believe that is (or was) a requirement from the bank that is used to do the money transfers [15:18] so there isn't much room for play here [15:18] but do check on MyApps and the FAQ. They should be up to date [15:18] commandoline asked: Is there any chance that open source apps developed this way can also get into debian? [15:19] They are all open source apps and they are publicly available in the extras.ubuntu.com archive, so I can't see no reason why someone can port them to Debian, most probably with minimal or no packaging changes [15:20] ok, let's continue [15:20] There are 10 minutes remaining in the current session. [15:21] moez asked: i want to develop an app well integred to gnome-shell, unity and even kde. Quickly can't do it for me. is there any tool can make it easier? [15:22] Quickly is focused on Ubuntu, but ultimately, it creates a Python app. You can use Quickly to create your app and then modify it to integrate into all of those shells [15:22] jsjgruber-l85-p asked: Are there plans for apps to declare what permissions they will need so the consumer can make a choice to trust an app developer or not (like Android's store)? [15:22] that's an excellent question [15:23] we have actually been discussing this over the course of the last few weeks [15:23] but such a feature is dependant essentially on sandboxing working well for all use cases [15:24] we've been discussing a plan for it, but it will span multiple releases to complete [15:24] stay tuned very soon for an announcement on the ubuntu-devel mailing list, and on the Ubuntu app development channels [15:24] moez asked: i'm using lauchpad for my app, and i want to ask help for design as asking help for translate. how? [15:25] There are 5 minutes remaining in the current session. [15:25] for design, I'd recommend heading to design.ubuntu.com. For translations, I'd recommend sending an e-mail to launchpad-translators(AT)lists(DOT)launchpad(DOT)net [15:40] They are stripped during the build on the Launchpad buildds and put into the language-pack-* packages instead. [15:40] There is a set of language packs per language [15:40] They are divided roughly between generic translations and those which are used in a GNOME-based desktop and those used in a KDE-based desktop [15:41] Although this cycle, with KDE being in universe [15:41] we won't have KDE translations in language packs [15:41] We essentially make use of language packs to deliver translations independently from applications and thus we're able to ship regular translation updates throughout a distro [15:42] lifecycle [15:42] [15:42] Translations Import Workflow [15:42] ---------------------------- [15:42] On a 1000 feet view, what happens when you do a package upload is that their translations get stripped by a tool called pkgbinarymangler, and they are put in a translations tarball containing a translations template (more on this later on) and the translations themselves. [15:42] TheLordOfTime asked: if KDE translations arent included in language packs, how would KDE users get their localization/translation packs? [15:42] Ah, good question, but don't worry [15:43] They will still be shipped, simply not in language packs [15:44] what we do in language packs is to extract translations from the original packages, combine them with those from launchpad, and ship them separately in the actual language pack packages [15:44] in the case of KDE, translations will simply not be extracted and shipped in the original packages [15:44] so all is good :) [15:44] chilicuil asked: so, may I have translations from programs I've not installed? [15:44] Another good question [15:44] Yeah, that's actually the case [15:45] We put translations for all translatable software from main, restricted, universe in the langpacks, and you'll get them even if you haven't installed the software [15:46] but this just amounts to a bit of extra space, which 99% of users won't even notice or need to worry about [15:46] so where were we? [15:47] Oh, translations being extracted from packages... [15:47] ok, so here's what happens next [15:47] This tarball with extracted translations is then fed to Soyuz (an internal Launchpad component), which ends up handing it to the translations imports queue. There, they will be eventually processed, approved and imported into Launchpad, at which point they will be exposed in the translations web interface ready for translators to do their job. [15:47] If you are interested in seeing what the imports queue looks like, you can see the translation uploads currently pending review here: [15:47] https://translations.launchpad.net/ubuntu/quantal/+imports?field.filter_extension=pot&field.filter_status=NEEDS_REVIEW&start=75&batch=75 [15:48] That's the global imports queue, but you can see it per package as well [15:48] https://translations.launchpad.net/ubuntu/quantal/+source/unity/+imports [15:48] So now we come to the nitty gritty details... :) [15:49] [15:49] Package Modifications for a better Ubuntu integration [15:49] ----------------------------------------------------- [15:49] In order for translations to be imported to Launchpad and in order to direct translators to the translations page to start contributing straight away, [15:49] we make two main changes to the application at the packaging level: [15:49] * Creation of a POT file on build - We require the .deb package to produce a .pot translation template during the build, which will be imported into Launchpad and be used to expose translations for translators to do their work. [15:49] Actually, I think we can leave it to one change :) [15:49] For those not familiar with the concept of a POT template: [15:49] It's a textual file with the .pot extension [15:50] and it's what Launchpad use as the source for exposing translations [15:50] all translations in all languages will be based on that template, which contains the translatable messages in English [15:50] It's generally built by gettext-based tools [15:50] which extract translatable messages from the code in an application [15:50] and put them in the textual .pot file [15:50] There are 10 minutes remaining in the current session. [15:51] Actually, seeing that there are only 10 mins left, I think I'll wrap it up here and point you to: [15:51] https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging [15:52] There you'll find the information I've been talking on in this session, and more [15:52] As per contributing with translations, the best place to get started is on: [15:52] https://wiki.ubuntu.com/Translation [15:53] Ok, time for some questions, bring them on! :-) [15:54] JoseeAntonioR asked: How can I start a translation team for a language that hasn't been set up yet? [15:54] Aha, nice question! [15:55] You'll find detailed, step-by-step information on how to do that here: https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam [15:55] There are 5 minutes remaining in the current session. [15:57] ok, any other questions, or anything you've always wanted to know about translations and were afraid to ask? [15:57] ...3... [15:58] marcosb asked: shell scripts [15:58] marcosb asked: translation on shell scripts [15:58] ok, let me rephrase that... any _easy_ questions? ;-) [15:59] just joking, but translation of shell scripts is a bit hard to get right [15:59] and not always works fully [15:59] I'd recommend reading the gettext documentation for that, which contains a couple of good examples [16:00] my recommendation is that if you want to make a script translatable, just use Python [16:00] which fully supports gettext [16:00] ok, so time's up! [16:00] Thanks everyone for listening in and I hope you enjoyed the session! === 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 Developer Week - Current Session: Adding test cases with UTAH - Instructors: gema [16:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html following the conclusion of the session. [16:01] Hello everyone! [16:01] I am Gema Gomez-Solano and I work in the Platform QA Team in Canonical [16:02] and I am going to talk about UTAH, or the Ubuntu Test Automation Harness, [16:02] it is a testing tool we are creating because we were lacking coherence in our testing [16:02] we’d like to share it with other groups in case anyone is having the same kind of problems [16:03] UTAH is a tool that is meant to help with end to end test automation. [16:03] you can find the project in launchpad: https://launchpad.net/utah [16:03] ok, so let's get started with what UTAH does [16:04] it takes care of provisioning a machine from any iso or existing provisioned machine, installs either a VM or a physical machine with it and then it runs the tests and report the results back [16:04] before this project we were doing a lot of development work that was tailored to solve a particular problem, we had to do installs for ISO testing, for Kernel SRU testing, for upgrades... [16:05] we are interested in using hardware as well as VMs, 32 and 64 bits, ARM [16:05] so we had many scripts to solve all these problems separately, furthermore, this was happening not only in the QA Team, but also in the development teams. [16:06] there was a lot of redundant code being created everywhere [16:06] the creation of this code was getting on the way of the real development of automated tests, because at the end of the day, how you provision a machine may or may not be relevant to your testing [16:07] so we thought of this project to unify all the scattered work we were doing [16:07] the test cases can be written in any programming language and then be wrapped with UTAH to be able to run them in an fully automated fashion === var is now known as Guest76298 [16:07] you can also choose to schedule things with jenkins, which is the scheduler of choice of the QA Team, or you can choose to schedule runs with cron or just kick off a run manually whenever you need it [16:07] we are expecting UTAH to help also reproducing bugs, [16:08] whenever we find a bug with automated testing, we should be able to give a preseed and a runlist to the developer and he should be able to reproduce the problem at home, [16:08] without having to worry too much about installing a system [16:08] so we are trying to make testing repeatable [16:08] I will describe a bit how the testing is meant to be structured in UTAH [16:09] Testing structure [16:09] Test cases are the smallest execution unit in UTAH, we prefer them to be in separate files, so that we can choose to execute a particular binary, but if your binary takes parameters and executes different test cases based on the parameter, that works also well. [16:10] Test cases can have set up and tear down, so that you have control over your test environment [16:10] Test cases also need to leave the system in the same state they found it, this is good practice and avoids problems down the line. [16:11] So do not make test cases dependant on each other so that they have to run in any specific order! [16:11] Test cases can be grouped in test suites. === carlos is now known as Guest27302 [16:11] Test suites are group of test cases that target a particular piece of functionality and that makes sense to *maintain together* [16:12] i.e. the code is going to be maintained by a particular developer who is the expert on that part [16:13] for instance, file system testing may make a nice test suite, and then we could choose to [16:13] execute only some of those for smoke testing and all of them if we wanted full regression testing [16:13] We are going to use test suites to group test cases that are functionally similar, or that are targetting a particular piece of functionality [16:14] We also have runlists, which is a list of test cases and/or test suites that are run together [16:14] For instance, for smoke testing, which is the daily testing we do every day to validate Ubuntu images, we will have a runlist. [16:14] We may need more than one smoke testing runlist if we decide to run different test cases on different images for any reason, or on different architectures. [16:15] runlists are groups of tests that makes sense to *run together*. [16:15] runlists may be different for quantal and precise, for instance. We may want to run different test cases in one case and the other, and runlists help us achieve that [16:15] do you guys have any questions/comments? [16:16] ok, you can interrupt me any time, I will continue with what UTAH provides to the tester [16:17] So we've spoken already about provisioning, and how UTAH can do that for you [16:17] Test cases can be written in any language, as long as they are binaries that report success or error in a traditional way. [16:17] UTAH captures and reports stderr and stdout, so any output really will do, as long as you are able to parse it afterwards [16:18] UTAH can handle reboots, so if for instance a test case needs to reboot in the middle of the execution, UTAH will reboot the machine and continue executing from then onwards [16:18] Test cases have timeouts, test suites have timeouts and you can even define a timeout for the overall execution [16:18] this is particularly important in full automation, because you don’t want your servers to be stuck on neverending jobs whenever something goes bad with the testing [16:19] Runlists can cherrypick test cases from test suites, and they can either include test cases or exclude some [16:19] we have added the options to help with maintainability of runlists [16:20] What is the status of the development [16:20] We are using UTAH already for bootspeed testing [16:20] so any bootspeed testing results you see from now on, come from tests executed with the harness [16:20] There are 10 minutes remaining in the current session. [16:20] we are slowly migrating also ISO testing, so that our smoke testing runs with the tool and we can concentrate on adding more coverage easily [16:21] before the scripts were not so flexible and we need to maintain several copies of the same test cases for different configurations, which is not ideal [16:21] we are trying to avoid that going forward [16:22] the most difficult part of migrating from our current system, is to decide how to structure the test cases in the new world so that they grow in the right direction [16:22] we are also working on provisioning ARM, so that we can finally run ARM tests fully automated in the lab [16:22] this will be coming soon [16:23] any questions anyone? [16:24] TheLordOfTime asked: How does one get UTAH so we can use it? [16:24] good question, TheLordOfTime ! [16:25] the documentation on how to install and get utah is available online [16:25] http://utah.readthedocs.org/en/latest/index.html [16:25] and you can also join our mailing list [16:25] https://lists.canonical.com/mailman/listinfo/ubuntu-utah-devel [16:25] in case you run into problems [16:25] There are 5 minutes remaining in the current session. [16:25] it is early days and we are getting it ready for everyone now [16:26] there doesn't seem to be any more questions [16:28] jsjgruber-l85-p asked: Is it possible to have Utah test GUI applications? [16:28] good question, right now that is not posible, but we are working on enabling it [16:28] the reason it is not possible is because utah connects to the host to run the tests via ssh [16:29] and we haven't decided how to start the x session and test from there [16:29] if you have suggestions join the list and share them [16:30] we are about to finish this session, but I am still here for the coming 30 mins === 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 Developer Week - Current Session: Q&A about test automation - Instructors: gema [16:30] ok, so I wanted to have time to talk about testing and automation in a more generic way [16:30] Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html following the conclusion of the session. [16:31] not just utah, but discuss options that people have when considering automating testing for their applications/packages [16:31] do you guys have any question that needs addressing? [16:32] or want to know anything about how we are running all the automated tests you see in jenkins? [16:34] marcosb asked: say frameworks for automatized test for Linux. [16:35] ok, marcosb, let's see [16:35] I have already spoken about UTAH [16:35] we have also in the ubuntu world autopilot [16:36] you can use Xpresser [16:36] you can even use checkbox for some existing test cases and certification [16:37] marcosb: do you have any particular need to address so that I can give you a better answer? [16:38] please, feel free to ask questions in this channel directly [16:38] since this is more of a round table kind of session [16:38] it makes sense [16:38] no need to prefix with QUESTION: [16:39] sure gema, is nicolas skeggs part of your team?, or we have several testing teams here? [16:39] chilicuil: nicholas skaggs is the QA Community coordinator [16:39] so basically my team work focussed on automation and we also do manual testing during milestones [16:40] which is what nicholas is coordinating [16:40] so we work directly with nicholas in things that are open initiatives [16:40] and just work in canonical creating test cases that nicholas and you guys can use to drive your testing later [16:40] we do both things [16:40] nick is not in our team but we talk on daily basis and collaborate [16:41] marcosb asked: No just interested about possibilites :) [16:42] marcosb: ack [16:42] chilicuil: do you collaborate on the ubuntu QA team? [16:42] gema: not yet [16:43] chilicuil: we'll be happy to have you onboard whenever you want :) [16:43] I was just wondering why I've heart about UTAH in the mails nicolas send almost every day =) [16:43] I've not* [16:43] chilicuil: because utah is in the process of being created, we are not fully in production yet [16:43] so nicholas cannot still use our runlists [16:44] but believe me he is asking me on regular basis :) [16:44] that answer my question, I hope to join u soon [16:44] excellent [16:44] any other questions / concerns? [16:46] well, we have still some minutes to go, so let me know if you guys have anything [16:46] i was wondering what timezone the schedule for classes is in, i looked at the link provided here. [16:47] for future reference [16:47] wan26: the schedule is in UTC i think [16:47] (GMT +- 0) [16:47] yes, that confused me too [16:47] "Events shown in time zone: GMT (no daylight saving)" [16:47] Thank you :) [16:49] so if you guys want to have a look at results of our automated testing, feel free to look at jenkins [16:50] https://jenkins.qa.ubuntu.com/ [16:50] we are working on a different view for results, but for now jenkins does the job [16:50] There are 10 minutes remaining in the current session. [16:51] and if you want to collaborate with QA for Ubuntu, you can start on the wiki of the QA Team [16:51] https://wiki.ubuntu.com/QATeam/ [16:52] so if you guys do not have any more questions on QA, make sure you stay tuned for the next session, which is about WebApps [16:52] in under 10 minutes [16:53] thanks a lot gema, I feel me a little bit lost with jenkins so I think I'll check it out before joining the team [16:53] we'll also be having a Developers Roundtable, where you'll be able to ask questions, share your experiences, and bring ideas about development :) [16:54] chilicuil: no worries about jenkins [16:54] chilicuil: to be able to help you only need to know how to install ubuntu and have some machine or VM to do it [16:54] jenkins is automated testing, it is what my team and others in Canonical do [16:54] but people from the community can also help by testing images [16:54] during milestones [16:55] http://iso.qa.ubuntu.com/ [16:55] have a look here ^ [16:55] no need to understand jenkins for that :) [16:55] There are 5 minutes remaining in the current session. [16:56] I'll do gema, I just though I need to make sense of the results jenkins gave [16:56] and if you wanted to know, say.. how quantal's image today is doing, you'd go here: [16:56] https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ [16:56] and you see what image is being tested in the description [16:56] and if it is sort of good or not [16:56] it is just an indication that it is worth installing [16:56] and doing further testing [16:56] on it [16:56] Is this to gather as much data as possible for compatibility? Looks interesting [16:57] wan26: we are not doing compatibility testing yet [16:57] we still have to cover the basis of functional! [16:57] got it, so if I see an image with lots of failures is it good to test?, in order to file bugs for example? [16:57] chilicuil: the other way around [16:57] when the automated testing is all red [16:57] aha I see [16:57] it is not worth for you to try [16:57] because it will probably not work [16:57] you are welcome to, but you may encounter problems [16:58] when things are green in the automated world [16:58] then it is worth for people with brains to try and install [16:58] because that finds problems [16:58] I'll stick with the iso.qa.ubuntu.com pagen then =) [16:58] that the robot cannot find [16:58] chilicuil: good choice :) [16:58] we are wrapping up this session guys, we are in #ubuntu-testing if you want to continue this conversation [16:59] or ask anything in the future [16:59] a pleasure talking to you! [16:59] have a nice day gema, thanks for sharing UTAH with us [17:00] thanks [17:00] thank you for listening :) === 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 Developer Week - Current Session: Getting started with Ubuntu WebApps - Instructors: lamalex, alex-abreu [17:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html following the conclusion of the session. [17:03] Hi All [17:03] hello everybody [17:03] welcome this this session about Unity Web Apps technology [17:04] we're both on Canonical's webapps team, working on- well webapps [17:05] Canonical introduced webapps for a few reasons. We want to help close the gab between desktop and web development [17:05] the distinction is kind of arbitrary and the only barrier is technological [17:06] we're not the first to try and do this, but we think there is some novelty in our solution [17:06] previously its been tried to bring html5 development to native apps, i think rick spencer wrote up a demo of this a few months ago. that's cool and all, but it leaves a lot to be desired [17:07] we're trying to allow the web to integrate itself into the desktop via a javascript api that site authors can use to make their web application feel at home on a desktop, not like webapp but integrate into the shell just like a native application [17:08] From the javascript API exposed to integration scripts (we will talk about what it is later) we offer multiple desktop integration points [17:10] from this, the script has access to functionnalities from the messaging menu, the sound menu, the launcher (new icon, quicklists and counts), [17:10] the dash (dynamically added actions), drag and drop (each integration scripts declares a set of mime-types that it supports) [17:10] and the alt-tab switcher [17:11] we plan to add more in the future (not necessarly in terms of API changes but better desktop integration to get closer to native feel) [17:12] the integrated view of a given webapp can be reached in two ways basically [17:13] 1. by browsing (with firefox or chromium at this point) to a supported websites, i.e. one that has an installed integration script associated, or one that "natively" integrated with Ubuntu through a direct usage of our API [17:14] 2. by using the launcher icon to start an already integrated web application, it then start a browser window (default one) in a special "chromeless" mode [17:14] this basically does not limits you to a given specific way to access a supported webapp [17:15] The chromeless mode offers a streamlined view of the default browser, removing all the unnecessary chrome keeping only the multitabs view [17:16] the menu is then streamlined to the bare minimum (and in the future will be expanded with webapp specific commands) [17:16] and some generic actions are disabled [17:17] the idea of a chromeless window is also to also act as a container for a group of common webapps (based on same website) [17:17] e.g. for the google docs webapp [17:18] all your document should open in the same chromeless window, nothing else [17:19] browsing outside of googledocs from a given chromeless tab will open a new chromeless window and start a new webapps container [17:20] we're really excited that this work we're doing offers so much opportunity for the Ubuntu community to contribute [17:21] now that we've introduce what we're trying to build, there are 2 more parts of our talk here. next we're going to give an overview of how all of the components fit together. then we'll go through a tutorial of writing a userscript [17:21] that's where the most help from the community will come, we hope. the more apps are integrated the better our work is and the better the web experience on ubuntu becomes. [17:22] we have some plans for the future to bring all of the work we've done to the various web standards bodies so that this can all be web supported cross platform work, started by and best on Ubuntu [17:22] ok onto the overview [17:23] first up is the userscript. this is the javascript code that integrates with a webapp to provide integration. [17:23] there are 2 types of scripts. userscripts and native [17:24] a userscript is essentially a greasemonkey script that gets injected into the browser and executed when the page loads, just like normal javascript. [17:24] these are what we ship in the unity-webapps package [17:25] these work to parse the DOM tree, and by making various calls to the Unity webapps API (http://developer.ubuntu.com/api/ubuntu-12.04/javascript/unity-web-api-reference.html) manage to send and receive messages to and from the launcher, HUD, messaging menu, and all of the various integration points [17:25] these are the bread and butter of what we do. the rest of our work goes into building the support structure so these work [17:26] our goal is for web developers to integrate our API right into their site so that the userscripts arent necessary, relieving us of a maintenance burden and allowing the web developers who really know their code, to craft a really beautiful and fully integrated experience for their site [17:27] so far we're already seeing some adopting of our API with web developers [17:27] for instance, Rd.io have integrated the unity api into their webapp [17:28] whatever the mean of integration as explained above [17:28] everything through browser specific extensions [17:29] that acts as a bridge between the "integration script" and the native backend [17:29] that communicates with the various Unity components targetted [17:30] the extensions manage all the tasks related with injecting our API, keeping track of the integration elements, and doing some book keeping in the background [17:31] two extensions are available, one for chromium and one for firefox [17:32] the one for chromium, can be seen in when navigating to chrome://extensions [17:33] without going too much into the technical side (ask questions if needed), each navigated tab has a content script associated to it that communicates back and forth with a background page script that checks if one or more integration script are available for the currently visited URL [17:34] the content script also injects the API in the javascript "world" associated with the page so that anywebsite can "natively" use it [17:34]