[10:31] hi [10:44] http://ubucon.de/2013 [11:02] lets go? === dpm is now known as dpm-laptop === 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 Open Week - Current Session: How to Contribute to the Ubuntu Touch Core Apps - Instructors: dpm [13:01] Logs for this session will be available at http://irclogs.ubuntu.com/2013/05/22/%23ubuntu-classroom.html following the conclusion of the session. [13:02] Hey all, and welcome to the second day of Ubuntu Open Week! [13:02] we'll wait for a minute for people to come in and then we can get started [13:04] ok, let's roll [13:04] For the late-comers, hi again and welcome to the second day of Ubuntu Open Week [13:05] My name is David Planella, and I work in the Community team at Canonical as Ubuntu App Development Liaison. [13:05] As such, my role involves coordinating and representing Ubuntu App Development, [13:05] grow our developer community and act as a liaison with app authors who target our platform. [13:06] Today I'm going to talk about the Ubuntu Touch Core Apps project, give an overview on what it is and how it works, [13:06] and most importantly, on how everyone can participate [13:06] If you've got any questions during the session, [13:06] feel free to ask them any time on the #ubuntu-classroom-chat channel [13:06] by prepending them with QUESTION: [13:07] I'll also leave some time at the end of the session for Q&A [13:07] So let's get started, shall we? ;-) [13:07] # The Core Apps Project [13:07] [13:07] After the Ubuntu Phone announcement, and as part of the phone platform we sent a call to our community [13:07] to participate in building the core set of apps that will ship with the phone. [13:08] With this, we started a really exciting project that provides a fantastic opportunity for community members [13:08] to create software that could run on millions of handsets! [13:08] We had an overwhelming response to our call for participation: nearly 2000 (!) individuals [13:08] expressed their interest in contributing to core apps. [13:09] From these replies, we formed dedicated development teams around each one of the apps, [13:09] set up the development infrastructure around Launchpad, [13:09] regular meetings to track progress [13:09] and the communication channels to discuss development. [13:10] These projects have been community-driven and run in the open from day one, [13:10] which has made collaboration much easier. [13:10] In essence, each team organizes their work and time in the way that works best for them, [13:10] and Canonical participates providing the following resources: [13:11] - Development infrastructure [13:11] - Engineering management [13:11] - Community mentorship and support [13:11] - Design guidance [13:11] (that should have probably been *mentoring, not even sure if mentorship exists ;) [13:12] One thing to make clear is that all apps in this project will have to be reviewed and comply [13:12] with the Ubuntu Touch quality expectations to be part of the default image. [13:12] That an app is part of the Core Apps project only guarantees [13:12] that it will be included if it complies with the quality standards. [13:13] Currently, already 4 of our initial list of 12 core apps has already been included in the Ubuntu Touch images. [13:13] Which is really good news [13:13] So kudos to the Calculator, Calendar, Clock and Weather teams! [13:13] ok, everything clear so far? Any questions? [13:15] coolbhavi asked: is the sdk fully functional and the code is available somewhere? [13:15] That's a really good question [13:15] The SDK is fully functional [13:16] and in fact it has already been used to create all of these apps [13:16] we don't consider it as feature complete yet though, which is why we still call it the SDK alpha [13:16] but the Beta is coming out in July [13:17] and the 1.0 together with Ubuntu 13.10 [13:17] the code is public and available on https://launchpad.net/ubuntu-ui-toolkit [13:17] ok, let's move on, then [13:18] [13:18] # Designing Core Apps [13:18] [13:18] At the same time, we kicked off an initiative to provide design suggestions for each one of the apps, [13:18] to provide guidance to the development teams [13:18] This was a very popular project too, with lots of exciting designs coming out of it. Check them out here: [13:18] https://ubuntu.mybalsamiq.com/projects/ubuntuphonecoreapps/grid [13:19] The Canonical Design team are also participating in this project, [13:19] and providing the direction for a subset of these core apps. [13:19] They communicate regularly with developers to discuss designs and feedback [13:19] from the teams and other contributors. [13:21] [13:21] # Which Core Apps? [13:21] [13:21] The core apps project currently comprises 12 applications, [13:21] but this list might change slightly as we're evaluating the best set of applications to be part of the launch. [13:21] You can see the list of core applications in Launchpad: [13:21] 1. Ubuntu Calculator App [13:22] 2. Ubuntu Calendar App [13:22] 3. Ubuntu Clock App [13:22] 4. Ubuntu Document Viewer App [13:22] 5. Ubuntu E-mail App [13:22] 6. Ubuntu Facebook App [13:22] 7. Ubuntu File Manager App [13:22] 8. Ubuntu Music App [13:22] 9. Ubuntu RSS Feed Reader App [13:22] 10. Ubuntu Terminal App [13:22] 11. Ubuntu Weather App [13:22] 12. Ubuntu Youtube App [13:23] As mentioned, these are managed and developed in Launchpad, our online collaboration tool: [13:23] https://launchpad.net/ubuntu-phone-coreapps [13:23] There you'll find the links to the code and other resources for each one of the apps [13:24] [13:24] # What are System Apps? [13:24] [13:24] In parallel to the Core Apps, [13:24] there is a set of applications that were developed [13:24] by dedicated teams of Canonical Engineers as part of the first public Ubuntu Touch demo. [13:25] They are currently also developed in the open, [13:25] and the way to contribute is similar to core apps in the sense that code can be submitted for review and the roadmap is discussed in public, [13:26] although they are run in a different way. [13:26] They are outside of the scope of this session, but you can see these system apps here: [13:26] https://translations.launchpad.net/ubuntu-touch-preview [13:27] These are apps such as the Camera, Gallery, Web browser, Notes, etc. [13:27] And if you have any questions about them, just ask on #ubuntu-touch or send an e-mail to ubuntu-phone@lists(at)launchpad(dot)net [13:27] ok, so it seems we've got some questions: [13:27] coolbhavi asked: is there any possibility that all the social network platforms are integrated in a single app? so that it can be accessible at one touch? [13:28] Yes. In fact, there is such an app already: Friends [13:28] The good things is that it is not only an app, but it also provides a reusable library for any app to access social networks [13:29] Check out https://blogs.gnome.org/kenvandine/2013/03/07/introducing-friends/ [13:29] The Facebook core app already uses the Friends library :) [13:30] sebbu asked: is there a list of formats that will be suported by the document viewer, or a way to make suggestions ? [13:30] You can check out the functional requirements for the doc viewer here: https://wiki.ubuntu.com/Touch/CoreApps/DocViewer [13:31] and suggest and contribute to the support of new formats in the mailing list: [13:31] https://launchpad.net/~ubuntu-touch-coreapps/+join [13:32] [13:32] # How to get started [13:32] [13:32] Ok, so now comes the interesting bit, [13:32] how can you contribute to Ubuntu being in millions of mobile devices! [13:32] As mentioned before, the project is run in a completely open manner, [13:33] so the way to contribute is not much different from the way other projects part of Ubuntu are run [13:33] [13:33] ## 1. Pick an app [13:33] [13:33] The first thing you'll need to do is to pick up a core app you'd like to work on [13:33] You can see the list here: [13:33] https://wiki.ubuntu.com/Touch/CoreApps [13:34] Just click on the link for your app of choice, [13:34] which will take you to a page with all of the app details, [13:34] and further links related to all of the app's resources, [13:35] such as Launchpad project, team, IRC channel, blueprints, etc. [13:35] This should give you a good overview about the app and how and where things are run [13:35] [13:35] ## 2. Decide how you want to contribute [13:35] [13:36] The main area for contribution in this project is development, [13:36] but there are also many other opportunities for participation: [13:36] - Bug reporting [13:36] - Testing [13:36] - Translations [13:36] - Design suggestions [13:37] - etc. [13:38] So it's up to you to decide the best use for your skills if you're interested in being part of the project, as you see, there's a broad range of areas to contribute to! [13:38] [13:38] ## 3. Get in touch [13:38] [13:38] Regardless of the way in which you choose to contribute, you should be aware and follow the communication channels for the project [13:39] The important thing when working within the community is to communicate in order to collaborate effectively [13:39] I'd first suggest to subscribe to the mailing lists: [13:40] 1) The Ubuntu Phone mailing list for general discussion on getting Ubuntu running on phones and other mobile devices: [13:40] https://launchpad.net/~ubuntu-phone/+join [13:41] 2) The Ubuntu App Cats mailing list for all discussion related to the core apps project: [13:41] https://launchpad.net/~ubuntu-touch-coreapps/+join [13:42] Also, each one of the development teams has got weekly meetings to discuss progress and solve any blockers [13:42] You can see an overview of all meetings here: [13:42] https://wiki.ubuntu.com/Touch/CoreApps/Meetings [13:43] There are IRC meetings and for some core apps video hangout meetings with the Design team [13:43] If you're interested in participating in the development of any of those apps, I'd recommend joining the meeting [13:44] asks: Can I see a detailed video overview anywhere with the latest updates and applications that already have? [13:45] Each one of the teams or other contributors generally blog about progress, including videos, on our Ubuntu App Developers Google+ community, so I'd recommend to join us to keep up to date too :) [13:45] https://plus.google.com/communities/111350780270925540549 [13:45] [13:45] ## 4. Development guide [13:46] [13:46] If you've decided to contribute with development, here's your next stop: the Core Apps Development Guide [13:46] [13:47] https://wiki.ubuntu.com/Touch/CoreApps/DevelopmentGuide [13:47] [13:47] This will help you get started with setting up the development environment and submitting your first contributions [13:48] It is fairly easy, and it will help you especially if you are new to collaborative development with Launchpad [13:48] The only requirements to get started is to have installed the Ubuntu SDK [13:49] and to sign the Contributor Agreement, which is needed because some carriers and manufacturers require specific license agreements [13:50] you'll see a more detailed explanation in the guide, but in summary, signing the agreement can be done really quickly with an online form and you retain the copyright of your contributions [13:51] There are 10 minutes remaining in the current session. [13:51] I think that pretty much summarizes everything I wanted to cover [13:52] For each app, the Launchpad project link should take you to other areas of contribution, such as Translations and Bugs [13:53] And finally, for testing those apps that are not yet on the image, you can do it easily either on a device or on your desktop! [13:53] All core apps run on the desktop as well [13:53] You can install them from this PPA: https://wiki.ubuntu.com/Touch/CoreApps/PPA [13:53] Phew, we're nearly at the end. Any questions? [13:54] sebbu asked: do they run natively on the desktop or do they need some kind of emulator ? [13:55] No emulation needed, apps will run natively on the desktop. You'll just need to install the SDK, which I believe is taken care of by the PPA packages [13:55] There are 5 minutes remaining in the current session. [13:56] In any case, here's how you can install the SDK: http://developer.ubuntu.com/get-started/gomobile/ [13:56] any other questions? [13:57] In that case, we'll wrap it up here [13:57] Thank you everyone for participating and for your questions. I hope you enjoyed the session and we can see your first contributions to core apps soon! :) [13:58] ok, seems we've got another question :) [13:58] sebbu asked: will the ppa only be available only for ubuntu, or for (some?) other distributions as well (debian, mandriva, fedora, etc...) ? [13:59] PPAs are a way to distribute development or testing packages that are not available in the Ubuntu archive [13:59] As such, PPAs are Ubuntu-specific [13:59] you could install the packages manually on Debian [14:00] but Fedora uses another packaging system [14:00] The SDK is also Ubuntu-specific atm [14:00] ok, I'll leave you in the good hands of my friend dholbach now! [14:00] Thanks dpm! :-) [14:00] Welcome everybody to the session about the Ubuntu Development team! === 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 Open Week - Current Session: Ubuntu Development Team - Instructors: dholbach [14:01] My name is Daniel Holbach, I work on the Ubuntu Community team along such nice people like dpm who you got to know earlier. :) [14:01] Logs for this session will be available at http://irclogs.ubuntu.com/2013/05/22/%23ubuntu-classroom.html following the conclusion of the session. [14:01] I love getting questions, so please ask whatever comes up in your mind - it'd be nice if it was loosely related to Ubuntu Development though. :) [14:01] and please prefix your questions with QUESTION: [14:02] So during the session I'll try to give you a broad overview over how the Ubuntu Development team works, so how Ubuntu the distribution, the operating system is put together. [14:03] Afterwards you won't be an Ubuntu developer (yet), but I hope you'll have at least heard of all the important moving parts and how they roughly fit together. [14:03] And again: ask! If I don't make sense or things are unclear or you're curious... ask. [14:03] Here we go. :) [14:03] Ubuntu is made up of thousands of different components, written in many different programming languages. Every component - be it a software library, a tool or a graphical application - is available as a source package. [14:03] Source packages in most cases consist of two parts: the actual source code and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. [14:03] Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install. [14:04] Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad’s build machines to be compiled. The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in /etc/apt/sources.list point to an archive or mirror. [14:04] Every day CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the CD. These CD images are then used for installation tests and provide the feedback for further release planning. [14:04] Does that make sense so far? Any questions? [14:05] All right, seems like we're good. [14:05] Ubuntu’s development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. With every freeze date that is reached developers are expected to make fewer, less intrusive changes [14:06] If you have a look at https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule you can see the release schedule for "saucy salamander" which is going to be Ubuntu 13.10. [14:06] Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented. The rest of the cycle is supposed to be focused on fixing bugs. [14:06] After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing. From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release. [14:07] SonikkuAmerica asked: I assume "CD image" is just a generic term for a Live image, as (at least) the desktop images don't fit on CDs anymore...? [14:07] SonikkuAmerica, Yes, that's correct - I should have said "image". Only saying "CD image" was never correct, as there always were DVD images as well, or images for netboot. Now we have images for tablets and phones as well. [14:08] Any more questions about images or the release process? [14:09] As you can see on https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule still in the "green" phase. This is where almost any change can still be uploaded. The more "red" you see down the line, the harder it will be to get risky changes included. [14:10] Ok, let's talk a bit about how the team communicates. [14:10] Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality. [14:10] At the beginning and during the release cycle we have the Ubuntu Developer Summits where developers and contributors come together to plan the features of the next releases. [14:11] Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on. This is all done in an open and transparent fashion, so you can participate and listen to a videocast, get involved, chat with attendants and subscribe to changes of specifications, so you are always up to date. [14:11] coolbhavi asked: with a 6 month release process, do you allocate sufficient time for testing packages and if so when? [14:11] coolbhavi, good one! [14:12] Yes. There are multiple ways in which put what we produce to the test. [14:13] There are many testing initiatives and Nicholas Skaggs gave a session about it yesterday, which you may want to go and check out: http://irclogs.ubuntu.com/2013/05/21/%23ubuntu-classroom.html#t16:01 [14:14] In short though: we do a lot of automated testing on the parts of Ubuntu we write, we also do a lot of manual testing (like image testing or specific apps), and use autopkgtest as well, which is interesting because tests are run for every upload of the package or when its dependencies change. [14:14] This gives us quite a good reassurance over when things might break. [14:15] Any more questions about testing or the communication bits I mentioned earlier? [14:15] If you are curious about what was discussed at the last UDS, you might want to check out http://summit.ubuntu.com/uds-1305/ which has links to all the sessions we held last week and what was discussed there. [14:15] Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public. [14:16] Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad. [14:16] All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload. === a is now known as Guest85082 [14:17] Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu. [14:17] These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it. The relationship to Upstreams is critically important to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions). [14:19] The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there. [14:19] Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness. [14:19] Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there. [14:20] coolbhavi asked: I read about syncing from upstream and merging from upstream. Whats the difference? [14:20] coolbhavi, I wanted to get to that in just a minute. :-) [14:20] But I can give a very quick answer here already. [14:21] Essentially we try to work together with Upstream projects, but sometimes, for example due to different timescales or needs, we might go ahead with adding a change in Ubuntu before it's included Upstream - sometimes we also need to do it to integrate the software better into Ubuntu. [14:22] In those cases we have a "delta" over Upstream. We deviated slightly. [14:22] So whenever source code changes in Debian, we will have to make sure that our changes are merged in a more recent version again. [14:23] "Merging" in terms of Ubuntu package maintenance means: "take new source code from Debian and integrate our changes". [14:23] "Syncing" means that the changes can either be dropped or are accepted in Debian as well, so our Ubuntu-local version of the package can be overwritten. [14:23] nik90 asked: If one wants to be a maintainer of a package in Ubuntu, is it required to run the latest Ubuntu version? [14:23] nik90, good one! [14:24] Yes, it's a good idea to run the latest development release - and if only in a virtual machine or a separate partition or something. [14:24] It's necessary, so you can test the build and test the package in the version your users are going to use it. [14:24] Otherwise it's very easy to "just upload" a change and never know if it actually worked the way you intended. [14:25] Or let's say you upload your app, but in the latest release some library it depends on changed and it crashes or behaves differently. [14:26] https://wiki.ubuntu.com/UsingDevelopmentReleases explains how to set up a development release in a sane and safe way. [14:26] ... although it has become much much much more stable than in the past. [14:26] In the last 3-4 releases, you could run the development release very early already and it was rock-solid. [14:27] nik90 asked: Are members of the Ubuntu Development Team involved in the coding of features or just making sure that the package is up to date with upstream? [14:27] nik90, there are both [14:27] There are many who work on dedicated parts of the system, depending on their interests, but there are generalists as well, who enjoy maintaining packages and keeping large parts of the archive in shape. [14:28] We have need for all of them. :-) [14:28] fr33r1d3 asked: Is 13.10 "stable" already? [14:29] fr33r1d3, considering that "saucy" is still only 3 weeks old, I expect a few more turbulences in its early days. I currently run it in a VM only - but everything I tested there worked just fine for me. :) [14:30] nik90 asked: which irc room do you recommend me to join if I have more questions regarding testing and packaging apps? Or are there any other way to get help? [14:30] nik90, Definitely #ubuntu-motu. There are many many friendly folks in there who are happy to help out. [14:30] I'm going to give a few links by the end of the session which should help you get started. [14:30] Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream is interested in working on a new big feature while Ubuntu, because of the tight release schedule, is interested in shipping a solid version with just an additional bug fix. [14:30] That is why we make use of “Distributed Development”, where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion. [14:32] So as I said in my explanation to coolbhavi earlier, sometimes you have cases where an Upstream ships an 1.0 version of an app, you add an additional bug fix, Upstream in the meantime works on 1.1, which adds a lot of crazy new features, but if it's too late in our release cycle, 1.1 will have to wait for the next Ubuntu release. [14:33] That's sometimes a hard decision to make, particularly if you have angry users who want "the latest and greatest", but it's often a good idea in terms of stability. [14:34] coolbhavi asked: I have already made a first upload.. is there anyone i can reach out for further help in the process? [14:34] coolbhavi, I wanted to mention a few links towards the end of the session about this, but yeah - there is! :) [14:35] The MOTU team is definitely the way to go. #ubuntu-motu and ubuntu-motu@lists.ubuntu.com is a good place for you to get advice and help. [14:35] There's also the Developer Advisory Team, who will reach out to you during your development journey at some stage - they can also be of help. [14:36] To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. [14:36] After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu. [14:36] These code reviews are nothing to be afraid of. The people you work with here are friendly and won't shout at you for making mistakes. [14:37] Not everything is in our documentation (it'd be huge and indigestible otherwise), but you'll learn a lot about conventions and the common tricks in code reviews. [14:37] That's how you slowly grow into the team. [14:37] Abunujum asked: I'm currently learning how to make web apps, And i would like to publish some for the Software Center, but how can I package them? [14:38] Abunujum, I'll give some links to documentation later on. https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages is a page specifically about getting totally new packages into Ubuntu. [14:38] When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort. [14:39] So you can see: it's a bit of detective work and it's a lot of team work - which makes the whole experience very interesting and you'll get to know many people. [14:39] When you fix bugs additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream. [14:40] Any more questions? :) [14:41] The most important requirements for success in Ubuntu development are: having a knack for “making things work again,” not being afraid to read documentation and ask questions, being a team player and enjoying some detective work. [14:41] You don't need to know every programming language on the planet. We have quite a number of simple bugs which are simple enough to understand and resolve. [14:41] And as I said earlier: Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. [14:41] You're not on your own. [14:41] You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software. [14:42] Abunujum asked: What programming language do recommend to use to make ubuntu software? [14:43] Abunujum: that entirely depends on what you want to achieve. [14:43] For example if you work on some low-level or hardware-related pieces of Ubuntu, you will very likely have to use C or C++ [14:44] Many applications in Ubuntu are written in Python though and with Ubuntu Touch and the Ubuntu SDK coming up, it got very interesting to use QML. [14:44] If you work on existing packages and fix bugs there, you are very likely going to use whatever the software itself was written in. [14:45] This is a very interesting learning experience, as you dive into existing code, try to find the issue, read some documentation and hopefully get to the point where you fix the bug. :) [14:45] I personally learnt a lot this way. [14:45] fr33r1d3 asked: Describe QML in short... [14:45] QML is the Qt Meta Language or Qt Modeling Language. [14:46] It allows you to write apps in which you write in a declarative way how the app should look like or how it should behave. [14:46] So modelling the UI becomes very easy and you don't need to worry about writing a lot of actual code. [14:47] When you get to the point where you define the actual logic of your app you can then very easily tie in JavaScript, or any other language, like C++ or Python. [14:47] Abunujum asked: I would also like to know, Is it possible to develop ubuntu touch applications using python [14:48] Yes, it is. Although you might want to do some investigation in the beginning to find out if using Python won't have a negative impact in terms of startup time or memory consumption. The people in the #ubuntu-touch channel should be able to give you a good idea. It will also depend on what exactly you want to achieve. [14:48] fr33r1d3 asked: I read at the UDS that they want to start tell people to not use Quickly anymore.. Is it safe to still use it or? [14:49] fr33r1d3, Yes, it's still safe to use it. If you start a fresh project, you might want to investigate though if the Ubuntu SDK with Qt Creator doesn't give you a better experience. [14:50] Oh and coming back to the earlier question about QML and how to use it - http://developer.ubuntu.com/get-started/gomobile/ has a really nice tutorial for getting started. [14:50] It should also show you the beauty of how easily apps can be written. [14:50] There are 10 minutes remaining in the current session. [14:51] So to re-cap a bit on what I said earlier... if you're interested on working on Ubuntu itself and making it work great - be sure to check out and bookmark http://developer.ubuntu.com/packaging/ [14:51] the title of the webpage is a bit misleading - it's not only about packaging, but it's more about developing Ubuntu itself [14:52] you'll learn about packaging, about our release processes, about how our infrastructure works and everything else [14:52] the guide is currently available in English, Spanish, Russian and Brazilian Portuguese [14:52] We are also always looking for people who can help us translating it. https://translations.launchpad.net/ubuntu-packaging-guide/ should make that very easy. [14:53] So if you speak a language other than English, try to help out a little bit - many upcoming developers will appreciate it. [14:54] Any more questions? [14:55] There are 5 minutes remaining in the current session. [14:56] So to illustrate, that we have simple bugs which can be fixed, you can take a look at https://code.launchpad.net/~fourdollars/software-properties/fix-1138121-a-typo-in-CountryInformation.py/+merge/151870 for example. [14:57] Down at the bottom you can see the "diff". [14:57] The green lines indicate lines which were added, red lines indicate code which was removed. [14:58] So apart from the bits in debian/changelog, there's only one line which changed, essentially "common-name" was changed to "common_name". This fixed a bug in Ubuntu. :) [14:58] Sometimes it takes a little bit to get there and find out what exactly it's broken. [14:58] Still, it's worth it - you're going to make millions of Ubuntu users happier. :) [14:58] So go and bookmark http://developer.ubuntu.com/packaging/ and you won't be disappointed on the journey. :) [14:59] Thanks a lot everyone for your questions! [14:59] Next up is jsalisbury who is going to give you an introduction to the Ubuntu Kernel Team! [14:59] dholbach, o/ [15:00] Hi All, My name is Joe Salisbury, I am the kernel defect analyst for the Kernel Team at Canonical [15:00] Today, I'll be talking about kernel bug triage, the different Importance and Status fields for a bug and some typical debugging tasks commonly requested when triaging a bug. === 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 Open Week - Current Session: Ubuntu Kernel Team - Instructors: jsalisbury [15:01] * jsalisbury thanks the bot [15:01] Logs for this session will be available at http://irclogs.ubuntu.com/2013/05/22/%23ubuntu-classroom.html following the conclusion of the session. [15:01] Questions should be asked on the #ubuntu-classroom-chat channel. If you want to ask a question, write it there, and precede it with 'QUESTION:'. For example: [15:01] QUESTION: What is an Upstream kernel? [15:02] First, for details about the Ubuntu kernel, the top level Kernel wiki page can be found at: [15:02] https://wiki.ubuntu.com/Kernel [15:02] There is also a page dedicated to kernel bug triage, which can be found at: [15:02] https://wiki.ubuntu.com/Kernel/BugTriage [15:03] The kernel bug triage page is a great place to start if interested in learning more about triaging kernel bugs. [15:04] Bug triage is a great place to start to learn about the kernel. [15:04] Triaging kernel bugs provides a way to learn about a variety of kernel sub systems [15:05] The Ubuntu Linux Kernel has quite a large number for bugs opened against it. Close to 5000 as of today. A full list of bugs can be seen at: [15:05] https://bugs.launchpad.net/ubuntu/+source/linux [15:05] I generally focus on triaging and escalating bugs opened against the current development kernel, which is currently Saucy. [15:05] That's not to say there is no focus on the stable kernels. === dpm-laptop is now known as dpm [15:06] Each and every kernel bug reported should be triaged, which could be against the current development kernel or any of the prior supported stable kernels. [15:08] The priority with the development kernel is to identify bugs and hit them hard and fast, so we can fix as many issues as possible, before release. [15:08] On the other hand, stable kernel bugs can take longer to fix. This is because a patch for a bug must go through the Stable Release Update process: [15:08] https://wiki.ubuntu.com/KernelTeam/StableHandbook/StableProcess [15:09] Details on stable kernels can be found here: [15:09] https://wiki.ubuntu.com/Kernel/Handbook/Stable [15:09] To assist with the large number of kernel bugs reported, the kernel team has developed bug 'Bots' to review each new bug, and ensure all the required apport logs are attached. [15:10] If all the information is there the bug Status is changed from 'New' to 'Confirmed'. If the bug is missing the apport logs, the bug Status is set to 'Incomplete' and a request for the logs is posted to the bug. [15:10] After the bot sets the bug to 'Confirmed', the bug is reviewed. Based on the bug description, I will see if the bug is similar to recent bugs and may be a duplicate. [15:11] I will also determine what kernel subsystem the bug affects. The bug might be specific to USB, wifi, graphics, suspend/resume, etc. [15:12] I will ask subsystem specific questions to collect that specific data. [15:12] The following wiki has some pages on specific debugging by subsystem: [15:12] https://wiki.ubuntu.com/Kernel/Debugging [15:13] Once a bug has all the needed information, I will usually ask that the latest Mainline kernel is tested and then set the bug to Incomplete, until the testing is done. The latest Mainline kernel is the kernel that is currently being developed upstream, and is considered Linus' tree. [15:14] The reason for testing this kernel is to see if the bug is already fixed upstream. If it is, usually the current Ubuntu devlelopmt kernel will get this fix when it is rebased to the latest Mainline kernel. [15:15] Testing the Mainline kernel will also tell us if the bug exists upstream. If the bug does exist upstream, we like to ask the Bug Reporter to open a bug with upstream, so the issue is known to the upstream Developers as well. [15:16] Nova__ asked: How we can contribute to Kernel team ? [15:16] sebbu asked: if there is so many bugs, does that means that it doesn't work well ? [15:16] There is a wiki that describes how to report a bug upstream here: [15:16] https://wiki.ubuntu.com/Bugs/Upstream/kernel [15:17] We also ask for testing of the Mainline kernel when a bug is reported against a stable kernel. For the same reason it will tell us if the bug is already fixed. [15:17] However, just because a bug is fixed upstream, doesn't mean a stable kernel will ever get that fix. [15:18] Depending on the bug, we may also ask for testing of the latest upstream stable kernel. [15:18] For example, Precise is based on the 3.2 kernel. Currently Precise has all the upstream updates up to 3.2.39 [15:18] However, the latest upstream 3.2 stable kernel is 3.2.45. Eventually Precise will get the 3.2.45 updates, so it is beneficial to know if the bug is already fixed there. [15:19] If it is, we usually just need to wait until the bug is fixed when the release gets those upstream updates. [15:20] As mentioned earlier, there may be a case when a bug is fixed in Mainline, but is not fixed in the latest upstream stable kernel for a release. [15:20] niagr asked: How can we learn about the working of the kernel? [15:21] niagr, The best way is to review some of the kernel wiki pages. [15:21] niagr, the top level Ubuntu kernel wiki page is at: [15:21] https://wiki.ubuntu.com/Kernel [15:22] niagr, there are topics on bug triage, like I'm talking about now, testing, and kernel development as well [15:22] niagr, there are many other resources around the Internet as well. [15:24] So there may be a case when a bug is fixed in Mainline, but is not fixed in the latest upstream stable kernel for a release. [15:24] This can happen when a patch is submitted upstream, but does not include the Cc to the upstream stable kernel. [15:24] If this is the case, I will perform what is called a "Reverse" kernel bisect. This debugging process is used to identify a patch upstream that fixes a specific bug. [15:25] Before going down the debugging of a specific type of bug, lets step back to the bug triage flow. [15:25] First a bot checks for the apport logs, then the bug is reviewed and a request is made to test the latest Mainline kernel. [15:26] The next thing we need to know is if this bug is a regression or not. [15:26] It a bug is not a regression, it has all the apport logs, and testing of the Mainline kernel does not fix the bug, the bug status is set to "Triaged". [15:27] If the bug is a regression, we can perform a kernel bisect to identify the commit that introduced the bug. [15:27] The steps to perform a bisect can be found at: [15:27] https://wiki.ubuntu.com/Kernel/KernelBisection [15:28] The entire details of a kernel bisect can take some time, so it may be best for another session at some point. But I'll give a summary. [15:29] Basically we first need to identify the last kernel version that did not have the bug and the first kernel version that did have the bug. [15:30] Once we have these two versions, We provide these two version numbers into git bisect. Git then tells us a kernel commit that is about halfway between these two versions. [15:30] Using this information, I build a test kernel up to this commit and ask the bug reporter to test it. [15:31] Based on the test results, I tell git whether or not the kernel exhibited the bug. [15:32] Git will then spit out the next commit id(SHA1), which is again half way in between the last good and first bad commit. [15:32] I then build another test kernel, ask for it to be tested, and feed the result back into git. [15:33] Eventually this process will yield the SHA1 of the patch that introduced the regression. [15:34] Then next step is determined after reviewing the details of the patch that introduced the regression. [15:35] The bug can be fixed by creating a new patch. The patch that introduced the regression can be reverted and/or upstream will be contacted to get it fixed upstream as well. [15:36] Like I mentioned earlier there is also a "Reverse" bisect. A reverse bisect is used to identify a commit that fixes a bug. [15:37] This is basically the same process as a standard bisect, but git is told the opposite of the testing results. === Quintasan_ is now known as Quintasan [15:38] Eventually though the same process, git will report the SHA1 of the patch that fixes the bug. [15:38] Depending on the patch, the fix will then be cherry-picked or backported and an SRU request submitted. [15:39] Where or not a bisect or reverse bisect is performed, depends on the bug. [15:40] Usually the priority of the bug and/or the number of people affected will decide. [15:41]