[02:54] <cc11rocks> 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] <cc11rocks> Setup (tools and such), upstream, common commands, basic process of getting things patched, etc is what I have for you...
[03:41] <cc11rocks> 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
[10:45] <bahdem> ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:56] <dholbach> Hello everybody, welcome to the last day of Ubuntu Developer Week!
[14:56] <dholbach> Here are just a few organisational bits and pieces before David Planella takes over:
[14:56] <dholbach> #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] <dholbach> If you do ask questions, please make sure you prefix them with QUESTION:
[14:58] <dholbach> ie: QUESTION: Is it true some of your teammates can discuss Metallica albums for hours?
[14:58] <dholbach> 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] <dholbach> If you would like to stop notices about people joining and parting coming in, please review https://wiki.ubuntu.com/UbuntuDeveloperWeek/JoiningIn
[14:58] <dholbach> To stay up to date with initiatives like this one, consider following @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to
[14:58] <dholbach> You still have 3 minutes to grab a tea, coffee or glass of water before dpm gets cracking :)
[14:58] <dholbach> Enjoy!
[14:59] <dpm> dholbach, running to the kitchen!
[15:00] <ClassBot> 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] <dpm> Hello everyone!
[15:01] <dpm> welcome to the first session of Ubuntu Developer Week Day 3!
[15:02] <dpm> it's a short session today, so let's just go for it :)
[15:02] <dpm> 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] <dpm> This is a bit of a different session than most of the topics this week.
[15:03] <dpm> I want to tell you about building upon the Ubuntu platform and create apps that run on it,
[15:03] <dpm> rather than developing and maintaining the platform itself.
[15:03] <dpm> To put it simple, the subject of this session will be how to get started
[15:03] <dpm> with the process of creating apps that run on Ubuntu, rather than how to developing the Ubuntu platform itself
[15:04] <dpm> Both are equally fun, so feel free to pick your poison ;)
[15:04] <dpm> Therefore, during the next half hour I'll be talking about how to submit your apps to Ubuntu, so
[15:04] <dpm> that they get published in the Software Centre, to be distributed to millions of
[15:04] <dpm> users that will surely enjoy your cool software :)
[15:05] <dpm> But it will not be just a talk: I'd like everyone to participate and ask their questions at the end.
[15:05] <dpm> However, feel free to interrrupt me during the rest of the session too, if you've got any questions.
[15:05] <dpm> Just remember to prepend them with QUESTION: on the #ubuntu-classroom-chat channel
[15:05] <dpm> Throughout the talk I will be referring to different places in the Ubuntu App Developer site,
[15:05] <dpm> which is the central place for anyone wanting to create and publish their apps in Ubuntu.
[15:05] <dpm> Here's where it lives:
[15:05] <dpm>     http://developer.ubuntu.com
[15:06] <dpm> So let's get cracking
[15:06] <dpm>  
[15:06] <dpm> Creating your app
[15:06] <dpm> [15:06] <dpm> Well, the first step is obvious, you have to create your app, which is basically
[15:06] <dpm> the time when you materialise that cool idea into beautiful software.
[15:06] <dpm> I will not dwell too much on this subject, as it's beyond the scope of the session,
[15:06] <dpm> However, I'll just add a couple of tips for app authors.
[15:07] <dpm> If you're considering writing a new application for Ubuntu, I'd recommend to use
[15:07] <dpm> the standard set of tools available from the Ubuntu archive.
[15:07] <dpm> 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] <dpm> but also will help you following good development practices.
[15:07] <dpm> And they're all Free Software and also free as in free beer!
[15:07] <dpm> You've got an overview of them here:
[15:07] <dpm>     http://developer.ubuntu.com/get-started/quickly-workflow/
[15:08] <dpm> What we've also got is a tool called Quickly, which puts all those technologies together
[15:08] <dpm> If you want to know more about it, mterry did a nice session during this UDW
[15:08] <dpm> so remember to check out the logs
[15:09] <dpm> You can learn more about it here too, it's got a nice and short video tutorial to show
[15:09] <dpm> you how to write a basic functional template for your app in a matter of minutes:
[15:09] <dpm>     http://developer.ubuntu.com/get-started/
[15:09] <dpm>  
[15:09] <dpm> Which types of apps qualify
[15:09] <dpm> [15:09] <dpm> There are thousands of apps available in the Ubuntu archive already, which usually get in there through other means.
[15:09] <dpm> Many of these fall into the category of system software, or big applications that are part of the Ubuntu platform.
[15:10] <dpm> They are also subject to strict policies to ensure the security and quality of the software,
[15:10] <dpm> as well as to ensure that they are indeed Free Software and can be distributed with Ubuntu.
[15:10] <dpm> 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] <dpm> Ultimately though, they are all published through the Software Centre
[15:10] <dpm> 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] <dpm> * Paid for apps
[15:11] <dpm> * Gratis apps with proprietary licenses
[15:11] <dpm> * Gratis apps with Open Source licenses
[15:11] <dpm> 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] <dpm>  
[15:11] <dpm> 1. Submitting your app
[15:11] <dpm> [15:12] <dpm> 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] <dpm> 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] <dpm> For this, we've developed a tool especially for app developers.
[15:12] <dpm> It's called My Apps and you'll find it on the app developer site:
[15:12] <dpm>     https://myapps.developer.ubuntu.com
[15:13] <dpm> 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] <dpm> 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] <dpm> Also, before you continue the process of submitting the app, you might want to read the quickstart guide on:
[15:14] <dpm>     http://developer.ubuntu.com/publish/
[15:14] <dpm> It will show you the basic steps you will be following and give you some useful tips along the way.
[15:14] <dpm> Let's go quickly through them:
[15:14] <dpm> 1 - Set up your My Apps account - you've already done that :)
[15:14] <dpm> 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] <dpm> 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] <dpm> 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] <dpm> (actually, I'd need to check if that has changed recently)
[15:16] <dpm> 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] <dpm> If you use Quickly, it will do that for you
[15:16] <dpm> so that you don't have to worry about packaging
[15:16] <dpm> 6 - Your app will be reviewed - before it gets into the wild, your app needs to be reviewed and QAd.
[15:17] <ClassBot> nja asked: ​ Why is the minimum price $2.99?
[15:17] <dpm> I believe that is (or was) a requirement from the bank that is used to do the money transfers
[15:18] <dpm> so there isn't much room for play here
[15:18] <dpm> but do check on MyApps and the FAQ. They should be up to date
[15:18] <ClassBot> commandoline asked: Is there any chance that open source apps developed this way can also get into debian?
[15:19] <dpm> 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] <dpm> ok, let's continue
[15:20] <ClassBot> There are 10 minutes remaining in the current session.
[15:21] <ClassBot> 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] <dpm> 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] <ClassBot> 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] <dpm> that's an excellent question
[15:23] <dpm> we have actually been discussing this over the course of the last few weeks
[15:23] <dpm> but such a feature is dependant essentially on sandboxing working well for all use cases
[15:24] <dpm> we've been discussing a plan for it, but it will span multiple releases to complete
[15:24] <dpm> stay tuned very soon for an announcement on the ubuntu-devel mailing list, and on the Ubuntu app development channels
[15:24] <ClassBot> 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] <ClassBot> There are 5 minutes remaining in the current session.
[15:25] <dpm> 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] <dpm> They are stripped during the build on the Launchpad buildds and put into the language-pack-* packages instead.
[15:40] <dpm> There is a set of language packs per language
[15:40] <dpm> 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] <dpm> Although this cycle, with KDE being in universe
[15:41] <dpm> we won't have KDE translations in language packs
[15:41] <dpm> 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] <dpm> lifecycle
[15:42] <dpm>  
[15:42] <dpm> Translations Import Workflow
[15:42] <dpm> ----------------------------
[15:42] <dpm> 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] <ClassBot> TheLordOfTime asked: if KDE translations arent included in language packs, how would KDE users get their localization/translation packs?
[15:42] <dpm> Ah, good question, but don't worry
[15:43] <dpm> They will still be shipped, simply not in language packs
[15:44] <dpm> 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] <dpm> in the case of KDE, translations will simply not be extracted and shipped in the original packages
[15:44] <dpm> so all is good :)
[15:44] <ClassBot> chilicuil asked: so, may I have translations from programs I've not installed?
[15:44] <dpm> Another good question
[15:44] <dpm> Yeah, that's actually the case
[15:45] <dpm> 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] <dpm> 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] <dpm> so where were we?
[15:47] <dpm> Oh, translations being extracted from packages...
[15:47] <dpm> ok, so here's what happens next
[15:47] <dpm> 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] <dpm> If you are interested in seeing what the imports queue looks like, you can see the translation uploads currently pending review here:
[15:47] <dpm> https://translations.launchpad.net/ubuntu/quantal/+imports?field.filter_extension=pot&field.filter_status=NEEDS_REVIEW&start=75&batch=75
[15:48] <dpm> That's the global imports queue, but you can see it per package as well
[15:48] <dpm> https://translations.launchpad.net/ubuntu/quantal/+source/unity/+imports
[15:48] <dpm> So now we come to the nitty gritty details... :)
[15:49] <dpm>  
[15:49] <dpm> Package Modifications for a better Ubuntu integration
[15:49] <dpm> -----------------------------------------------------
[15:49] <dpm> 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] <dpm> we make two main changes to the application at the packaging level:
[15:49] <dpm> * 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] <dpm> Actually, I think we can leave it to one change :)
[15:49] <dpm> For those not familiar with the concept of a POT template:
[15:49] <dpm> It's a textual file with the .pot extension
[15:50] <dpm> and it's what Launchpad use as the source for exposing translations
[15:50] <dpm> all translations in all languages will be based on that template, which contains the translatable messages in English
[15:50] <dpm> It's generally built by gettext-based tools
[15:50] <dpm> which extract translatable messages from the code in an application
[15:50] <dpm> and put them in the textual .pot file
[15:50] <ClassBot> There are 10 minutes remaining in the current session.
[15:51] <dpm> Actually, seeing that there are only 10 mins left, I think I'll wrap it up here and point you to:
[15:51] <dpm>     https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging
[15:52] <dpm> There you'll find the information I've been talking on in this session, and more
[15:52] <dpm> As per contributing with translations, the best place to get started is on:
[15:52] <dpm>     https://wiki.ubuntu.com/Translation
[15:53] <dpm> Ok, time for some questions, bring them on! :-)
[15:54] <ClassBot> JoseeAntonioR asked: How can I start a translation team for a language that hasn't been set up yet?
[15:54] <dpm> Aha, nice question!
[15:55] <dpm> You'll find detailed, step-by-step information on how to do that here: https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
[15:57] <dpm> ok, any other questions, or anything you've always wanted to know about translations and were afraid to ask?
[15:57] <dpm> ...3...
[15:58] <ClassBot> marcosb asked: shell scripts
[15:58] <ClassBot> marcosb asked: translation on shell scripts
[15:58] <dpm> ok, let me rephrase that... any _easy_ questions? ;-)
[15:59] <dpm> just joking, but translation of shell scripts is a bit hard to get right
[15:59] <dpm> and not always works fully
[15:59] <dpm> I'd recommend reading the gettext documentation for that, which contains a couple of good examples
[16:00] <dpm> my recommendation is that if you want to make a script translatable, just use Python
[16:00] <dpm> which fully supports gettext
[16:00] <dpm> ok, so time's up!
[16:00] <dpm> Thanks everyone for listening in and I hope you enjoyed the session!
[16:00] <ClassBot> 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] <gema> Hello everyone!
[16:01] <gema> I am Gema Gomez-Solano and I work in the Platform QA Team in Canonical
[16:02] <gema> and I am going to talk about UTAH, or the Ubuntu Test Automation Harness,
[16:02] <gema> it is a testing tool we are creating because we were lacking coherence in our testing
[16:02] <gema> we’d like to share it with other groups in case anyone is having the same kind of problems
[16:03] <gema> UTAH is a tool that is meant to help with end to end test automation.
[16:03] <gema> you can find the project in launchpad: https://launchpad.net/utah
[16:03] <gema> ok, so let's get started with what UTAH does
[16:04] <gema> 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] <gema> 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] <gema> we are interested in using hardware as well as VMs, 32 and 64 bits, ARM
[16:05] <gema> 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] <gema> there was a lot of redundant code being created everywhere
[16:06] <gema> 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] <gema> so we thought of this project to unify all the scattered work we were doing
[16:07] <gema> 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
[16:07] <gema> 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] <gema> we are expecting UTAH to help also reproducing bugs,
[16:08] <gema> 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] <gema> without having to worry too much about installing a system
[16:08] <gema> so we are trying to make testing repeatable
[16:08] <gema> I will describe a bit how the testing is meant to be structured in UTAH
[16:09] <gema> Testing structure
[16:09] <gema> 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] <gema> Test cases can have set up and tear down, so that you have control over your test environment
[16:10] <gema> 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] <gema> So do not make test cases dependant on each other so that they have to run in any specific order!
[16:11] <gema> Test cases  can be grouped in test suites.
[16:11] <gema> Test suites are group of test cases that target a particular piece of functionality and that makes sense to *maintain together*
[16:12] <gema> i.e. the code is going to be maintained by a particular developer who is the expert on that part
[16:13] <gema> for instance, file system testing may make a nice test suite, and then we could choose to
[16:13] <gema> execute only some of those for smoke testing and all of them if we wanted full regression testing
[16:13] <gema> 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] <gema> We also have runlists, which is a list of test cases and/or test suites that are run together
[16:14] <gema> 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] <gema> 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] <gema> runlists are groups of tests that makes sense to *run together*.
[16:15] <gema> 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] <gema> do you guys have any questions/comments?
[16:16] <gema> ok, you can interrupt me any time, I will continue with what UTAH provides to the tester
[16:17] <gema> So we've spoken already about provisioning, and how UTAH can do that for you
[16:17] <gema> 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] <gema> 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] <gema> 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] <gema> Test cases have timeouts, test suites have timeouts and you can even define a timeout for the overall execution
[16:18] <gema> 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] <gema> Runlists can cherrypick test cases from test suites, and they can either include test cases or exclude some
[16:19] <gema> we have added the options to help with maintainability of runlists
[16:20] <gema> What is the status of the development
[16:20] <gema> We are using UTAH already for bootspeed testing
[16:20] <gema> so any bootspeed testing results you see from now on, come from tests executed with the harness
[16:20] <ClassBot> There are 10 minutes remaining in the current session.
[16:20] <gema> 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] <gema> 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] <gema> we are trying to avoid that going forward
[16:22] <gema> 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] <gema> we are also working on provisioning ARM, so that we can finally run ARM tests fully automated in the lab
[16:22] <gema> this will be coming soon
[16:23] <gema> any questions anyone?
[16:24] <ClassBot> TheLordOfTime asked: How does one get UTAH so we can use it?
[16:24] <gema> good question, TheLordOfTime !
[16:25] <gema> the documentation on how to install and get utah is available online
[16:25] <gema> http://utah.readthedocs.org/en/latest/index.html
[16:25] <gema> and you can also join our mailing list
[16:25] <gema> https://lists.canonical.com/mailman/listinfo/ubuntu-utah-devel
[16:25] <gema> in case you run into problems
[16:25] <ClassBot> There are 5 minutes remaining in the current session.
[16:25] <gema> it is early days and we are getting it ready for everyone now
[16:26] <gema> there doesn't seem to be any more questions
[16:28] <ClassBot> jsjgruber-l85-p asked: Is it possible to have Utah test GUI applications?
[16:28] <gema> good question, right now that is not posible, but we are working on enabling it
[16:28] <gema> the reason it is not possible is because utah connects to the host to run the tests via ssh
[16:29] <gema> and we haven't decided how to start the x session and test from there
[16:29] <gema> if you have suggestions join the list and share them
[16:30] <gema> we are about to finish this session, but I am still here for the coming 30 mins
[16:30] <gema> ok, so I wanted to have time to talk about testing and automation in a more generic way
[16:30] <ClassBot> 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] <gema> not just utah, but discuss options that people have when considering automating testing for their applications/packages
[16:31] <gema> do you guys have any question that needs addressing?
[16:32] <gema> or want to know anything about how we are running all the automated tests you see in jenkins?
[16:34] <ClassBot> marcosb asked: say frameworks for automatized test for Linux.
[16:35] <gema> ok, marcosb, let's see
[16:35] <gema> I have already spoken about UTAH
[16:35] <gema> we have also in the ubuntu world autopilot
[16:36] <gema> you can use Xpresser
[16:36] <gema> you can even use checkbox for some existing test cases and certification
[16:37] <gema> marcosb: do you have any particular need to address so that I can give you a better answer?
[16:38] <gema> please, feel free to ask questions in this channel directly
[16:38] <gema> since this is more of a round table kind of session
[16:38] <gema> it makes sense
[16:38] <gema> no need to prefix with QUESTION:
[16:39] <chilicuil> sure gema, is nicolas skeggs part of your team?, or we have several testing teams here?
[16:39] <gema> chilicuil: nicholas skaggs is the QA Community coordinator
[16:39] <gema> so basically my team work focussed on automation and we also do manual testing during milestones
[16:40] <gema> which is what nicholas is coordinating
[16:40] <gema> so we work directly with nicholas in things that are open initiatives
[16:40] <gema> and just work in canonical creating test cases that nicholas and you guys can use to drive your testing later
[16:40] <gema> we do both things
[16:40] <gema> nick is not in our team but we talk on daily basis and collaborate
[16:41] <ClassBot> marcosb asked: No just interested about possibilites :)
[16:42] <gema> marcosb: ack
[16:42] <gema> chilicuil: do you collaborate on the ubuntu QA team?
[16:42] <chilicuil> gema: not yet
[16:43] <gema> chilicuil: we'll be happy to have you onboard whenever you want :)
[16:43] <chilicuil> I was just wondering why I've heart about UTAH in the mails nicolas send almost every day =)
[16:43] <chilicuil> I've not*
[16:43] <gema> chilicuil: because utah is in the process of being created, we are not fully in production yet
[16:43] <gema> so nicholas cannot still use our runlists
[16:44] <gema> but believe me he is asking me on regular basis :)
[16:44] <chilicuil> that answer my question, I hope to join u soon
[16:44] <gema> excellent
[16:44] <gema> any other questions / concerns?
[16:46] <gema> well, we have still some minutes to go, so let me know if you guys have anything
[16:46] <wan26> i was wondering what timezone the schedule for classes is in, i looked at the link provided here.
[16:47] <wan26> for future reference
[16:47] <TheLordOfTime> wan26:  the schedule is in UTC i think
[16:47] <TheLordOfTime> (GMT +- 0)
[16:47] <gema> yes, that confused me too
[16:47] <TheLordOfTime> "Events shown in time zone: GMT (no daylight saving)"
[16:47] <wan26> Thank you :)
[16:49] <gema> so if you guys want to have a look at results of our automated testing, feel free to look at jenkins
[16:50] <gema> https://jenkins.qa.ubuntu.com/
[16:50] <gema> we are working on a different view for results, but for now jenkins does the job
[16:50] <ClassBot> There are 10 minutes remaining in the current session.
[16:51] <gema> and if you want to collaborate with QA for Ubuntu, you can start on the wiki of the QA Team
[16:51] <gema> https://wiki.ubuntu.com/QATeam/
[16:52] <gema> 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] <gema> in under 10 minutes
[16:53] <chilicuil> 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] <JoseeAntonioR> 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] <gema> chilicuil: no worries about jenkins
[16:54] <gema> 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] <gema> jenkins is automated testing, it is what my team and others in Canonical do
[16:54] <gema> but people from the community can also help by testing images
[16:54] <gema> during milestones
[16:55] <gema> http://iso.qa.ubuntu.com/
[16:55] <gema> have a look here ^
[16:55] <gema> no need to understand jenkins for that :)
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:56] <chilicuil> I'll do gema, I just though I need to make sense of the results jenkins gave
[16:56] <gema> and if you wanted to know, say.. how quantal's image today is doing, you'd go here:
[16:56] <gema> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/
[16:56] <gema> and you see what image is being tested in the description
[16:56] <gema> and if it is sort of good or not
[16:56] <gema> it is just an indication that it is worth installing
[16:56] <gema> and doing further testing
[16:56] <gema> on it
[16:56] <wan26> Is this to gather as much data as possible for compatibility? Looks interesting
[16:57] <gema> wan26: we are not doing compatibility testing yet
[16:57] <gema> we still have to cover the basis of functional!
[16:57] <chilicuil> 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] <gema> chilicuil: the other way around
[16:57] <gema> when the automated testing is all red
[16:57] <wan26> aha I see
[16:57] <gema> it is not worth for you to try
[16:57] <gema> because it will probably not work
[16:57] <gema> you are welcome to, but you may encounter problems
[16:58] <gema> when things are green in the automated world
[16:58] <gema> then it is worth for people with brains to try and install
[16:58] <gema> because that finds problems
[16:58] <chilicuil> I'll stick with the iso.qa.ubuntu.com pagen then =)
[16:58] <gema> that the robot cannot find
[16:58] <gema> chilicuil: good choice :)
[16:58] <gema> we are wrapping up this session guys, we are in #ubuntu-testing if you want to continue this conversation
[16:59] <gema> or ask anything in the future
[16:59] <gema> a pleasure talking to you!
[16:59] <chilicuil> have a nice day gema, thanks for sharing UTAH with us
[17:00] <wan26> thanks
[17:00] <gema> thank you for listening :)
[17:00] <ClassBot> 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] <alex-abreu> Hi All
[17:03] <lamalex> hello everybody
[17:03] <alex-abreu> welcome this this session about Unity Web Apps technology
[17:04] <lamalex> we're both on Canonical's webapps team, working on- well webapps
[17:05] <lamalex> Canonical introduced webapps for a few reasons. We want to help close the gab between desktop and web development
[17:05] <lamalex> the distinction is kind of arbitrary and the only barrier is technological
[17:06] <lamalex> we're not the first to try and do this, but we think there is some novelty in our solution
[17:06] <lamalex> 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] <lamalex> 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] <alex-abreu> From the javascript API exposed to integration scripts (we will talk about what it is later) we offer multiple desktop integration points
[17:10] <alex-abreu> from this, the script has access to functionnalities from the messaging menu, the sound menu, the launcher (new icon, quicklists and counts),
[17:10] <alex-abreu> the dash (dynamically added actions), drag and drop (each integration scripts declares a set of mime-types that it supports)
[17:10] <alex-abreu> and the alt-tab switcher
[17:11] <alex-abreu> 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] <alex-abreu> the integrated view of a given webapp can be reached in two ways basically
[17:13] <alex-abreu> 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] <alex-abreu> 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] <alex-abreu> this basically does not limits you to a given specific way to access a supported webapp
[17:15] <alex-abreu> The chromeless mode offers a streamlined view of the default browser, removing all the unnecessary chrome keeping only the multitabs view
[17:16] <alex-abreu> the menu is then streamlined to the bare minimum (and in the future will be expanded with webapp specific commands)
[17:16] <alex-abreu> and some generic actions are disabled
[17:17] <alex-abreu> 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] <alex-abreu> e.g. for the google docs webapp
[17:18] <alex-abreu> all your document should open in the same chromeless window, nothing else
[17:19] <alex-abreu> browsing outside of googledocs from a given chromeless tab will open a new chromeless window and start a new webapps container
[17:20] <lamalex> we're really excited that this work we're doing offers so much opportunity for the Ubuntu community to contribute
[17:21] <lamalex> 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] <lamalex> 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] <lamalex> 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] <lamalex> ok onto the overview
[17:23] <lamalex> first up is the userscript. this is the javascript code that integrates with a webapp to provide integration.
[17:23] <lamalex> there are 2 types of scripts. userscripts and native
[17:24] <lamalex> 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] <lamalex> these are what we ship in the unity-webapps package
[17:25] <lamalex> 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] <lamalex> 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] <lamalex> 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] <lamalex> so far we're already seeing some adopting of our API with web developers
[17:27] <lamalex> for instance, Rd.io have integrated the unity api into their webapp
[17:28] <alex-abreu> whatever the mean of integration as explained above
[17:28] <alex-abreu> everything through browser specific extensions
[17:29] <alex-abreu> that acts as a bridge between the "integration script" and the native backend
[17:29] <alex-abreu> that communicates with the various Unity components targetted
[17:30] <alex-abreu> 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] <alex-abreu> two extensions are available, one for chromium and one for firefox
[17:32] <alex-abreu> the one for chromium, can be seen in when navigating to chrome://extensions
[17:33] <alex-abreu> 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] <alex-abreu> the content script also injects the API in the javascript "world" associated with the page so that anywebsite can "natively" use it
[17:34] <lamalex> The logic of the firefox extension is very similar to that of the chromium one, but the firefox extension uses a forked version of greasemonkey to handle loading and injecting the userscripts. In Quantal we ship Firefox with a patch that backports a feature from FF17 that allows us to get the XID of the tab. We use this for window tracking, raising the right tab of a webapp, and stuff like that
[17:35] <lamalex> From the browser extensions, the data sent via the API shoots to a daemon running in the background.
[17:36] <lamalex> there are two daemons, context-daemons and the webapps-service daemon
[17:36] <lamalex> webapps service takes care of general tasks (unrelated to specific website).
[17:37] <lamalex> and the context-daemons do the integration for each instance of a webapp and the desktop
[17:37] <lamalex> if you open up D-feet, the dbus browser and type webapp
[17:37] <lamalex> you'll see the named service bus and a few private ones
[17:37] <lamalex> the private ones represent an instance of a webapp. those are spawned each time you open gmail, docs, twitter, etc
[17:39] <lamalex> ok- now onto the tutorial! we're going to walk through the one published on webapps.ubuntu.com
[17:39] <lamalex> http://developer.ubuntu.com/resources/app-developer-cookbook/unity/integrating-tumblr-to-your-desktop/
[17:39] <lamalex> which i guess we should also pimp out webapps.ubuntu.com as the developer site for webapps. API docs, tutorial, etc is all there. if you need info- that's a good place to start
[17:40] <lamalex> so let's just jump right in- you're all literate and can read the tutorial in its entirety at another time. we just want to help you explore the API
[17:41] <lamalex> this tutorial is mostly based around the tumblr dashboard so if you don't have a tumblr account you'll have to a) make one or b) just follow along and try modifying what we're doing to match some other site. that's really what you'll be doing when you write a userscript anyway
[17:42] <lamalex> this tutorial uses firefox, let's use chromium just for change of pace. open up tumblr.com in a chromium browser and log in to the dashboard
[17:42] <lamalex> ctrl+shift+j will open the javascript console
[17:43] <lamalex> this is where we'll be working for the rest of this demo- and while we're doing this demo I suppose we can start Q&A since we're running out of time. Sound good to you alex-abreu?
[17:44] <lamalex> step 1 is always to load the unity object, and is done the same way every time
[17:44] <lamalex> in your JS console enter window.Unity = external.getUnityObject(1);
[17:45] <lamalex> the parameter (1) is for API version.  it's just to ensure your script is set up to use the proper version of the API.
[17:45] <alex-abreu> (sure)
[17:47] <alex-abreu> Please keep in mind that a given integration script will be run & executed everytime you basically browse a webpage
[17:47] <alex-abreu> one thing that you will see in most of the integration scripts already there
[17:47] <alex-abreu> is a function called isCorrectPage()
[17:47] <alex-abreu> this is not mandatory per se
[17:47] <alex-abreu> but strongly advised
[17:48] <alex-abreu> one of the *important* thing that we try to do is to *expand* the user's experience
[17:48] <alex-abreu> without altering the experience or deteriorating it if something is wrong
[17:48] <alex-abreu> or even modifying the webpage in any way
[17:49] <alex-abreu> so the idea behind the function above, is to make sure that the webpage has all the elements that you expect it to have before starting an init
[17:50] <lamalex> are we out of time already?
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:50] <lamalex> yar
[17:51] <lamalex> so if we refer to the tutorial, we see is isCorrectPage function wrapping a call to Unity.init
[17:51] <lamalex> Unity.init is the base function for all of your userscripts. This kicks off a new context-daemon, adds an icon to the launcher/switcher
[17:52] <lamalex> it takes its parameters in the form of a dictionary and has 3 required parameters
[17:52] <lamalex> name, iconUrl, onInit
[17:52] <lamalex> name is the name of your webapp, very obvious
[17:53] <lamalex> the icon url is a url to an icon. this can take the form of icon:// for a local icon in an icon theme- or the location of an image on a webpage
[17:53] <alex-abreu> (make sure to select a meaningful name, it will be used when the user is being asked for integration permission)
[17:53] <lamalex> for instance the url to the tumblr icon on the dashboard is http://assets.tumblr.com/images/logo.png. so you could do:
[17:54] <lamalex> Unity.init({name: "Tumblr", iconUrl: "http://assets.tumblr.com/images/logo.png", onInit: wrapCallback(setupTumblr)});
[17:54] <lamalex> and this would use the hosted tumblr icon rather than one installed in the system.
[17:55] <lamalex> onInit is a callback and that's where all of the meat of your userscript will happen
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[17:55] <lamalex> once the daemon has been initialized and all of the system bits are ready to go, this will be called and your script will start to run. in here you integrate with the messaging menu, etc
[17:56] <lamalex> since we're pretty much out of time I don't see much reason in going too much deeper. like we said, there's a helpful tutorial available from http://developer.ubuntu.com/resources/app-developer-cookbook/unity/integrating-tumblr-to-your-desktop/
[17:56] <lamalex> and #ubuntu-webapps is always available if you need more help feel free to ping any one of us
[17:56] <lamalex> are there any questions?
[17:56] <lamalex> comments?
[17:57] <alex-abreu> once your callback (specified in the onInit propery or the init() call) is called, you will have: a launcher icon present and be ready to use the API and integration points
[17:57] <lamalex> thanks for tuning in. hope this session was informative and inspiring
[17:58] <lamalex> go write userscripts
[17:58] <alex-abreu> you can reach us and ask any question in #ubuntu-webapps as stated by lamalex, or in askbuntu.com w/ the "webapps" tag
[18:00] <aquarius> Hi! I'm Stuart Langridge, and I'm here to talk about u1db.
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html following the conclusion of the session.
[18:01] <aquarius> first, thanks to the Alexes :-)
[18:01] <aquarius> The subtitle for this talk on the schedule is "synced data for your apps on many platforms", and that's what u1db does.
[18:01] <aquarius> You build an app, and use u1db to store its data, and you can then sync that data to your app on other machines and other devices and other platforms.
[18:02] <aquarius> So if you built an Ubuntu app, you could have the same data sync between all your Ubuntu machines, meaning that your data is everywhere.
[18:02] <aquarius> You could also sync to other platforms, so an Android app could share the same data, and so on.
[18:02] <aquarius> Imagine your shopping lists and your notes and your movie watching habits and your music ratings in your Ubuntu desktop and your smartphone and on the web available from anywhere.
[18:03] <aquarius> So far, this is just syncing, like Ubuntu One file sync: why have a database?
[18:03] <aquarius> U1DB is good at dealing with data; file sync isn't.
[18:03] <aquarius> Some people have thought in the past "hey, my app stores things in SQLite; I'll just use U1 to sync my app's data folder and then my data is synced everywhere, woo!"
[18:03] <aquarius> This is great, until it isn't.
[18:04] <aquarius> If you make changes to your SQLite database on two different machines, they'll conflict, because SQLite isn't designed for syncing.
[18:04] <aquarius> So you'll get a conflict from Ubuntu One file sync, which you'll have to resolve.
[18:04] <aquarius> U1DB is cleverer than that; changes to your data won't conflict unless they really, really need to, so it's much more suitable for syncing.
[18:04] <aquarius> You probably have questions at this point, but let's see some code first and then we can discuss.
[18:04] <aquarius> First, you'll need u1db, of course.
[18:05] <aquarius> For this talk, you'll need to get u1db from launchpad, with "bzr branch lp:u1db"
[18:05] <aquarius> (U1DB itself is now available in Ubuntu Quantal, but for this demo please get the Launchpad version because it contains the example app as well!)
[18:05] <aquarius> Once you have u1db, this should work and not throw errors: PYTHONPATH=u1db python -c "import u1db"
[18:05] <aquarius> (I pause a little to give people a chance to grab u1db :))
[18:06] <aquarius> Let's try a simple example of a working app first: the u1db distribution comes with an example app called "cosas", which is a small todo list.
[18:07] <aquarius> (Everyone writes a todo list now: it's like the Hello World of the 21st century)
[18:07] <aquarius> cd u1db/cosas
[18:07] <aquarius> PYTHONPATH=.. python ui.py
[18:07] <aquarius> and you should see a todo list window pop up, looking like http://ubuntuone.com/7aOvtpIljWwbwB1FEFbs5L
[18:08] <aquarius> (you might need to apt-get install python-qt4 if you don't have it)
[18:08] <ClassBot> calmi asked: python is the recommended language?
[18:09] <aquarius> calmi: I'll get to that. It is *a* language you can use :)
[18:09] <aquarius> there are many others :)
[18:09] <aquarius> Add a couple of tasks, tick a couple
[18:09] <aquarius> Then from the app menu, do File > Synchronize
[18:09] <aquarius> and choose Ubuntu One and Synchronize Now
[18:09] <aquarius> (this demo is for people who have an Ubuntu One account; if you don't have one, just skip doing this and take my word for it. You can sync u1db without using Ubuntu One at all by running your own server)
[18:10] <aquarius> Your little todo list is now synced with your U1 account!
[18:10] <aquarius> You can prove this: quit cosas and then delete the file ~/.local/share/cosas/cosas.u1db, as if you're a second machine
[18:11] <aquarius> If you now restart cosas you'll have no todo list items... just File > Synchronize again and they'll be synced to you!
[18:11] <aquarius> Obviously you could be running cosas on many different Ubuntu machines and the data could be synced to all of them.
[18:12] <aquarius> So, let's see how this actually works. I'll show using U1DB from Python on Ubuntu, but it's also available in other platforms and languages too, which I'll talk about later.
[18:12] <aquarius> Start with some simple examples, taken from the documentation at http://packages.python.org/u1db/
[18:12] <aquarius> Start a python interpreter with "python"
[18:12] <aquarius> >>> import u1db
[18:12] <aquarius> >>> db = u1db.open("mydb.u1db", create=True)
[18:13] <aquarius> We've now created a U1DB database named mydb.u1db.
[18:13] <aquarius> Next, we'll create a document in it. U1DB is a document-based database: you save JSON documents into it. So, a simple document naming a person:
[18:13] <aquarius> >>> content = {"name": "Alan Hansen"}
[18:13] <aquarius> >>> doc = db.create_doc(content)
[18:13] <aquarius> And the Document is saved in the database. You can still see the Document's content:
[18:14] <aquarius> >>> doc.content
[18:14] <aquarius> {'name': 'Alan Hansen'}
[18:14] <aquarius> We can edit the content of that document, of course:
[18:14] <aquarius> >>> doc.content = {"name": "Alan Hansen", "position": "defence"}
[18:14] <aquarius> After changing the content, we need to save that updated Document:
[18:14] <aquarius> >>> rev = db.put_doc(doc)
[18:14] <aquarius> And now the updated document is saved in the DB, ready to be retrieved or queried or synced.
[18:15] <aquarius> Let's create a couple more documents:
[18:15] <aquarius> >>> doc2 = db.create_doc({"name": "John Barnes", "position": "defence"})
[18:15] <aquarius> (and we'll change the content before saving: Document.content is a dictionary)
[18:15] <aquarius> >>> doc2.content["position"] = "forward"
[18:15] <aquarius> >>> db.put_doc(doc2)
[18:15] <aquarius> >>> doc3 = db.create_doc({"name": "Ian Rush", "position": "forward"})
[18:15] <aquarius> and we now have three documents.
[18:15] <aquarius> Retrieving documents from the database with a query is done by creating an "index".
[18:15] <aquarius> To create an index, give it a name, and the field(s) in the document that you want to query on:
[18:15] <aquarius> >>> db.create_index("by-position", "position") # create an index by passing a field name
[18:16] <aquarius> so we have an index, named "by-position", indexing all documents on the field "position".
[18:16] <aquarius> And now we can query that index for a particular value. If we want to get everyone with position="forward" in our list of people:
[18:16] <aquarius> >>> results = db.get_from_index("by-position", "forward")
[18:16] <aquarius> And our results is a list of two Documents:
[18:16] <aquarius> >>> len(results)
[18:16] <aquarius> 2
[18:17] <aquarius> And you can manipulate that list just like a standard Python list, which is what it is:
[18:17] <aquarius> >>> data = [result.content for result in results]
[18:17] <aquarius> >>> names = [item["name"] for item in data]
[18:17] <aquarius> >>> sorted(names)
[18:17] <aquarius> [u'Ian Rush', u'John Barnes']
[18:17] <aquarius> That's the very basics of using u1db: saving data, loading it, and querying for it, same as any database.
[18:17] <aquarius> The documentation at http://packages.python.org/u1db/ goes into much, much more detail.
[18:18] <aquarius> In particular, the tutorial at http://packages.python.org/u1db/tutorial.html walks through cosas, the example todo list app, and explains how it structures its data and how to sync a U1DB with other places, like Ubuntu One.
[18:19] <aquarius> As I said right at the beginning, U1DB is designed to work everywhere.
[18:19] <aquarius> This means that there will be, or could be, a U1DB implementation for any choice of platform and language.
[18:19] <aquarius> What I've shown above is the Python implementation, which should work on any platform where you have Python (so Ubuntu, other Linuxes, Windows, Mac, N9, etc).
[18:20] <aquarius> There is also a C implementation, so if you're writing apps in C or some other C-bound language you can use the C version.
[18:20] <aquarius> At U1 we're also building an Android Java version and an iOS Objective-C version, in time.
[18:20] <aquarius> There's also a command line client (u1db-client, and u1db-serve to run a simple server).
[18:21] <aquarius> Members of the U1DB team are also bringing U1DB to Vala, Go, and in-browser JavaScript.
[18:21] <aquarius> So apps using all those languages on all those platforms will be able to sync data: imagine your app on Ubuntu and a mobile version on your Android phone and a web version, all able to sync data between themselves.
[18:22] <aquarius> Part of the goal of U1DB is that if you decide that you want to be able to use it in a platform we haven't provided (and you can't or won't bind to the C version) then it ought to be possible to do a full reimplementation of it in your chosen language for your chosen platform
[18:23] <aquarius> There's a very comprehensive test suite exactly so that it's possible to test compliance.
[18:23] <aquarius> So we're building U1DB for a whole load of different platforms, and it's possible to bring it to others.
[18:23] <aquarius> U1DB is in Ubuntu Quantal, so your apps can depend on it.
[18:24] <aquarius> You don't actually have to sync data to use U1DB, of course: you can just use it as a database and never sync it at all!
[18:24] <aquarius> If you use U1DB in an app now, then you can add syncing later when you choose to.
[18:24] <aquarius> This has been a brief tour of U1DB, and I'm sure there are questions, so I'll happily take them now :)
[18:24] <ClassBot> jsjgruber-l85-p asked: How is this different from couchdb?
[18:25] <aquarius> Similar goals, similar-ish implementation, but the big difference is that U1DB runs in your process, and it's built separately for each platform and uses the platform's native data storage capabilities.
[18:25] <aquarius> So couchdb was a server; if you wanted to use couchdb on your phone, you (or someone else) had to port the whole couchdb server to that platform, and run it as a server there and connect to it.
[18:26] <aquarius> u1db is built separately and independently for each platform
[18:26] <aquarius> so it's not making one codebase run everywhere; an implementation can do whatever makes the most sense on the platform it's on: an Android version would likely be written in Java, for example
[18:27] <aquarius> and an in-browser JavaScript version would be run entirely by your web app; it's not a separate server that you have to deploy and secure, it's entirely client-side and then you sync it with a u1db server elsewhere.
[18:27] <aquarius> using the DB is similar: it's a store of JSON documents, which is similar to couch.
[18:28] <aquarius> does that answer the question? :)
[18:28] <ClassBot> jsjgruber-l85-p asked: How will it avoid the scaling problems couchdb had on the U1 infrastructure?
[18:29] <aquarius> we've deliberately built the U1DB server infrastructure to work exactly for this use case
[18:30] <aquarius> I'm not the server scaling expert, but I know the people who are :) If you have specific questions, we can answer them
[18:31] <ClassBot> wan26 asked: What encryption scheme is used for sync?
[18:31] <aquarius> Sync to Ubuntu One is always over SSL
[18:32] <aquarius> If you run your own server, you are able to run it over SSL or not as you choose
[18:33] <aquarius> and sync to U1 is authenticated the same way as all the other Ubuntu One APIs
[18:33] <aquarius> again, if you run your own server, you can (and should) define your own authentication policy :)
[18:34] <aquarius> The best place to learn about u1db is the documentation, as mentioned, at http://packages.python.org/u1db/
[18:35] <aquarius> There are introductory materials there to get started, and a much deeper dive into the intricacies of querying, syncing, replication, and so on when you want to do more complicated things
[18:36] <aquarius> or if you want to do a new implementation of u1db for a different platform
[18:36] <aquarius> but the best thing is to use u1db as it exists and build apps on it :)
[18:38] <aquarius> one of the apps in the recent Ubuntu App Showdown (tickit) is using u1db for storage precisely to get syncing capabilities
[18:38] <aquarius> and we have a bunch of others talking to us as well :)
[18:38] <aquarius> you can get hold of the u1db team if you have questions once you start development on irc, here on freenode, on #u1db
[18:39] <aquarius> and the mailing list at https://launchpad.net/~u1db-discuss
[18:40] <aquarius> and if you fancy helping me work on the JavaScript version, that'd be great :P
[18:43] <aquarius> So, that concludes the brief tour: if you have questions, or you're thinking of using u1db, or curious as to how you'd use it, speak now. :)
[18:45] <aquarius> Cool, no more questions
[18:45] <aquarius> So, thank you for your time: come and tell us about which apps you're using u1db in!
[18:51] <ClassBot> There are 10 minutes remaining in the current session.
[18:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:00] <bdrung> hi, i am Benjamin Drung, a Debian and Ubuntu Developer. I am here to answer your questions.
[19:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html following the conclusion of the session.
[19:01] <JoseeAntonioR> ok guys, so let's get started with the roundtable
[19:01] <JoseeAntonioR> thanks everyone for coming to our Ubuntu Developer Week for this cycle
[19:01] <JoseeAntonioR> I hope you've enyojed all our sessions, this is the last session for this event :)
[19:02] <JoseeAntonioR> this is basically a session where you're able to interact with different developers, so, if you're a developer just say hi, and bring in your question
[19:02] <JoseeAntonioR> or if not, and just want to ask, go ahead, you're free to :)
[19:03] <JoseeAntonioR> some of you can also be sharing experiences as developers later, so get ready for this last hour!
[19:04] <bdrung> if you will have questions later, feel free to ask them on IRC (in #ubuntu-devel, #ubuntu-motu, or #ubuntu-packaging) on on the mailing lists.
[19:04] <JoseeAntonioR> let me remind you all interaction is via this channel (#ubuntu-classroom), as this session is non-moderated
[19:04] <JoseeAntonioR> so, anyone's got any questions?
[19:05] <TheLordOfTime> JoseeAntonioR:  note that some questions might drop into -chat, for those using lernid.
[19:05] <TheLordOfTime> ;)
[19:05] <JoseeAntonioR> and I'll get them here, so don't worry about that
[19:06] <JoseeAntonioR> so, if you're a developer, or would like to get started on it, raise your hand!
[19:06] <JoseeAntonioR> o/
[19:07] <wan26> I'd like to get started but don't know how to become directly involved
[19:07] <thummar> o/
[19:07] <wan26> o/
[19:07] <JoseeAntonioR> wan26: I'm sure many people have that problem :)
[19:07] <stadtfeld> o/
[19:07] <jincreator> o/
[19:08] <bdrung> wan26: don't you know on what you should work or don't you know how to interact with Ubuntu?
[19:08] <chilicuil> o/
[19:08] <JoseeAntonioR> great, seems like we've got many people in here, anyone else? :)
[19:08] <bdrung> i started becoming a Ubuntu developer by scratching my own itch. i needed a newer version of matplotlib and tried to update the package.
[19:09] <bdrung> thummar: ask!
[19:10] <raki1> o/
[19:10]  * ScottK is here now too.
[19:10] <JoseeAntonioR> seems great!
[19:10] <JoseeAntonioR> so, bdrung, can you please tell us about your experience as an Ubuntu developer?
[19:11] <ScottK> I came in at bdrung saying "i started becoming a Ubuntu developer by scratching my own itch." - This was true for me too.
[19:11] <bdrung> scratching your own itch is a very motivating reason to start working on free software.
[19:12] <bdrung> finding an itch is easy: you probably experienced a bug that annoys you or you want a newer version of a program, but it's not updated in the current development release.
[19:14] <bdrung> over 4 years ago, i participated in a packaging jam, in which dholbach explained how to package stuff.
[19:14] <bdrung> i saw all the tools used in a very short time, but i knew that i would be able to learn them.
[19:15] <bdrung> packaging is knowing a bunch of command line tools and file formats.
[19:15] <ScottK> Finding an itch was a start, but it's not what sustains me.  I think people should do their bit to make the world a better place and contributing to free software is part of how I do that.  I wrote about it a few years ago: https://skitterman.wordpress.com/2009/05/31/back_home_from_uds_karmic/
[19:16] <JoseeAntonioR> seems great, so anyone else here has got any experiences you want to share with us?
[19:17] <chilicuil> I've a question, hope u dont matter if I do it while sharing experiences, what are ur favorite|most used tool in the ubuntu-dev-tools pkg ?
[19:18] <bdrung> there are a bunch: syncpackage, wrap-and-sort, sponsor-patch come to my mind
[19:19] <bdrung> syncpackage is for syncing a package from Debian to Ubuntu. if you have no upload right, you will probably use requestsync instead.
[19:19] <bdrung> wrap-and-sort will make your debian/control file look nicer (at least for me)
[19:20] <JoseeAntonioR> ok, so, cdunlap asks: Do they still do packaging Jams where you can get some of this knowledge?
[19:20] <ScottK> Developers use tools very differently and that's OK.
[19:20] <ScottK> I use syncpackage all the time, but I've never used the other two.
[19:21] <bdrung> sponsor-patch is for sponsoring a package for someone else, it download the source package, applies the proposed patches, test builds it. this tool allows me to concentrate on looking on the proposed changes.
[19:22] <ScottK> I think they still do packaging jams, but there's no need to wait.  I learned before such a thing existed.  If you've got something to work on, dive in and start and the people on #ubuntu-motu will be glad to help if you get stuck.
[19:22] <bdrung> ScottK: you should try wrap-and-sort! ;)
[19:23] <ScottK> There's lots of documentation (enough to be overwhelming), but as long as you're trying to figure it out and not just waiting to be spoon fed, people will help you.
[19:23] <ScottK> Don't worry about appearing not to know stuff when you ask questions.  I've been doing this since 2007 and I still have questions.
[19:23] <bdrung> cdunlap: i can't remember when we had the last packaging jam. The Ubuntu Developer Week is a equivalent event that can trigger someone to start diving into development.
[19:26] <wan26> I've noticed many people write code differently, how do you deal with that if someone has a different style ? or is there a general style you all adhere to?
[19:26] <ScottK> The biggest problem I see people have with getting into development is not being enough of a self-starter.  This is not a regular job with a manager that will set work in front of you and tell you what to do and when it needs to be done by.  You need to find the motivation in yourself to get something done.  If you can find that, you'll succeed because the actual technical knowledge needed for most package activities isn't that complex
[19:26] <ScottK> (there's a lot of it, but the individual pieces aren't hard).
[19:27] <JoseeAntonioR> calmi asked: to the experienced developers: can you still abstract your point of view? i.e. can you still put yourself in the posion of - let's say your father trying to get things done with little knowledge about computers?
[19:28] <ScottK> wan26: Distribution packaging is primarily integration work, so we don't write a lot of code from scratch.  If you're working on patching something to fix a bug or work better on Ubuntu, you generally want to stick with the upstream style for consistency and to maximize the chance of the patch getting accepted upstream.
[19:29] <ScottK> JoseeAntonioR: It's very difficult.  I often ask people who are new to development to go fix documentation after I help them with something because they are much better positioned to write it so it works for the new developer audience than me.
[19:29] <JoseeAntonioR> calmi: ^
[19:29] <ScottK> Right.
[19:30] <chilicuil> do u use the distributed development system (branch/merge) or are u stick with the debian way to produce the patches?, do you think the new Ubuntu way is ready to use safty for new contributors? what're some of the things that the Ubuntu way cannot still handle?
[19:30] <ScottK> I never use UDD.
[19:30] <ScottK> I tried it and found it more complex and the tools not mature.
[19:31] <ScottK> I think it's a mistake to teach it to new people first since as soon as they hit a branch that's out of date, they have to go back to the old way, so they still need to know that too.
[19:31] <bdrung> calmi: good question. I help a bunch of people in my neighbourhood to maintain Ubuntu. looking at how they interact with the computer shows the difference to my usage. I do stuff quickly and often on the command line, but that doesn't explain what prevents them to do the same stuff.
[19:31] <ScottK> Also, if you want to get involved in Debian (which I recommend), you're better off knowing how the more general tools work.
[19:32] <ScottK> That said, I love the package branches that are generated on each upload.  It makes it very easy to go back and figure out what changed, when and why.
[19:32] <ScottK> It's an awesome tool for forensics.
[19:33] <JoseeAntonioR> any other questions or ideas?
[19:33] <bdrung> I rarely use UDD. I do most of my stuff in some Debian version control systems (in most cases: git).
[19:33] <ScottK> That does bring up another good point.  Both bdrung  and I are also Debian developers.
[19:34] <ScottK> We both started with Ubuntu and migrated to start doing work in Debian too.
[19:34] <jincreator> Many Ubuntu developers are also Debian developers(as far as I know). What makes them(you) also start paritipate in Ubuntu?
[19:34] <ScottK> So for packages I maintain, I'm almost always uploading to Debian and syncing.
[19:34] <ScottK> I started in Ubuntu.
[19:35] <bdrung> More people benefit if you do stuff upstream.
[19:35] <ScottK> Exactly.
[19:35] <bdrung> jincreator: I started in Ubuntu and became Debian Developer (DD) afterwards.
[19:35] <ScottK> Also if changed done in Ubuntu get ported up to Debian, that's less work for Ubuntu developers to have to deal with.
[19:36] <ScottK> This is important.  Debian has about an order of magnitude more developers than Ubuntu and so it's critical for as much to be done there as possible.
[19:37] <bdrung> Doing stuff just in Ubuntu will give you a diff between Debian and Ubuntu. Then a Ubuntu Developer needs to maintain this diff. This takes time that could have been used for something else.
[19:37] <ScottK> Also Debian package maintainers are experts in their package so by working with Debian people you get good feedback it's hard to get in Ubuntu where most developers are generalists and few packages have dedicated maintainers.
[19:37] <bdrung> Debian has around 1000 developers. Ubuntu has only around 150.
[19:38] <ScottK> I know Debian developers that have gotten involved in Ubuntu.
[19:38] <chilicuil> in order of difficultity how would you clasify the tasks you do?
[19:39] <ScottK> Generally it seems to be either a desire to learn about issues with their packages (Ubuntu has a LOT of users and the file a lot of bugs) or they consider worrying about users of Debian derivatives like Ubuntu a natural extension of the Debian Social Contract.
[19:39] <bdrung> that depends. doing one specific task the first time can be difficult. doing the same task for the tenth time is easy.
[19:40] <stadtfeld> Let's say you start contributing by doing some bug fixes and writing some patches, what happens next? How do you go from being let's say casual contributer  to ubuntu developer?
[19:41] <chilicuil> I mean, I find myself creating a patch for an Ubuntu package a lot easier (if it's not a difficult one) than merging or working with FTFBS, I've never managed to fix one of those
[19:42] <ScottK> stadtfeld: Usually people are seriously considered for being an Ubuntu dev until they've been contributing for about six months.
[19:42] <bdrung> stadtfeld: once you contribute for at least a half year and your sponsors have nothing to complain about your proposed changes, you can apply for uploads rights at the Developer Membership Board (DMB)
[19:42] <ScottK> Sometimes sponsors will tell you they think it's time to apply.  If you think maybe you're ready, you should ask people that have been sponsoring you.
[19:43] <ScottK> chilicuil: Fixing a FTBFS is still just some kind of a patch usually, it's just often hard to figure out what the patch should be.
[19:43] <stadtfeld> I see, thanks :)
[19:43] <bdrung> stadtfeld: you could also ask your sponsors if they think that you are ready to get upload rights. in my case my sponsors encourage me to apply for uploads right before i was thinking about it.
[19:44] <bdrung> chilicuil: it's very useful to know the programming language (and sometimes the build system) to fix a FTBFS.
[19:45] <bdrung> chilicuil: it often depends on the background what is considered easy or hard.
[19:45] <ScottK> The hardest thing is packaging something new from scratch.  Not because it's particularly complex, but because to do this you need to know about all aspects of packaging.  I think that's the one thing to stay away from to start.
[19:46] <bdrung> yes, starting with packaging something from scratch is not a good idea.
[19:47] <ScottK> Becoming an Ubuntu developer is a very big step.  It means you can upload code to the official archive without further review that might eventually run on millions of desktops.
[19:47] <ScottK> It's critical that the community know you well enough to trust you before granting that privilege.
[19:47] <JoseeAntonioR> calmi asked: how is the relationship between ubuntu developers and those of ubuntu "official" derivates as k/x/lubuntu and especially linux mint "secessionists" ;)?
[19:48] <ScottK> I'm not aware that there is one.
[19:48] <ScottK> I know Ubuntu works really hard to push fixes it does into Debian and I've done so literally hundreds of times.
[19:48] <ScottK> I don't recall ever seeing someone from Mint doing the same.
[19:49] <ScottK> Ubuntu has a lot of derivatives and I don't think anyone in Ubuntu minds a bit.
[19:49] <ScottK> As a rule though, I don't think there's a lot of interchange.
[19:50] <ScottK> It's equally possible that I'm working with people who also work on Mint and I just don't know it.
[19:50] <ClassBot> There are 10 minutes remaining in the current session.
[19:50] <bdrung> The difference of Ubuntu/Kubuntu/Xubuntu is just the CDs. There is no difference between a Kubuntu or Xubuntu developer. We all work on the same archive. Just a different set of packages is used to build the CDs.
[19:51] <ScottK> Yes.
[19:51] <jsjgruber-x-p_> Can you get upload rights without packaging from scratch?
[19:51] <ScottK> Yes.
[19:51] <gustavo_> enc
[19:51] <ScottK> If you've done enough other things.
[19:52] <ScottK> We generally encourage new packages to go to Debian these days so packaging from scratch in Ubuntu is not the norm.
[19:52] <JoseeAntonioR> calmi asked: so everyone does his thing in "his tribe" except ubuntu-debian?
[19:52] <bdrung> I newer met a Mint developer. Maybe I worked with them, but then they didn't say that they were from Mint.
[19:52] <ScottK> calmi: We can't answer that.
[19:53] <ScottK> I do know that the Sabily developers are active in Debian/Ubuntu.
[19:53] <ScottK> So that's at least one exception.  The Ichthux developers were too when it was active.
[19:54] <ScottK> So there are some exceptions.
[19:54] <bdrung> calmi: Mint uses the Ubuntu archive and add some packages, but Ubuntu uses just the source packages from Debian.
[19:54] <ScottK> I also see developers from other Debian derivatives active in Debian.
[19:54] <chilicuil> the people who help u to come abroad are still part of ubuntu?, do u see people leaving ubuntu at the same rate new people jumps in?, how is the relation?
[19:54] <bdrung> calmi: Every update to the Ubuntu archive will end up in Mint.
[19:55] <ScottK> One point I want to make sure that I make is that Ubuntu participation is based on contribution and merit.
[19:55] <ScottK> It doesn't matter who you work for.
[19:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:55] <jincreator> How much times do you spend on contribuing Ubuntu?
[19:56] <ScottK> I'm, among other things, a member of the Ubuntu Archive team who's job it is to check and make sure new packages are legal for Canonical and the Ubuntu mirrors to distribute, even though I don't and have never worked for them.
[19:57] <bdrung> chilicuil: most of them are still active. some are less active than they used to be. the job and the real life can influence the time you have to spent on Ubuntu.
[19:57] <ScottK> jincreator: It varies a lot.  I've probably spent less than two hours this week, including this last hour, but then some times I've spent full days on it.
[19:58] <bdrung> jincreator: around one hour per week for the DMB and a varying timespan for packaging stuff (between 0 hours till 60 hours per week)
[19:59] <ScottK> I've done all nighters where someone broke something and I was the only one around that could fix it.
[19:59] <bdrung> jincreator: i have spent just this hour this week for Ubuntu, because i am ill.
[20:00] <jincreator> It really varies a lot! bdrung: Hope you get better soon.
[20:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/08/30/%23ubuntu-classroom.html
[20:00] <ScottK> Feel free to ping me on #ubuntu-motu if you have questions
[20:01] <JoseeAntonioR> ok guys, so this is the end of the session
[20:01] <bdrung> jincreator: thanks. i feel better today. no headache any more. yeah!
[20:01] <JoseeAntonioR> and also the end of the Ubuntu Developer Week for this cycle
[20:01] <JoseeAntonioR> I hope you all enjoyed the sessions, I should also thank all the instructors who volunteered for doing this, you've done a great job
[20:02] <JoseeAntonioR> we'll be having some Ubuntu on Air sessions and the Ubuntu OpenWeek soon, so stay tuned! again, thanks for being here :)
[20:02] <chilicuil> \o/, thanks a lot guys!
[20:03] <jsjgruber-x-p_> Thanks, all.
[20:04] <bdrung> if you still have questions, feel free to ping me on #ubuntu-devel, #ubuntu-motu, or #ubuntu-packaging