[06:44] <huxley_spark> exit
[10:39] <abhitri> ##kernel
[11:09] <sebsebseb> hi
[13:56] <dholbach> Hello everybody! If I read the clock correctly, we'll start in 5 minutes - now is a good time to tweet/dent/etc. and invite your friends to the event. :-)
[14:00] <dholbach> Welcome everybody to day two of Ubuntu Open Week! We still have a lot of great stuff lined up for the week, have a look at the schedule at https://wiki.ubuntu.com/UbuntuOpenWeek - after my double session there'll be one session about Ubuntu Friendly and one about Brainstorm Ubuntu - awesome!
[14:00] <dholbach> I'd like to invite you to ask as many questions as you have, this will make the session much move lively and interesting
[14:00] <dholbach> for that, please join #ubuntu-classroom-chat and ask your questions in there
[14:01] <dholbach> please prefix them with QUESTION:
[14:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session.
[14:01] <dholbach> luckily with the help of the Ubuntu Packaging Guide team I have a lot of the content already prepared, so you will spend less time waiting for me to have typed everything
[14:01] <dholbach> and we have more time for questions
[14:02] <dholbach> if anything's unclear or weird or doesn't make sense, please ask :)
[14:02] <jcastro> woo, welcome back everyone!
[14:02] <dholbach> jcastro, want to say a few words?
[14:03] <dholbach> hum, I guess I'll get started then :)
[14:03] <jcastro> nope, just take it away!
[14:04] <dholbach> ok, so in the double session today, I'd like to introduce you to the world of Ubuntu development, so explain what the big moving parts are, how we work and which other actors are involved
[14:04] <dholbach> you won't be a pro after this, but I hope you'll at least have heard of the most important things afterwards :-)
[14:04] <dholbach> in the second part, I'll help you get your development environment set up and maybe we even have time to have a look at trying to fix a bug
[14:05] <dholbach> 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:05] <dholbach> 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:05] <dholbach> Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install.
[14:06] <dholbach> 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.
[14:06] <dholbach> he URLs in /etc/apt/sources.list point to an archive or mirror. 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:07] <dholbach> Sorry... I meant to say "The URLs in /etc/apt/sources.list ..."
[14:07] <dholbach> So far so good? Any first questions already?
[14:08] <dholbach> Ok, let's talk a bit about the release cycle then... please have a look at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[14:08] <dholbach> it's a draft of the release schedule of the 12.04 cycle
[14:09] <dholbach> Ubuntu’s development is very much dependent on the current stage of the release cycle.
[14:09] <dholbach> 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:09] <dholbach> 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.
[14:09] <dholbach> The rest of the cycle is supposed to be focused on fixing bugs. 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.
[14:10] <dholbach> 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.
 QUESTION Is it possible for non programmers to develop?
[14:10] <dholbach> tcarrondo, great question - thanks
[14:11] <dholbach> the answer is: you can easily start your journey as an Ubuntu developer without a huge background in programming, but you need a few skills still
[14:12] <dholbach> what I personally feel is important for a new contributor to development is: having a knack for making things work again, patience, no fear of documentation, being a good team player and not being afraid of asking a few questions
[14:13] <dholbach> it obviously helps if you have spent years programming, but it's not a strict prerequisite - through some dedication and an interest in the area, you will learn quickly enough
[14:13] <dholbach> the great thing about Ubuntu is: the code is open, getting the code and learning from making small changes to it is quite natural
[14:13] <dholbach> ... if you have the skills/interests I mentioned above :)
[14:14] <ClassBot> navneeth asked: ​ dholbach: What's the difference between Feature Def. freeze and Feature freeze?
[14:14] <dholbach> another great question, thanks navneeth
[14:15] <dholbach> navneeth, I'll go into a bit more detail in a bit, the short answer is: the features and big changes are discussed and defined during the first phase of the development cycle (at Ubuntu Developer Summit)
[14:15] <dholbach> so that's where a lot of people come together, discuss, make plans (at UDS) and write up specifications (after UDS)
[14:16] <dholbach> at Feature Definition Freeze we expect the plan to be established
[14:16] <dholbach> any more questions about the release cycle and the general introduction?
[14:16] <dholbach> ok, let's talk about UDS and generall communication/coordination then
[14:16] <dholbach> 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:17] <dholbach> At the beginning of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases. 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.
[14:17] <ClassBot> korky2 asked: What is UDS?
[14:17] <dholbach> korky2, it's the Ubuntu Developer Summit
[14:17] <dholbach> This is all done in an open and transparent fashion, so even if you can not attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date.
[14:18] <dholbach> 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.
[14:18] <dholbach> 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:19] <dholbach> 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. 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.
[14:19] <dholbach> so far so good?
[14:20] <dholbach> let's talk about the projects around Ubuntu then
[14:20] <dholbach> 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. These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it.
[14:21] <dholbach> 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:23] <dholbach> Obviously a lot of developers are part of more than one project. so there's Ubuntu developers, who have a deep interest in some other project and they actively participate in there, make sure that communication channels work between both of them and contribute code there.
[14:23] <dholbach> Being an "ambassador" between projects is a great contribution to the Open Source world in its own.
[14:24] <dholbach> 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:24] <dholbach> 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:25] <dholbach> What this means in practise is that Debian and Ubuntu are both distributions, both having similar, but sometimes divergent goals and release cycles, so some coordination is necessary.
[14:26] <dholbach> If you remember the release cycle I mentioned above, you saw how 12.04 will have freeze dates a lot earlier than usual.
[14:26] <dholbach> This is because 12.04 will be an LTS (Long Term Support) release, so developers who make a decision which code to import from Debian have to do this a lot more carefully.
[14:27] <dholbach> ie: back off from importing a crazy new unstable piece of code and stay with the stable one, or if they decide to bring it in, then make sure it lands early in the cycle
[14:27] <dholbach> so we have the time to test and fix or roll back if necessary
[14:28] <dholbach> next I'd like to talk a bit about how you can get changed into Ubuntu, because that's probably what you all are most interested in :)
[14:28] <dholbach> 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:29] <dholbach> 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:29] <dholbach> 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:30] <dholbach> In practise finding the fix is probably the hardest bit in there, but the process around getting the fix reviewed and everything is quite simple - I'll sort-of-demo this in the second part.
[14:30] <dholbach> 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:30] <dholbach> Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream.
[14:31] <dholbach> This was a huge amount of information now - you must have questions! Or do you all feel you know enough to get rocking and rolling already?
[14:32] <dholbach> Ok, you look like you're all much cleverer than I was, when I started getting involved! Great! :-)
[14:33] <dholbach> As I mentioned earlier: 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 might be interested in working on a new big feature while Ubuntu, because of the tight release schedule, might be interested in shipping a solid version with just an additional bug fix.
[14:34] <dholbach> 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.
 are most bugs located in the "upstream" package or does the packaging process induce bugs?
[14:34] <dholbach> mblank, fantastic question
[14:34] <dholbach> Most bugs are upstream bugs.
[14:35] <dholbach> Which is why Launchpad has this great feature of tracking bugs in other bug trackers.
[14:35] <dholbach> So for example I find a but in gedit, and it's bug number X in Launchpad, we identify that it's a bug in the upstream code, so we forward it with all relevant information to the gnome bugzilla, there it has bug number Y.
[14:36] <dholbach> Launchpad can let us know when the bug status upstream changes, so for example if they need more info or when they fixed the bug.
[14:36] <dholbach> Launchpad can also sync bug comments, so you always have all info in one place, which make collaboration a lot easier
[14:37] <dholbach> Good examples for bugs in the packaging are: wrong or missing dependencies, missing/wrong build options or bugs in patches needed to integrate the package better
[14:37] <dholbach> (there's very likely loads more... :-))
[14:37] <ClassBot> jamdatadude asked: ​ so how does one make sure to get the information proper for both ubuntu and the upstream?
[14:38] <dholbach> It depends what you mean by information: if you want to forward a bug report for example, you want to make sure that the bug is not already fixed in a newer version of the software, or that it's not because of a patch we applied
[14:38] <dholbach> also you want to include a test-case and the exact circumstances when the bug happens
[14:39] <ClassBot> ikt asked: will there be greater intergration with lp and upstream? At the moment most bug reports go against packages listed in launchpad, but wouldn't it make more sense to have apport report the bug directly against the upstreams bug tracker? no sense in making the same bug report twice?
[14:40] <dholbach> ikt, there are some upstream maintainers who want to know about every Ubuntu bug, they subscribe to the package in Launchpad and they deal with feedback there
[14:40] <dholbach> for some upstreams with big projects that get lots of bug reports this option is not feasible
[14:40] <dholbach> they rely on us to make sure that all the information is collected and that it's clearly identified that it's an issue they need to fix
[14:41] <dholbach> also do we use the bug reports in Launchpad for our own communication
[14:41] <dholbach> let's say there's an important crasher bug in gedit - gedit is a very important package: we can't have the text editor crash by the end of release
[14:42] <dholbach> which is why we target the bug report to a milestone in Ubuntu, so the people who care about the desktop, also the release team know what we still need to fix
[14:42] <dholbach> any more questions?
[14:42] <dholbach> if not, I'll crack on and talk a little bit about Distributed Development
[14:43] <dholbach> please have a look at http://developer.ubuntu.com/packaging/html/_images/cycle-branching.png
[14:43] <dholbach> In this example it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins.
[14:44] <dholbach> You can imagine the different code branches as streams of changes, as a developer you often have to make a decision, which of these you are willing to integrate at the current time of the release cycle.
[14:45] <dholbach> In any case you want to make sure that eventual divergences are merged back.
[14:45] <dholbach> Not merging them means having to maintain your changes in your own branch for the time, which can become quite expensive.
[14:46] <dholbach> To sum this up and to reiterate what I said earlier: 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:47] <dholbach> Good places to ask your questions are ubuntu-motu-mentors@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. 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:47] <dholbach> This is part 1 of what I wanted to talk about - are there general question you still have?
[14:49] <dholbach> alright - let's get cracking and let's set up our development environment together :-D
[14:49] <dholbach> There are a number of things you need to do to get started developing for Ubuntu. This article is designed to get your computer set up so that you can start working with packages, and upload your packages to Ubuntu’s hosting platform, Launchpad.
[14:49] <dholbach> oops, replace "this article" with "this session" :-D
[14:50] <dholbach> over-eager copy and pasting I'd call this :)
[14:50] <ClassBot> mblank_ asked: you copy the upstream SW at some point in time and then work with this copy until the next ubuntu releas?
[14:50] <dholbach> mblank, nice question
[14:50] <dholbach> essentially yes
[14:50] <dholbach> if you go back to the wiki page with the release schedule you can see Debian Import Freeze
[14:51] <dholbach> and Feature Freeze
[14:51] <dholbach> at DIF we basically stop the semi-automatic import of source packages from Debian
[14:51] <ClassBot> There are 10 minutes remaining in the current session.
[14:51] <dholbach> at Feature Freeze we expect new upstream versions to just fix bugs or we ask to file a freeze exception with the release team
[14:51] <ClassBot> Armin asked: My biggest problem is where to start from, find a bug and fix it is not so easy as it sounds. Do you have any tips on this?
[14:52] <dholbach> Armin, yes, a good question - I'll go into a bit more detail about this later on
[14:52] <dholbach> generally it depends what you want to work on
[14:52] <dholbach> if you are interested in a specific piece of software or a set of packages (based on their functionality or programming language), it's easy to spot these and get cracking on bugs, etc
[14:53] <dholbach> if you don't know yet, it's a bit harder
[14:53] <dholbach> for the beginners I'd recommend to start working on a really small, really isolate bug
[14:53] <dholbach> such as a typo, or a bug that was tagged as 'bitesize'
[14:54] <dholbach> so you have something easy to immediately spot, fix, build, test and get uploaded
[14:54] <dholbach> alright, let's crack on with our development environment
[14:54] <dholbach> We'll cover:
[14:54] <dholbach> Installing packaging-related software. This includes:
[14:55] <dholbach>     Ubuntu-specific packaging utilities
[14:55] <dholbach>     Encryption software so your work can be verified as being done by you
[14:55] <dholbach>     Additional encryption software so you can securely transfer files
[14:55] <dholbach> Creating and configuring your account on Launchpad
[14:55] <dholbach> Setting up your development environment to help you do local builds of packages, interact with other developers, and propose your changes on Launchpad.
[14:55] <ClassBot> There are 5 minutes remaining in the current session.
[14:56] <dholbach> It is advisable to do packaging work using the current development version of Ubuntu. Doing so will allow you to test changes in the same environment where those changes will actually be applied and used.
[14:56] <dholbach> Don’t worry though, the Ubuntu development release wiki page shows a variety of ways to safely use the development release: https://wiki.ubuntu.com/UsingDevelopmentReleases
[14:56] <dholbach> for now, if you run oneiric or some other release, that's totally fine - you can always just retrace the steps of this session if you install the "precise" development release in a vm later on
[14:57] <dholbach> There are a number of tools that will make your life as an Ubuntu developer much easier. You will encounter these tools later in this guide. To install most of the tools you will need run this command:
[14:57] <dholbach>   sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file
[14:58] <dholbach> If you run oneiric (11.10) (or if you have Backports enabled on a currently supported release), the following command will install the above and other tools which are quite common in Ubuntu development:
[14:58] <dholbach>   sudo apt-get install packaging-dev
[14:58] <dholbach> This command will install the following software:
[14:58] <dholbach> gnupg – GNU Privacy Guard contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad.
[14:58] <dholbach> pbuilder – a tool to do a reproducible builds of a package in a clean and isolated environment.
[14:58] <dholbach> ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier.
[14:58] <dholbach> bzr-builddeb (and bzr, a dependency) – distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work.
[14:58] <dholbach> apt-file provides an easy way to find the binary package that contains a given file.
[14:59] <dholbach> apt-cache (part of the apt package) provides even more information about packages on Ubuntu.
[14:59] <dholbach> I know this will, depending on your bandwidth, take a bit of time. So let's have some questions!
[15:00] <ClassBot> cdunlap asked: When I set up my environment, do i need to add the deb-src for precise?  if so, where do I find that info
[15:00] <dholbach> cdunlap, nice one!
[15:00] <dholbach> No, for now it's not necessary.
[15:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <dholbach> but if you want to use 'precise' in a safe manner afterwards for your development, check this out and bookmark it: https://wiki.ubuntu.com/UsingDevelopmentReleases
[15:01] <dholbach> it will show you ways to do this safely, so for example by using a virtual machine, setting up a chroot or other means
[15:02] <dholbach> immediately upgrading to 'precise' is only for folks who have no problem with dealing daily new pain
[15:02] <dholbach> 'precise' was just opened as a development release a day or two ago, so there's still lots of moving bits and pieces that will break :)
[15:02] <dholbach> ok... packages installed? everybody all set?
[15:03] <dholbach> awesome
[15:03] <dholbach> First of all, we'll create our GPG key.
[15:03] <dholbach> If you did that already, you can just lay back and do nothing. :-)
[15:03] <dholbach> GPG stands for GNU Privacy Guard and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package.
[15:04] <dholbach> To generate a new GPG key, run:
[15:04] <dholbach>   gpg --gen-key
[15:04] <dholbach> GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure.
[15:04] <dholbach> Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say “0”, which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary.
[15:04] <dholbach> Then you will have to set a passphrase, choose a safe one (a passphrase is just a password which is allowed to include spaces).
[15:05] <dholbach> Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine. Move the cursor around, type some paragraphs of random text, load some web page, etc.
[15:06] <dholbach> Please speak up, if we're going too fast or if I don't make sense, OK? I hope you're all just quiet because you're busy setting up your key. :-)
[15:06] <ClassBot> mblank_ asked: I already have a PGP Key in Launchpad, do I need a new one for development participation?
[15:06] <dholbach> mblank, no, if you do, and have it already in LP, you're all set
[15:06] <ClassBot> Atamisk asked: Is there a way to migrate one PGP key from system to system?
[15:07] <dholbach> Atamisk, yes, fortunately
[15:07] <dholbach> and as a bonus, it's very simple: just copy over the whole ~/.gnupg/ directory :)
[15:07] <dholbach> done
[15:07] <dholbach> you might still have to hook up your key with your email client or wherever you make use of it, but that should be it
[15:08] <dholbach> ok, let's crack on and set up our SSH key
[15:08] <dholbach> again: if you have an SSH key already, no need to bother, just relax and lay back :)
[15:08] <ClassBot> jamdatadude asked: ​ Can we use Ubuntu one to sync that .gnupg directory?
[15:09] <dholbach> jamdatadude, you can, but I personally would be a bit reluctant - please note that this directory contains also your private key, so the very bit which through the act of signing or encrypting proves to others that you are you
[15:10] <dholbach> I'm sure the Ubuntu One engineers made the experience as safe as they could, still this is nothing I personally would give out of my hands :)
[15:10] <dholbach> ok, SSH key
[15:10] <dholbach> SSH stands for Secure Shell, and it is a protocol that allows you to exchange data in a secure way over a network. It is common to use SSH to access and open a shell on another computer, and to use it to securely transfer files. For our purposes, we will mainly be using SSH to securely upload source packages to Launchpad.
[15:10] <dholbach> To generate an SSH key, enter:
[15:10] <dholbach>   ssh-keygen -t rsa
[15:10] <dholbach> The default file name usually makes sense, so you can just leave it as it is. For security purposes, it is highly recommended that you use a passphrase.
[15:10] <dholbach> (If your GPG key is not created yet, just open another terminal.)
[15:11] <ClassBot> hannie asked: Is an openPGP key the same as a PGP key?
[15:12] <dholbach> gpg (GNU Privacy Guard) implements the OpenPGP standard
[15:12] <dholbach> I suggest you have a look at http://gnupg.org/ which discusses this in detail
[15:13] <dholbach> ok, let's crack on, because this is another piece of software which will take a bit longer to get set up
[15:13] <dholbach> Set up pbuilder!
[15:13] <dholbach> pbuilder allows you to build packages locally on your machine. It serves a couple of purposes:
[15:13] <dholbach>  - The build will be done in a minimal and clean environment. This helps you make sure your builds succeed in a reproducible way, but without modifying your local system
[15:13] <dholbach>  - There is no need to install all necessary build dependencies locally
[15:13] <dholbach>  - You can set up multiple instances for various Ubuntu and Debian releases
[15:13] <dholbach> Setting pbuilder up is very easy, run:
[15:13] <dholbach>   pbuilder-dist <release> create
[15:14] <dholbach> where <release> is for example precise, oneiric, natty, maverick, lucid or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though.
[15:14] <dholbach> Again: while this runs, just open another terminal.
[15:15] <dholbach> The next thing we'll do is: tell a few tools a bit about who we are.
[15:16] <dholbach> First, we'll configure Bazaar
[15:16] <dholbach> Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently. It is used for the new Ubuntu Distributed Development method of working with Ubuntu packages.
[15:16] <dholbach> To tell Bazaar who you are, simply run:
[15:16] <dholbach>   bzr whoami "Bob Dobbs <subgenius@example.com>"
[15:16] <dholbach>   bzr launchpad-login subgenius
[15:17] <dholbach> You get bonus points for using your real name and not Bob Dobbs!
[15:17] <dholbach> whoami will tell Bazaar which name and email address it should use for your commit messages. With launchpad-login you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you.
[15:17] <dholbach> Note: If you can not remember the ID, go to https://launchpad.net/~ and see where it redirects you. The part after the “~” in the URL is your Launchpad ID.)
[15:18] <dholbach> And as a last step:
[15:18] <dholbach> Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your ~/.bashrc in a text editor and add something like this to the bottom of it:
[15:18] <dholbach>   export DEBFULLNAME="Bob Dobbs"
[15:18] <dholbach>   export DEBEMAIL="subgenius@example.com"
[15:18] <dholbach> Now save the file and either restart your terminal or run:
[15:19] <dholbach>   source ~/.bashrc
[15:19] <dholbach> (If you do not use the default shell, which is bash, please edit the configuration file for that shell accordingly.)
[15:19] <dholbach> If something just went too quick for you: no problem, you can always go back to the log of this session and retrace your steps.
[15:20] <dholbach> Did anybody face any problems? Or has any questions about what we just covered?
[15:20] <ClassBot> jamdatadude asked: ​ bzr complained that I was missing an SSH key
[15:20] <dholbach> ha! good point jamdatadude!
[15:21] <dholbach> I guess what happened was that you created your SSH key alright (does ~/.ssh/id_rsa.pub exist?) but Launchpad did not know about it yet.... which leads us to our next step :)
[15:22] <dholbach> You can paste your public SSH key (the public one is fine, not the secret one) into https://launchpad.net/~/+editsshkeys
[15:22] <dholbach> Insert the contents of your public key (usually ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub) into the text box and submit.
[15:23] <dholbach> Now rerunning the two bzr commands above should work.
[15:24] <dholbach> Did creating your GPG key finish already?
[15:24] <dholbach> Once this is done, you will get a message similar to this one:
[15:24] <dholbach> pub   4096R/43CDE61D 2010-12-06
[15:24] <dholbach>       Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
[15:24] <dholbach> uid                  Daniel Holbach <dh@mailempfang.de>
[15:24] <dholbach> sub   4096R/51FBE68C 2010-12-06
[15:25] <dholbach> If you look closely, in this case 43CDE61D is the key ID.
[15:25] <dholbach> (but you can always find out about yours, if you run   gpg --fingerprint <email@address.com>  )
[15:25] <dholbach> Next, you need to upload the public part of your key to a keyserver so the world can identify messages and files as yours. To do so, enter:
[15:26] <dholbach>   gpg --send-keys <KEY ID>
[15:26] <dholbach> This will send your key to one keyserver, but a network of keyservers will automatically sync the key between themselves. Once this syncing is complete, your signed public key will be ready to verify your contributions around the world.
[15:26] <dholbach> Once all of this is done, you can register your GPG key at https://launchpad.net/~/+editpgpkeys - you can do this later and I'll give you a link to all these instructions later on
[15:26] <ClassBot> Barzogh asked: is it possible to get a mentor that would help us to begin efficiently on software packaging ? i've already set up my environnement ( pbuilder, etc... )
[15:27] <dholbach> Barzogh, great question
[15:27] <dholbach> Barzogh, we tried the concept of 1-on-1 mentoring before, but we struggled quite a bit
[15:28] <dholbach> there was a huge mass of contributors who wanted a mentor, so we looked hard for people to mentor - a lot of people never followed up responsibly, so we didn't get much out of it, which is very unfortunate
[15:28] <dholbach> the good news is: we have great docs (I'll give links later on)
[15:28] <dholbach> and we have very friendly people on #ubuntu-motu who will take your questions
[15:28] <dholbach> and there's also ubuntu-motu-mentors@lists.ubuntu.com for those of you who prefer mailing lists
[15:29] <dholbach> also will I try to organise more packaging initiatives this cycle, so we work on packaging challenges together as a team
[15:29] <dholbach> which will making get involved a lot easier
[15:29] <dholbach> just follow @ubuntudev on twitter, identi.ca or facebook.com if you want to get updates
[15:30] <ClassBot> hannie asked: does it matter on which computer I use the pgp key?
[15:30] <dholbach> hannie, no, you can re-use your gpg key on whichever computer you want
[15:30] <dholbach> just make sure you copy over the ~/.gnupg/ directory
[15:31] <dholbach> I know I rushed through these whole instructions a bit quickly, but I hope you generally managed to take it all in :)
[15:31] <dholbach> More questions?
[15:31] <dholbach> If not, I'll talk about fixing bugs in Ubuntu in the next 30 minutes
[15:32] <dholbach> http://developer.ubuntu.com/packaging/html/_images/fixing-a-bug.png has a quick illustration of the process of fixing bugs
[15:32] <dholbach> As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged.
[15:32] <dholbach> -- Finding the problem --
[15:32] <dholbach> There are a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report.
[15:33] <dholbach> Harvest is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them ‘bitesize’), and so on. Check it out and find your first bug to work on. http://harvest.ubuntu.com
[15:33] <dholbach> -- Figuring out what to fix --
[15:33] <dholbach> If you don’t know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you’ll need to work on.
[15:33] <dholbach> Let’s say you’ve found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running /usr/bin/tomboy on the command line. To find the binary package containing this application, use this command:
[15:34] <dholbach>   apt-file find /usr/bin/tomboy
[15:34] <dholbach> This would print out:
[15:34] <dholbach>   tomboy: /usr/bin/tomboy
[15:34] <dholbach> Note that the part preceding the colon is the binary package name. It’s often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages. To find the source package for a particular binary package, type:
[15:34] <dholbach>   apt-cache showsrc tomboy | grep ^Package:
[15:35] <dholbach> Which will print out:
[15:35] <dholbach>   Package: tomboy
[15:35] <dholbach> If you type:
[15:35] <dholbach>   apt-cache showsrc python-vigra | grep ^Package:
[15:35] <dholbach> It will print out:
[15:35] <dholbach>   Package: libvigraimpex
[15:35] <dholbach> The latter example is a case, where one source package builds multiple binary packages.
[15:36] <dholbach> Can anyone think of a good reason to have one source package build multiple binary packages?
[15:37] <dholbach> Ok, I can easily clear this up: in some cases you might want to not give the user the burden to install EVERYTHING.
[15:37] <dholbach> Let's say you have a small tool which is 15k big, but you have 5MB of documentation - in this case you might want to split the two.
[15:38] <dholbach> Also if there are multiple libraries or tools with lots of different dependencies, you might want to split them up properly.
[15:38] <dholbach> -- Getting the code --
[15:39] <dholbach> Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. In Ubuntu Distributed Development this is done by branching the source package branch corresponding to the source package. Launchpad maintains source package branches for all the packages in Ubuntu.
[15:39] <dholbach> Once you’ve got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch. When you are happy with your fix, you can submit a merge proposal, which asks other Ubuntu developers to review and approve your change. If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets t
[15:39] <dholbach> he benefit of your excellent fix - and you get a little bit of credit. You’re now on your way to becoming an Ubuntu developer!
[15:39] <dholbach> So far so good?
[15:40] <dholbach> -- Work on a fix --
[15:40] <dholbach> There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly.
[15:41] <dholbach> Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:
[15:41] <dholbach>  - Upstream (and Debian) bug tracker (open and closed bugs),
[15:41] <dholbach>  - Upstream revision history (or newer release) might have fixed the problem,
[15:41] <dholbach>  - bugs or package uploads of Debian or other distributions.
[15:42] <ClassBot> mblank_ asked: What process should I follow if I found out that there is an upstream fix already?
[15:42] <dholbach> mblank, nice one!
[15:43] <dholbach> this depends entirely on where we are in the release cycle
[15:43] <dholbach> so let's say it's just one more week until release and you want to make sure we fix the bug before the release gets out
[15:43] <dholbach> in this case you want to try to incorporate just the minimal patch that is required to fix the issue
[15:43] <dholbach> the same goes for fixing bugs post-release
[15:44] <dholbach> ie. if you want to get a fix into oneiric-updates now
[15:44] <dholbach> we call this a SRU, a Stable Release Update
[15:44] <dholbach> in this cases we want to make absolutely sure that this just fixes the specific issue and nothing else, so we don't bring in additional regressions, etc.
[15:45] <dholbach> if we're early in the release cycle, you might want to include the whole new upstream release, which is then allowed to also bring in new features and the like
[15:46] <dholbach> I'll later give a link to instructions on how to use the tools to integrate patches like that easily. I fear we won't have the time in the last 14 minutes.
[15:46] <dholbach> More general questions?
[15:47] <dholbach> ok, let me then just quickly cover the rough basics of using Ubuntu Distributed Development
[15:47] <dholbach> to get the source code for package, you run
[15:47] <dholbach>   bzr branch lp:ubuntu/<packagename>        (for the latest development release, 'precise' in our case)
[15:47] <dholbach> and
[15:47] <dholbach>   bzr branch lp:ubuntu/<release>/<packagename>        (for any other release)
[15:48] <ClassBot> hannie asked: can I use this procedure when I find typos in GUI or documentation?
[15:48] <dholbach> hannie, yes, the process is always the same
[15:49] <dholbach> if you are asking about SRU fixes, typos might not qualify as super serious bug fixes, unless they seriously break things, but the process is the same, yes
[15:50] <dholbach> so if you branched a package, you can edit and make changes to your hearts delight, Bazaar makes it easy for you to stay focused and on top of things
[15:50] <dholbach> http://doc.bazaar.canonical.com/bzr.2.4/en/mini-tutorial/index.html is a nice tutorial, if you're not familiar with commands such as "bzr diff", "bzr add/remove", "bzr log" and the like
[15:51] <dholbach> One thing I still want to say about documenting changes
[15:51] <ClassBot> There are 10 minutes remaining in the current session.
[15:51] <dholbach> I mentioned earlier how important it is to communicate very clearly
[15:51] <dholbach> You don't want anybody to second-guess why you made changes or where exactly they were
[15:52] <dholbach> have a look at https://launchpad.net/ubuntu/+source/gedit/2.22.3-0ubuntu2 to see an example of a changelog entry
[15:52] <dholbach> Again: It is very important to document your change sufficiently so developers who look at the code in the future won’t have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes debian/changelog, where changes of each uploaded package are tracked.
[15:53] <dholbach> You want to let others know:
[15:53] <dholbach>  1. where the change was done
[15:53] <dholbach>  2. what was changed
[15:53] <dholbach>  3. where the discussion of the change happened
[15:53] <dholbach> In our (very sparse) example the last point is covered by "(lp: #236953)"
[15:53] <dholbach> which refers to Launchpad bug 236953. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the LP: #<number> notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu.
[15:54] <dholbach> so once you're done with your changes, you can easily commit them and push them by running:
[15:54] <dholbach>   bzr commit
[15:54] <dholbach> (which will commit the change locally)
[15:54] <dholbach> To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature:
[15:54] <dholbach>   bzr push lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>
[15:55] <dholbach> So for example:
[15:55] <dholbach>   bzr push lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456
[15:55] <dholbach> then you can run "bzr lp-open", which will open the corresponding page on Launchpad, where you can click on “(+) Propose for merging” link, to get the change reviewed by somebody and included in Ubuntu.
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
[15:56] <dholbach> We have 5 minutes left and I want you just do one more thing for me:
[15:56] <dholbach> please bookmark http://developer.ubuntu.com/packaging/html/
[15:56] <dholbach> it's all you should need for the next time, it will help you get started
[15:56] <dholbach> also drop by in #ubuntu-motu
[15:56] <dholbach> and don't hesitate ask your questions on ubuntu-motu-mentors@lists.ubuntu.com
[15:56] <dholbach> I know we had to rush through a lot of content in these 2 hours, so it was very compact.
[15:57] <dholbach> Maybe we have 1 or 2 closing questions?
[15:57] <dholbach> in the mean time please bookmark http://developer.ubuntu.com/packaging/html/ :-)
[15:57] <dholbach> (and make sure you follow @ubuntudev on identica, twitter or facebook)
[15:58] <dholbach> You are all awesome and I hope to see more of you in the 'precise' cycle! Thanks a lot everybody! :-)
[15:59] <dholbach> Next up is: "Is your system Ubuntu Friendly? Contributing to the community hardware testing program" -- Daniel Manrique (roadmr)
[15:59] <dholbach> roadmr, the stage is yours
[16:00] <roadmr> Thanks!
[16:00] <roadmr> Hello everyone! I'll be talking about Ubuntu Friendly. It'll be a rather hands-on session, with a nice website and a small application involved.
[16:00] <roadmr> Please feel free to ask questions in #ubuntu-classroom-chat at any time.
[16:00] <roadmr> So, is your computer Ubuntu Friendly? First, let me tell you what Ubuntu Friendly means.
[16:01] <roadmr> It means that your computer runs Ubuntu well, and that your devices work as you would expect them to, without needing to configure a lot of things in a difficult way.
[16:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session.
[16:01] <roadmr> We don't actually say that a computer is or isn't Ubuntu Friendly; rather, each model gets assigned a rating (from 1 to 5 stars) indicating how friendly it is.
[16:02] <roadmr> Think of it as a "friendliness meter" :) Ubuntu Friendly is still in Beta phase, but we're already producing some interesting and useful information.
[16:02] <roadmr> It's also an area where it's very quick and easy to contribute to the Ubuntu community. I'll show you how in a short while.
[16:02] <roadmr> So, why do you care about this, as an Ubuntu user?
[16:02] <roadmr> So, why do you care about this, as an Ubuntu user?
[16:03] <roadmr> sorry :) By visiting the website at http://friendly.ubuntu.com you can see friendliness ratings for systems that have been tested by other users like you.
[16:03] <roadmr> You can use these ratings to decide which computer to buy next, ensuring that it will work well with Ubuntu. Or maybe to see what other people say about the one you currently own.
[16:04] <roadmr> Maybe your company wants to buy computers to run Ubuntu and you'd like to recommend a model that works well.
[16:04] <roadmr> Or maybe you have a device that's giving you trouble and you'd like to see how it's working for other users with the same model.
[16:04] <roadmr> In any case the friendliness ratings are quite useful.
[16:04] <roadmr> As you may know, there is a list of hardware that’s certified for Ubuntu (http://www.ubuntu.com/certification).  Being on this list depends on manufacturers requesting certification for their systems.
[16:05] <roadmr> Corporations care about certification, as they like having support from Canonical, but end-users just care about sharing information and getting a system that works.
[16:05] <roadmr> Ubuntu Friendly wants to fulfill this need by providing data on a lot more models, thanks to contributions by users like you.
[16:05] <roadmr> Friendliness is not calculated based on a "subjective" rating given by testers. A system testing tool is run on each system, performing a series of automated and manual tests.
[16:06] <roadmr> This collected data is aggregated to produce both the friendliness rating, and some more detailed reports on each system.
[16:06] <roadmr> Let's begin by looking at the existing ratings. If you could please go to http://friendly.ubuntu.com you can take a look at information on several systems.
[16:07] <roadmr> Are you all already there? :)
[16:07] <roadmr> The website's interface is quite simple: first you'll see a listing of systems (by make and model), their Ubuntu Friendly rating, and the number of people who have rated, or tested, each system.
[16:07] <roadmr> At a glance you also get information on the CPU (little cog), GPU (screen icon) and wireless (WiFi icon) for each model.
[16:08] <roadmr> If you click on a model's name (you can do it, open this: http://bit.ly/p2yhmw) you'll see detailed information about each system.
[16:08] <ClassBot> gersitar asked: this is suppose to be a q/a format session or more like a lecture?
[16:09] <roadmr> If you have specific questions about the ratings and testing process there'll be time for that in a bit :) for now I'm showing this to people who may not have seen it before
[16:10] <roadmr> So we're looking at a model's page for a Samsung laptop.
[16:10] <roadmr> Here you'll get a list of all components in a system, and how many people reported each component as working correctly.
[16:10] <roadmr> You will notice components are split into "core" and "additional" components. The "stars" for each system are calculated taking this into account.
[16:11] <roadmr> For a system to have five stars, all components (core and additional) need to be reported as working. This is a system that works pretty much flawlessly with Ubuntu. Maximum friendliness!
[16:11] <roadmr> A system for which all core components work, but for which none of the available additional components work well, will get only three stars.
[16:11] <roadmr> A three-star system is considered "usable" but you may have trouble with some non-essential components. Friendly enough!
[16:12] <roadmr> A system which reports failures on at least one core component (meaning it's going to give trouble in an essential area) will get only one star. This is a quite unfriendly system. Imagine a laptop with no working WiFi!
[16:12] <roadmr> The split between "core" and "additional" components varies for laptops and desktop systems. The rating displayed on the website takes this into account.
[16:13] <roadmr> The system I picked has a rating of 3.6, since all core components passed the tests it gets 3 stars, plus 0.6 for the working additional components. It’s friendly and usable enough but not all additional components will work.
[16:13] <roadmr> The friendliness rating you see on the front page is an average of all reports. On the detailed view for a system, you can see (top right) the same rating, and a histogram of people reporting for each star rating.
[16:14] <roadmr> Thus if you see an average rating of 3 stars with 20 reports, but 10 of those are 1-star and the other 10 are 5-star, you may wish to do some deeper research before considering this system.
[16:14] <roadmr> Back on the main page, you have a search field (top) and some controls to filter results, to narrow down to features you're interested in.
[16:15] <roadmr> The website's interface as I said is quite simple, I just wanted to go a bit more in-depth on how ratings are calculated and what they mean.
[16:15] <roadmr> Now, you'll notice that most of the systems on the page have only one "rater". This means only one person has tested and sent data about each particular model.
[16:15] <roadmr> You may be wondering where the test results come from. This is where it gets interesting. These results have been sent in by the community! Ubuntu users like you.
[16:16] <roadmr> So you can also help build this resource by testing your system and sending the results. The more people that submit test results for each system, the more reliable they will be. It's the power of community testing aided by some statistics!
[16:16] <roadmr> I mentioned earlier that a "system testing" tool is used for this. The good news is, it's already installed on your Ubuntu system. If you're running Ubuntu 11.10, you can already help by testing your system.
[16:17] <roadmr> Let's give it a try so you see how easy it is. We'll run a quick set of tests and I'll show you how to submit those results to Ubuntu Friendly.
[16:17] <roadmr> Just a comment here. We can't run the whole set of tests right now, because some of them do funny things like suspend your system or test your network.
[16:18] <roadmr> So to avoid this we'll just be running a small subset of tests. This means the data you submit right now won't be enough to generate an Ubuntu Friendly rating for your system.
[16:18] <roadmr> But don't worry, after this you'll be able to help by running all the tests.
[16:19] <ClassBot> genii-around asked: Is the data from https://wiki.ubuntu.com/Testing/Laptop/Procedures used to produce results at http://friendly.ubuntu.com/ ?
[16:19] <roadmr> Answer: No, this uses a different procedure and test suite.
[16:20] <roadmr> So please use your Unity dash to search for "Ubuntu Friendly". Launch the System Testing utility that appears.
[16:20] <roadmr> If you’re using a derivative like Kubuntu or Xubuntu, you will probably need to install the checkbox and checkbox-gtk packages.
[16:20] <roadmr> You'll first see a welcome message. We'll ignore the warning about closing all applications, as we will run just a few tests now. Press Next...
[16:21] <roadmr> It will ask for your password, please input it. In case you're wondering, the password is needed to collect some data about your system. Don't worry, it won't collect or submit any personal information.
[16:21] <roadmr> Next you'll see a list of available tests. For the data to be useful for Ubuntu Friendly we'd have to leave them all selected... but...
[16:21] <roadmr> In this case we will press "Deselect All", then select only Graphics tests and Informational tests. Then press "Next" to start testing!
[16:22] <roadmr> For each test, you'll see a description explaining what to do. Some tests will just ask you a question. Some will ask you to press "Test", then ask you to confirm.
[16:22] <roadmr> In all cases, you can select "yes" or "no" to answer the question, or "skip" if a test doesn't apply to your system.
[16:22] <roadmr> For instance if the test is about SD cards but you don't have one handy, select "Skip". Of course, the more tests you do, the better.
[16:23] <roadmr> Once you select an answer, press "Next" to record it and go on to the next test.
[16:23] <roadmr> So for instance, when the test asks you to confirm whether resolution is correct for your system, select "Yes" or "No" and press "Next".
[16:23] <roadmr> If it asks you to press "Test" to display a video test, do so, and check that the video test works well, then select "Yes" or "No" and press "Next". Simple!
[16:24] <roadmr> Hopefully everyone is doing well with this quick test :)
[16:24] <roadmr> Once it's done, it will say "The following report has been generated".
[16:24] <roadmr> On this screen, you can have a look at a report about your system by clicking on "View Report". There's also a text field right above the "Previous" and "Next" buttons.
[16:25] <roadmr> If you want to send your results in to Ubuntu Friendly, please put your e-mail address here, then click "Next".
[16:25] <roadmr> (Though as I mentioned earlier, this test set is small and won't make it into Ubuntu Friendly - but this is how you'd go about testing and sending in your results)
[16:26] <roadmr> Once your results are sent in, they will be processed and your system's test results will be added to Ubuntu Friendly after a few hours.
[16:26] <roadmr> And that's it! it's easy and quick to contribute to Ubuntu Friendly. So running the full set of tests on your system is a great way to help.
[16:28] <roadmr> okay! I have some resources to share with you about Ubuntu Friendly but I think it's a good time for questions, maybe some of your questions will be solved by the extra material I have
[16:28] <ClassBot> ikt asked: what about computers that are custom built, will ubuntu friendly eventually extend to rate each individual parts? or maybe a subset of specific parts like video cards/cpus etc?
[16:29] <roadmr> great question! so, UF rates systems as a whole, so a custom-built computer will probably be identified by some OEM data given by the motherboard
[16:29] <roadmr> BUT components are rated individually within each submission
[16:29] <roadmr> so it'll be easy for people to see "hey, this is a 5-star system" - then go in, and look at exactly the components you have and how they tested
[16:30] <roadmr> if they want to duplicate your system and get a 5-star Ubuntu box it's doable
[16:30] <roadmr> of course, if it's a very custom configuration, the number of raters will be low (potentially just you), so the statistical usefulness of the results could be low, but that's why we show number of raters on each submission
[16:30] <roadmr> so people can use that information to decide how reliable the data is.
[16:30] <roadmr> Thanks for this question!
[16:31] <ClassBot> arasbm asked: are components such as wacom pen, multitouch panel, or fingerprint reader considered for testing when appropriare?
[16:32] <roadmr> The list of components that are tested and considered is here: https://wiki.ubuntu.com/UbuntuFriendly/Process/Components
[16:32] <roadmr> I can tell you that fingerprint readers are not tested
[16:32] <roadmr> wacom pen would probably be tested as a pointing device - just basic mousing functionality
[16:33] <roadmr> and multitouch panel - same thing, we don't test for things such as multitouch and gestures
[16:33] <roadmr> some of these tests are "manual" in that you have to tell us whether the mouse or trackpad works, if you consider it to not be working due to lack of these features you can say "No" and add a comment to that effect
[16:34] <ClassBot> danne asked: Are partial tests included or just complete tests?
[16:34] <roadmr> I assume you mean a partial test run, such as the one we just did :)
[16:35] <roadmr> For a test run to be valid, you need to leave all the tests selected in the test selection screen
[16:35] <roadmr> so for instance the one we did wouldn't be valid for UF as there are a lot of components that we didn't test
[16:35] <roadmr> if your system lacks a certain component and you know you shouldn't test it, please leave it selected anyway
[16:36] <roadmr> you'll have a chance to skip the test if it doesn't apply to your system
[16:37] <roadmr> This particular bit is explained in our "how to participate" page, and here's one of the resources I wanted to share with you: http://friendly.ubuntu.com/participate/
[16:37] <roadmr> ara did a wonderful screencast on how to test your system, so if you want a refresher on how to run the test suite, this is where you should go :)
[16:38] <ClassBot> azteech asked: if tester has multi-monitor set up, does each monitor get tested, and results reported as showing multi-monitor capable?
[16:38] <roadmr> I guess it depends on how complex your multihead setup is :)
[16:39] <roadmr> we basically test each port separately. This is a purely manual test where we ask if your VGA connector is working
[16:39] <roadmr> we test VGA and HDMI video output
[16:39] <roadmr> so again, if you have a multihead setup and think it's not working well, you're welcome to say "No" and provide more details about it
[16:40] <roadmr> however, if you have a specific problem with a certain hardware component in Ubuntu, probably the best way to go is to file a bug report about it
[16:40] <ClassBot> arasbm asked: is there a process for people to add new tests to be included?
[16:41] <roadmr> there's no formal process at the moment, however, if you're interested in helping improve the test suite, there's plenty of work to be done, and plenty of room for suggestions
[16:41] <roadmr> If you'd like to get involved a bit more, you can take a look at this page https://wiki.ubuntu.com/UbuntuFriendly.
[16:42] <roadmr> The Ubuntu Friendly Squad is the group that works on the whole process, and we always welcome contributors
[16:42] <roadmr> as a technical "good to know", the test suite is contained in the "checkbox" package, so you can always go and have a look at how the tests work
[16:44] <roadmr> did anyone have problems while running the small test set a few minutes ago? :)
[16:46] <roadmr> As I mentioned before, Ubuntu Friendly is still in beta phase. So some tweaks may still be done to the rating system and the test suite. User feedback is very important for this.
[16:46] <roadmr> So if you have any questions, comments, suggestions, other than the resources I already posted (web page and Ubuntu Friendly Squad webpage)
[16:47] <roadmr> you can also report problems with the Ubuntu Friendly website ("Report a Problem" up top)
[16:47] <roadmr> We're always happy to receive feedback, bug reports, and comments
[16:47] <roadmr> If you have any questions you can ask us in the Ubuntu Friendly mailing list (ubuntu-friendly-squad@lists.launchpad.net). People who know about Ubuntu Friendly also hang out in #ubuntu-testing.
[16:49] <roadmr> any more questions? comments? :)
[16:50] <ClassBot> chute_ asked: will there be a version for pre 11.10 ubuntus?
[16:51] <ClassBot> There are 10 minutes remaining in the current session.
[16:51] <roadmr> great question.. but I think we don't have that planned :( Hardware evolves pretty quickly and the software needs to evolve to keep up with that
[16:51] <roadmr> so we're focusing on the latest releases
[16:51] <roadmr> and we certainly want this to be quite mature for 12.04 due to its LTS nature
[16:52] <roadmr> but to answer your question, no, really you need 11.10 for things to work. Sorry about that...
[16:53] <roadmr> we still have a few minutes so ask away :)
[16:54] <roadmr> So it seems everybody is busy testing :)
[16:55] <ClassBot> arasbm asked: can tests be performed from a live flash disk or cd?
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:56] <roadmr> I think they can be run from a live cd, but not from a live usb, because the disk configuration confuses the tests (since we also test USB), sorry about that
[16:56] <roadmr> it's really best if you can test from a hard disk installation
[16:57] <ClassBot> chute_ asked: is the data gathered from checkbox-gtk feeding the UF database?
[16:57] <roadmr> yes, well the system testing utility also known as checkbox submits results to a database from which the UF ratings are generated
[16:58] <roadmr> it doesn't feed UF directly, results are batch processed and stored in processed form in UF
[16:58] <roadmr> if you're interested in knowing a bit more about the technical details you're welcome to join the Ubuntu Friendly Squad, the folks who developed that infrastructure are in that group
[16:59] <roadmr> any (literally) last-minute questions? :) make it a short one, only 50 seconds for me to reply
[16:59] <roadmr> well so let's wrap it up :)
[16:59] <roadmr> That's it for this session, thanks for coming and happy testing!
[17:00] <roadmr> I leave you in Cheesehead's capable hands :) (Ubuntu Brainstorm!)
[17:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session.
[17:01] <Cheesehead> roadmr: Thanks!
[17:01] <Cheesehead> roadmr: Thanks for a great session of Ubuntu Friendly.
[17:01] <Cheesehead> The Ubuntu-US-WI LoCo team will host an Ubuntu Friendly party on IRC (#ubuntu-us-wi) in nine hours. Anybody welcome to join us.
[17:01] <Cheesehead> .
[17:02] <Cheesehead> Welcome to the session on Brainstorm
[17:02] <Cheesehead> Brainstorm: Will your idea change the world?
[17:02] <Cheesehead> (The answer, by the way, is "Yes")
[17:02]  * Cheesehead pauses for breath
[17:02] <Cheesehead> Ubuntu Brainstorm ( http://brainstorm.ubuntu.com )is a place for people to post their ideas about Ubuntu.
[17:02] <Cheesehead> They can be promoted/demoted, and the most popular are reviewed by the Ubuntu developers.
[17:02] <Cheesehead> Brainstorm is one of the many good ways to contribute to the Ubuntu community.
[17:02] <Cheesehead> .
[17:03] <Cheesehead> Let me lecture about 20 lines with Brainstorm background, then we'll get to the GOOD STUFF - what Brainstorm can do for you, and how you can contribute to Brainstorm.
[17:03] <Cheesehead> Brainstorm opened in February 2008.
[17:03] <Cheesehead> Way back then, there was a lot of grumbling and in the community. Users grumbled that their feedback was ignored. Developers grumbled that feedback was swamping them.
[17:03] <Cheesehead> Brainstorm was one of many solutions to address those issues. It has evolved a bit from it's roots, but is still true to the original mission (a place to post, most popular get reviewed by developers).
[17:03]  * Cheesehead sips from a handy glass of water
[17:03] <Cheesehead> .
[17:03] <Cheesehead> We currently receive about 6,000 ideas a year.
[17:03] <Cheesehead> Every idea goes through a review-and-approval before opening to votes.
[17:04] <Cheesehead> That review-and-approval process is really important - I'll talk more about that in few minutes.
[17:04] <Cheesehead> Around 600-700 ideas will be opened to votes and comments this year.
[17:04] <Cheesehead> Finally, the top 40 ideas get reviewed by the Ubuntu Technical Board (UTB). 10 every three months.
[17:04] <Cheesehead> All UTB-selected ideas get feedback. And some become UDS-sessions, some get milestoned for future releases, some get adopted other ways, and a few get outright rejected.
[17:04] <Cheesehead> At first glance, a 6% selection rate by UTB doesn't seem great.
[17:04] <Cheesehead> But remember, that's just *one* avenue for getting the idea implemented! (The one that publishes results)
[17:04] <Cheesehead> Ubuntu is NOT a top-down hierarchy, and implementing Ideas is not the UTB's job anyway.
[17:04] <Cheesehead> *Anyone* can implement an idea, or start a project to implement an idea.
[17:05] <Cheesehead> *Any* project or team can use an idea from Brainstorm.
[17:05] <Cheesehead> *Any* individual can be inspired by a Brainstorm idea, and run with it.
[17:05] <Cheesehead> Some other teams do use Brainstorm for feedback, and some developers use it as a polling system. None currently publish numbers about how many ideas they use.
[17:05]  * Cheesehead sips from his drink again.
[17:05] <Cheesehead> .
[17:05] <Cheesehead> So, how can you mold the future of Ubuntu through Brainstorm?
[17:06]  * Cheesehead pauses a moment to let everyonje catch up
[17:06] <Cheesehead> .
[17:06] <Cheesehead> There are FIVE ways you can help.
[17:06] <Cheesehead> .
[17:06] <Cheesehead> 1) You can contribute ideas
[17:07] <Cheesehead> .
[17:07] <Cheesehead> 2) You can contribute solutions to other ideas.
[17:07] <Cheesehead> More and better solutions are really the key to getting a good idea recognized, upvoted, and implemented.
[17:07] <Cheesehead> For example, a common generic idea is to add Feature X to Application Y. But that ignores all the other similar applications.
[17:07] <Cheesehead> Another solution might be to create a lib (or add to an existing lib) so all applications can benefit.
[17:07] <Cheesehead> *You* contribute those better solutions
[17:07] <Cheesehead> .
[17:07] <Cheesehead> 3) You can add constructive comments to other ideas. Better yet, if you are skilled in the appropriate area,
[17:07] <Cheesehead> you can probably recruit the submitter onto your team, or mentor them on how to implement a solution themselves.
[17:08] <Cheesehead> If you're on a project looking to add new members, you can see the benefit there!
[17:08] <Cheesehead> .
[17:08] <Cheesehead> 3) You can add constructive comments to other ideas. Better yet, if you are skilled in the appropriate area,
[17:08] <Cheesehead> you can probably recruit the submitter onto your team, or mentor them on how to implement a solution themselves.
[17:08] <Cheesehead> Wait...I just said that
[17:08]  * Cheesehead is happy nobody noticed
[17:09] <Cheesehead> .
[17:09] <Cheesehead> 4) You can be a liason between Brainstorm and other Ubuntu teams and communities.
[17:09] <Cheesehead> You become a bridge, sharing your knowledge and experience of your communities with the Brainstorm community,
[17:09] <Cheesehead> and sharing the appropriate ideas with your other Ubuntu communities.
[17:09] <Cheesehead> For example, you can help review ideas: "Yeah, we thought of that last year, and are already working on it (IN DEVELOPMENT)"
[17:09] <Cheesehead> And you can help bring good ideas to your team: "Say, an idea popped up on Brainstorm to replace our internal database with a CouchDB"
[17:09] <Cheesehead> This is a particularly good way to get feedback AND squash rumors.
[17:09] <Cheesehead> ...and even recruit a new member?
[17:10] <Cheesehead> .
[17:10] <Cheesehead> 5) You can help review ideas, and mentor the idea submitters on how to improve them, clarify them, and make them more useful.
[17:10] <Cheesehead> Or to help refer the submitter to a more appropriate venue like the Bug Tracker or the correct Ubuntu Team that handles the issue.
[17:10] <Cheesehead> The Brainstorm reviewers and moderators do a lot of that.
[17:10]  * Cheesehead sips from his drink again.
[17:10] <Cheesehead> Okay, that's the end of the lecture portion of the evening.
[17:11] <Cheesehead> While you fellows think up some questions, I'm going to pretend to have a snack.
[17:11]  * Cheesehead pretends to have a snack
[17:14] <ClassBot> chute_ asked: Where can those 600-700 ideas be visualized?
[17:15] <Cheesehead> Visualized?
[17:15] <Cheesehead> I suppose you mean read-or-searched. On the brainstorm site.
[17:16] <Cheesehead> http:brainstorm.ubuntu.com
[17:16] <Cheesehead> If you mean more advanced info visualization techniques...
[17:16] <Cheesehead> a collaborator on the Ideatorrent software to develop such tools would be welcome.
[17:17] <ClassBot> h00k asked: Is there a list of implemented features that came from Ubuntu Brainstorm?
[17:17] <Cheesehead> Sort of.
[17:17] <Cheesehead> Developers don't always credit their initial inspiration...
[17:18] <Cheesehead> So we don't know if some came from Brainstorm or from the Bug Tracker ...
[17:18] <Cheesehead> or from a UDS discussion or upstream.
[17:18] <Cheesehead> We do track implemented ideas from all sources, not just directly implemented from Brainstorm
[17:19] <Cheesehead> It's on the main page, the "Implemented Ideas" tab.
[17:19] <ClassBot> Talinus asked: Can you give as an example for an already implented feature, that was suggested on brainstorm.ubuntu?
[17:20] <Cheesehead> Essentially the same question (not the questioner's fault I type slow!)
[17:21] <Cheesehead> Since the Ubuntu moderators don;t track ideas after they leave Brainstorm, I hesitate to authoritatively claim a new feature
[17:21] <Cheesehead> I didn't code it - a developer did. So I'll let the developer have the credit no matter the source.
[17:21] <Cheesehead> Fair enough?
[17:21] <Cheesehead> .
[17:22] <Cheesehead> There is a valid point to the question:
[17:22] <Cheesehead> What *good* is Brainstorm is I can't see any ideas get implemented?
[17:22] <Cheesehead> Well, that's too narrow a definition.
[17:22] <Cheesehead> Brainstorm is a huge gateway for new users
[17:23] <Cheesehead> And we refer them over to LoCos and teams and help them find ways to get involved.
[17:23] <Cheesehead> That's good.
[17:23] <Cheesehead> Developers *do* use Brainstorm for inspriation...even if sometimes the final result is different from the original Idea.
[17:23] <Cheesehead> Ubuntu Friendly is a classic example of that...
[17:24] <Cheesehead> In 2008, the first day of Brainstorm, the idea of an automated hardware database was proposed.
[17:24] <Cheesehead> And kicked around for years.
[17:24] <Cheesehead> Finally, Ubuntu Friendly made it actually happen.
[17:25] <Cheesehead> Does that mean that Brainstorm influenced the creation of Ubuntu Friendly?
[17:25] <Cheesehead> I honestly don't know. I helped moderate the idea, it was seen by a *lot* of eyes, and I suspect it had an impact...
[17:25] <Cheesehead> even though the final implementation is different from any of the solutions.
[17:26] <ClassBot> madjr asked: Why dont Ubuntu Developers also submit their ideas to brainstorm for feedback or even receive better suggestions? I ask this , because It seems many are ignoring brainstorm lately as it doesnt feel integrated or officially used by everyone enough, like if it were a side project or something from a third party
[17:26]  * Cheesehead adjusts hit tie
[17:26] <Cheesehead> Man, tough crowd!
[17:26]  * Cheesehead laughs
[17:26] <Cheesehead> That's a great question.
[17:27] <Cheesehead> And like many great questions, it can have a lot of answers.
[17:27] <Cheesehead> For example...most developers I know like to develop.
[17:27] <Cheesehead> They're not thrilled with bugtracking or documentations or...
[17:28] <Cheesehead> lots of the other administrivia associated with developing.
[17:28] <Cheesehead> This kind of feedback is both administrivia and optional
[17:28] <Cheesehead> so I'm not too surprised that some developers opt not to do it.
[17:29] <Cheesehead> I personally dislike ironing shirts, so I don't iron a lot of my shirts.
[17:30] <Cheesehead> If a developer wants to let their code or product speak for itself, well...it's their choice.
[17:30] <Cheesehead> And that highlights how non-developers can help on a project.
[17:31] <Cheesehead> Non-develoeprs can help document, can help triage bugs, can help communicate the project with the world.
[17:31] <Cheesehead> And can help add that information to brainstorm
[17:32] <Cheesehead> .
[17:32] <Cheesehead> You also raised the point that sometimes Brainstorm feels disconencted from the rest of the community.
[17:32] <Cheesehead> Well, sometimes it does.
[17:32] <Cheesehead> But that isn't the community's fault.
[17:33] <Cheesehead> That's something that is 100% Brainstorm-user fixable.
[17:34] <Cheesehead> Brainstorm users are supposed to bring their own experience and knowledge to the various ideas (see 2,3,4 above)
[17:34] <Cheesehead> And they do, in droves.
[17:34] <Cheesehead> Again, Brainstorm is only the first step to getting an idea implemented
[17:35] <Cheesehead> If you rely on somebody else to do all that research and coding and legwork, what do they get out of it?
[17:36] <Cheesehead> But if you use Brainstorm as one tool in your toolbox, along with the rest of the community, the Teams, upstream projects, and more...
[17:36] <Cheesehead> And you use those tools appropriately,
[17:36] <Cheesehead> Then you have a much greater chance of success.
[17:37] <ClassBot> madjr asked: ok, thank you, but why not have some ideas that need "design" and will affect many users get a mandatory mark as "needs more feedback from community, public and/or other developers". Worth considering ! :)
[17:37] <Cheesehead> Well, ideas that need 'design' may be more appropriate to a different venue.
[17:38] <Cheesehead> Brainstorm is *not* a useful venue to tell other people to go create things for you.
[17:38] <Cheesehead> There is no roomful of coding monkey sitting around, waiting to start jamming on the next idea.
[17:38] <Cheesehead> Doesn't exist. I wish it did, but it doesn't.
[17:38] <Cheesehead> (And their code quality wood be awful anyway)
[17:38] <Cheesehead> (Every time I ask a roomful of monkeys to produce anything they just fling feces at me and type a lot of Shakespeare)
[17:38] <Cheesehead> .
[17:39] <Cheesehead> If it 'Needs more feedback', then it's in the voting queue, and Brainstorm has built-in 'publicize it' tools, graphics and links.
[17:39] <Cheesehead> And it can get feedback and votes over *years*, if need be.
[17:41]  * Cheesehead sips from his drink again.
[17:42]  * Cheesehead ambles over to the snack table and picks up a carrot
[17:45]  * Cheesehead slowly chews the carrot, steely gaze swinging around the room *daring* somebody to ask a question
[17:45] <ClassBot> callaghan asked: I like how the Banshee developers did it: They created a PPA for an upcoming version, an article was published on OMGUbuntu! and the users started putting suggestions for improvement in the comments. David Nielsen answered nearly all of them and also considered them. This is something that should be done on Ubuntu Brainstorm for more projects...
[17:46] <Cheesehead> That's also a great way to get direct feedback on a project
[17:46] <Cheesehead> I'm not going to say that Brainstorm is the right way for everybody under all circumstances
[17:46] <Cheesehead> That would be silly
[17:48] <Cheesehead> In those circumstances, an established project, a limited set of feedback, users who knew where to find it, and a managable number of responses. Great!
[17:48] <Cheesehead> Brainstorm has some additional benefits (and contraints)
[17:48] <Cheesehead> And Brainstorm has had a ton of Banshee ideas.
[17:49] <Cheesehead> Another opportunity for a Banshee-involved non-developer to make a big difference as a liason.
[17:49] <Cheesehead> One of Brainstorm's big benefits to smaller projects is that it's already-installed infrastructure
[17:50] <Cheesehead> Complete with moderation to weed out bugs and irrelevancies!
[17:50] <Cheesehead> All your project needs to do is provide a volunteer part-time liason to check the queue every few days.
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:52] <Cheesehead> If you're interested more in how moderation works, how to get your project into Brainstorm (you can, you know!), how to use Brainstorm to recruit new members, just drop by #ubuntu-brainstorm and we can help you find a solution.
[17:53] <Cheesehead> Similarly, if you're new to the Ubuntu community, and you're not sure where to go. You have an idea, but not sure how to get from here to there...drop by and talk to a moderator. We can give you good advice, talk over the various choices and venues with you, and set you in the right direction.
[17:53]  * Cheesehead sips from his drink again.
[17:55] <ClassBot> madjr asked: As per the last question of banshee. Would be a good move to have launchpad integrate better with brainstorm (kind how some projects use "Get Satisfaction" for users to vote on ideas, etc.), what do you think ?
[17:55] <Cheesehead> Great question.
[17:55] <Cheesehead> And one that has been debated before.
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[17:56] <Cheesehead> Launchpad and Brainstrom have very different missions.
[17:56] <Cheesehead> Launchpad is for project management and code
[17:56] <Cheesehead> Brainstorm is for discussing problems and alternatives
[17:57] <Cheesehead> There is a lot of crossover.
[17:57] <Cheesehead> A lot of Brainstorm ideas are actually misfiled bug reports.
[17:58] <Cheesehead> But they lack enough detail be a useful launchpad bug report
[17:58] <Cheesehead> I think their fields are dissimilar enough to keep them separate for the next few years.
[17:59] <Cheesehead> Brainstorm was started because not every issue needed to fit into a bug report or development milestone.
[18:00] <Cheesehead> And some of the really good ideas cross multiple packages or concepts. Back in 2008 Lauchpad wasn't as good at those as it is now.
[18:00] <Cheesehead> Thanks everyone!
[18:00] <Cheesehead> See you in Brainstorm!
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html
[21:54] <Microsoft__> hi >:)
[21:54] <Microsoft__> !help
[21:54] <ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[21:54] <Microsoft__> !ban
[21:54] <ubot2> If you have been banned it is probably because you have not gone along with what is acceptable !behaviour. If you're not sure what acceptable !behaviour is please see !Etiquette and http://wiki.ubuntu.com/IRC/Guidelines - If you think the ban was a mistake, please join #ubuntu-ops
[21:54] <Microsoft__> !virus
[21:54] <ubot2> Antivirus is something you don't need on !Linux. except where files are then passed to windows computers (perhaps using samba), See https://help.ubuntu.com/community/Antivirus
[21:54] <Microsoft__> Wrong!
[21:54] <Microsoft__> there is actually 9,000 viruses for linux as of today.
[21:54] <Microsoft__> go to
[21:54] <Microsoft__> http://goggle.com for the virus list ;)
[21:55] <Microsoft__> jk that is a spam link but there is viruses now.
[21:55] <Microsoft__> !spam
[21:55] <ubot2> Factoid 'spam' not found
[21:55] <Microsoft__> !Rules
[21:55] <ubot2> The people here are volunteers, your attitude should reflect that. Answers are not always available. See http://wiki.ubuntu.com/IRC/Guidelines
[21:55] <Microsoft__> !rules
[21:55] <Microsoft__> !emergency
[21:55] <ubot2> Factoid 'emergency' not found
[21:55] <Microsoft__> l
[21:55] <Microsoft__> d
[21:55] <Microsoft__> d
[21:55] <Microsoft__> d
[21:55] <Microsoft__> d
[21:55] <Microsoft__> d
[21:55] <Microsoft__> d
[21:55] <Microsoft__> !spam
[21:55] <ubot2> Factoid 'spam' not found
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> d
[21:56] <Microsoft__> a
[21:56] <Microsoft__> e
[21:56] <Microsoft__> jjee
[21:56] <Microsoft__> r
[21:56] <Microsoft__> e