=== Debian is now known as Guest55136
=== 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 Women Project - Instructors: pleia2, belkinsa
[15:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2014/04/23/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <pleia2> hi everyone, welcome to day two of Ubuntu Open Week :) full schedule for today can be found here: https://wiki.ubuntu.com/UbuntuOpenWeek#The_Timetable
[15:01] <pleia2> first up, we have a session about the Ubuntu Women Project
[15:01] <pleia2> my name is Elizabeth K. Joseph. I currently work for HP and am tasked with working on the OpenStack Infrastructure team
[15:02] <pleia2> here in the Ubuntu world, among other things, I'm a member of the Ubuntu Community Council and one the quartet of leaders for the Ubuntu Women project along with Cheri Francis, Flavia Weisghizzi and Silvia Bindelli
[15:02] <pleia2> joining me today for this session is Svetlana Belkin (belkinsa) who will be discussing some of our current programs
[15:02] <belkinsa> o/ everyone!
[15:02] <pleia2> :)
[15:02] <pleia2> if anyone has any questions during this session, please speak up at any time, in #ubuntu-classroom-chat you can do a question like:
[15:02] <pleia2> QUESTION: Do you like penguins?
[15:02] <pleia2> and we'll be able to pull it over here via ClassBot to answer it
[15:03] <pleia2> as a bit of history, the Ubuntu Women project was started in 2005 and formalized in 2006 (around when I got involved) by folks (women and men) who were interested in helping to get more women using and contributing to Ubuntu
[15:03] <pleia2> continuing efforts have been spurred on by continued gender imbalance in open source, so loosely we work to:
[15:03] <pleia2> * reach out to women in our community or interested in joining and offer help to get involved, either through mentoring or better getting involved tools
[15:04] <pleia2> * give suggestions to current community members about how they can encourage higher female participation (or, at the very least, not actively drive them away)
[15:04] <pleia2> * work on programs to raise the profile of potential role models already within our community (having role models has proven to be a very important part of increasing involvement)
[15:04] <pleia2> * provide a safe environment where people can feel free to discuss problems or concerns they have about the community related to gender issues
[15:04] <pleia2> we're happy to say that when we were last tracking it, we were showing 5% of Ubuntu Members as women, which is higher than the general open source world where statistics range from 1-4%
[15:05] <pleia2> but obviously 5% isn't great either :) we want a lot more women joining Ubuntu and technology in general, so our efforts continue
[15:05] <pleia2> logistically, we primarily communicate on our mailing list: https://lists.ubuntu.com/mailman/listinfo/ubuntu-women (please sign up to post, so our moderators have less work :))
[15:06] <pleia2> and in IRC, in an unlogged channel at #ubuntu-women and our logged channel where we have meetings at #ubuntu-women-project and members can discuss things that they wish to have logged
[15:06] <pleia2> now, before we get into talking about some of our current projects, I have 2 things this session is not about, but may be useful resources for those interested
[15:07] <pleia2> 1. We won't be justifying the existence of the Ubuntu Women Project or explaining basic feminism topics
[15:07] <pleia2> this is open source! Members of the project feel it is valuable and wish to spend their time on it, if you are interested in the project please join us! and if not, work on something else :)
[15:07] <pleia2> if you are interested in the language of feminism, particularly as it relates to open source communities, to understand why we do what we do, I recommend starting with: http://geekfeminism.wikia.com/wiki/Feminism_101
[15:07] <pleia2> 2. We won't be rehashing the challenges that many women face in open source, tech or geek communities in general, or incidents that have occurred, it's not constructive for this space and these are already well-documented in many places, including:
[15:08] <pleia2> http://geekfeminism.wikia.com/wiki/Timeline_of_incidents
[15:08] <pleia2> http://geekfeminism.wikia.com/wiki/Category:Issues
[15:08] <pleia2> now, recent projects and plans for the future!
[15:08] <pleia2> like many more development-focused teams, we participate in the Summits every 6 months and put together a blueprint for what we wish to work on for that cycle, you can check out our finished blueprint for trusty here:
[15:08] <pleia2> https://blueprints.launchpad.net/ubuntu-women.org/+spec/community-1311-ubuntu-women
[15:09] <pleia2> through these blueprints everyone on the team is aware of priorities and committments for the cycle so everyone can stay on the same page
[15:09] <pleia2> we also host monthly meetings, whether we have an agenda or not, to check in on blueprint items and make sure everyone is on track and have the help they need to complete their tasks
[15:10] <pleia2> using this system has really helped our team keep momentum through the past couple years, so a huge thank you to everyone who participates in these summit sessions and/or monthly meetings :)
[15:10] <pleia2> we'll be having a session at the next summit too, coming up in June, details to be announced on our mailing list when our session is scheduled
[15:10] <pleia2> now, looking back to last year on some of our work to help shape direction, we ran a survey encouraging folks to give us feedback on the work the project was doing, anonymous results were made available:
[15:11] <pleia2> http://blog.ubuntu-women.org/2013/09/ubuntu-women-survey-2013-results-part-1/
[15:11] <pleia2> http://blog.ubuntu-women.org/2013/10/ubuntu-women-survey-2013-results-part-2/
[15:12] <pleia2> we were really impressed with the response to the survey, it was shared pretty widely and we got responses from a bunch of folks who hadn't heard of us before, so the feedback was diverse
[15:12] <pleia2> as a result of feedback in this survey, we've redoubled our efforts to work on our Career Days sessions so women in our community get exposure to careers where Open Source is a valueable skill
[15:13] <pleia2> Career Days are the brain child of Cheri Francis and we've been tracking our sessions here: http://wiki.ubuntu-women.org/CareerDays
[15:13] <pleia2> most recently we had Laura Czajkowski come to talk about her technical career and current position as EMEA Community Manager for MongoDB, it was really exciting to hear how her technical background and open source work has assisted her in this new, more community-focused role
[15:14] <pleia2> if anyone is interested in talking about their career with us during a Career Day, please let me know!
[15:14] <pleia2> while we're happy to have women showcase their careers (helps us grow the number of female role models), the point of this project is to show a diverse set of professions and skills, so we'd be happy to have anyone :)
[15:15] <pleia2> we also decided to increase the work we're doing to help women get involved in the community, with the GetInvolved Wiki Page Improvement and Project Harvest, which belkinsa will talk about now after introducing herself
[15:15] <belkinsa> Before I start, are there any questions for pleia2?
[15:16] <pleia2> if you think of anything, feel free to ask at any time (or at the end :))
[15:16] <belkinsa> Indeed, we are always open for questions during our session.
[15:17] <belkinsa> Okay, moving on...
[15:17] <belkinsa> Allow me to introduce myself...
[15:17] <belkinsa> I'm Svetlana Belkin (belkinsa) and I'm a Ubuntu Community Member that focuses on get people involved with Ubuntu, mainly in the Ubuntu Women team.
[15:18] <belkinsa> I'm the driver of two projects within the team.
[15:18] <belkinsa> The first is the GIWPI project.
[15:19] <belkinsa> And it stands for GetInvolved Wiki Page Improvement
[15:19] <belkinsa>  II. This project aims to improve that wiki page in order to get more people to get involved with Ubuntu and the Ubuntu Women Project
[15:19] <belkinsa> - II.
[15:19] <belkinsa> The project's page is here: http://wiki.ubuntu-women.org/GIWPI
[15:20] <belkinsa> It is almost done minus the quiz that we, as a team, have been working on that will allow users to answer some questions and based on the answers they will be suggested a team where they can be involved in.
[15:21] <belkinsa> I don't have the link to the quiz, but maybe we will have it out for testing soon.
[15:22] <belkinsa> There is also a sub project that aims to collect  the stories of Ubuntu Women members and how they got involved with Ubuntu and the Ubuntu community and it's called  V. WhatPeopleAreDoing
[15:23] <belkinsa> Link to the page: http://wiki.ubuntu-women.org/WhatPeopleAreDoing
[15:24] <belkinsa> pleia2 just supplied me the Italian version of the quiz which uses the same code as our English version: http://www.ubuntu-it.org/comunita/orientamento
[15:24] <belkinsa> Thanks pleia2.
[15:24] <belkinsa> Going back to the WhatPeopleAreDoing topic, I wanted to add that  you can submit one yourself if you have the wiki editing skills or e-mail me <belkinsa@ubuntu.com>
[15:25] <belkinsa> Any questions before I move on to my next topic?
[15:26] <belkinsa> Okay, moving on...
[15:27] <belkinsa> The next and final project that I'm a driver of is the  ProjectHarvest: http://wiki.ubuntu-women.org/ProjectHarvest
[15:28] <belkinsa> Harvest allows users to find small tasks for larger projects in the Ubuntu community
[15:28] <belkinsa>  The team is doing the testing phase that will hopefully allow Harvest to be opened up for the Ubuntu community and non-Ubuntu Women members
[15:28] <belkinsa>  Feedback is still welcomed and in a month or so, the feedback will be submitted to dholbach the driver of that project
[15:29] <belkinsa> These are the two projects that I drive and hopefully these two can help more women (and men!) to be involved with Ubuntu.
[15:30] <belkinsa> Thank you.
[15:30]  * belkinsa takes a bow
[15:30] <pleia2> thanks belkinsa!
[15:30] <pleia2> any questions?
[15:31] <pleia2> we'll be around for the remainder of the time if anyone things of anything
[15:34] <ClassBot> elfy asked: Any plans to try and get more women involved with flavours?
[15:35] <pleia2> great question :) right now our roadmap doesn't have that on our list, but we certainly do have a lot of folks on our team who represent other flavors and could probably help with this
[15:35] <pleia2> maybe it could even be something added to our quiz, do you use "Ubuntu, Xubuntu, Kubuntu..."
[15:35] <belkinsa> Indeed that can work and also maybe have the GetInvolved page have some links to the other favours team pages.
[15:36] <belkinsa> Sorry for the bad English there.  ;)
[15:36]  * pleia2 nods
[15:37] <belkinsa> Any other questions?
[15:39] <belkinsa> Oh, this is our team's wiki/website: http://wiki.ubuntu-women.org/
[15:50] <ClassBot> There are 10 minutes remaining in the current session.
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
[15:55] <pleia2> thanks for coming everyone :)
[15:58] <pleia2> the next session will be On Air, which means they're using Google Hangouts to broadcast a video-based session
[15:58] <pleia2> popey will share the link to join when it begins :)
[15:59] <belkinsa> Link to the page: http://ubuntuonair.com/
=== 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: [ON AIR!] Get Started Contributing to Ubuntu Core Apps - Instructors: popey
[16:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2014/04/23/%23ubuntu-classroom.html following the conclusion of the session.
[16:01] <popey> pleia2: it's at http://ubuntuonair.com/ ☻
[16:08] <pleia2> popey: it's not showing up, do you have a direct link that you can give to folks?
[16:09] <pleia2> ok, the live link is here: https://www.youtube.com/watch?v=M2mFNRRfPVo
=== 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: [ON AIR!] Get Started Contributing to Ubuntu Core Apps - Instructors: popey | Session live at https://www.youtube.com/watch?v=M2mFNRRfPVo
[16:14] <popey> pleia2: should be fixed now
[16:14] <popey> sorry about that
[16:50] <ClassBot> There are 10 minutes remaining in the current session.
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
=== ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Open Week - Current Session: Ubuntu Kernel Team - Instructors: jsalisbury
[17:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2014/04/23/%23ubuntu-classroom.html following the conclusion of the session.
[17:01] <jsalisbury> Hello Everyone o/
[17:01] <jsalisbury> Hello. My name is Joe Salisbury. I am a member of the Kernel Team at Canonical.
[17:02] <jsalisbury> 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.
[17:02] <jsalisbury> 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:
[17:02] <jsalisbury> QUESTION: What is an Upstream kernel?
[17:03] <jsalisbury> First, for details about the Ubuntu kernel, the top level Kernel wiki page can be found at:
[17:03] <jsalisbury> https://wiki.ubuntu.com/Kernel
[17:03] <jsalisbury> There is also a page dedicated to kernel bug triage, which can be found at:
[17:03] <jsalisbury> https://wiki.ubuntu.com/Kernel/BugTriage
[17:04] <jsalisbury> The kernel bug triage page is a great place to start if interested in learning more about triaging kernel bugs.
[17:05] <jsalisbury> The Ubuntu Linux Kernel has quite a large number for bugs opened against it.  Several thousand as of today.  A full list of bugs can be seen at:
[17:05] <jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux
[17:06] <jsalisbury> I generally focus on triaging and escalating bugs opened against the current development kernel.
[17:06] <jsalisbury> That's not to say there is no focus on the stable kernels.
[17:06] <jsalisbury> I review and triage each and every kernel bug reported, which could be against the current development kernel or any of the prior supported stable kernels.
[17:07] <jsalisbury> 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.
[17:08] <jsalisbury> 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:
[17:08] <jsalisbury> https://wiki.ubuntu.com/KernelTeam/StableHandbook/StableProcess
[17:08] <jsalisbury> Details on stable kernels can be found here:
[17:08] <jsalisbury> https://wiki.ubuntu.com/Kernel/Handbook/Stable
[17:09] <jsalisbury> 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.
[17:10] <jsalisbury> 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.
[17:11] <jsalisbury> After the bot sets the bug to 'Confirmed', I will review the bug.  Based on the bug description, I will see if the bug is similar to recent bugs and may be a duplicate.
[17:12] <jsalisbury> I will also determine what kernel subsystem the bug affects.  The bug might be specific to USB, wifi, graphics, suspend/resume, etc.
[17:12] <jsalisbury> I will ask subsystem specific questions to collect that specific data.
[17:13] <jsalisbury> The following wiki has some pages on specific debugging by subsystem:
[17:13] <jsalisbury> https://wiki.ubuntu.com/Kernel/Debugging
[17:13] <jsalisbury> 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.
[17:14] <jsalisbury> 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.
[17:15] <jsalisbury> 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.
[17:15] <jsalisbury> There is a wiki that describes how to report a bug upstream here:
[17:15] <jsalisbury> https://wiki.ubuntu.com/Bugs/Upstream/kernel
[17:16] <jsalisbury> 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.
[17:17] <jsalisbury> However, just because a bug is fixed upstream, doesn't mean a stable kernel will ever get that fix.
[17:17] <jsalisbury> Depending on the bug, we may also ask for testing of the latest upstream stable kernel.
[17:17] <jsalisbury> For example, Precise is based on the 3.2 kernel.  Currently Precise has all the upstream updates up to 3.2.55
[17:18] <jsalisbury> However, the latest upstream 3.2 stable kernel is 3.2.57.  Eventually Precise will get the 3.2.57 updates, so it is beneficial to know if the bug is already fixed there.
[17:18] <jsalisbury> If it is, we usually just need to wait until the bug is fixed when the release gets those upstream updates.
[17:19] <jsalisbury> 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.
[17:20] <jsalisbury> This can happen when a patch is submitted upstream, but does not include the Cc to the upstream stable kernel.
[17:21] <jsalisbury> 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.
[17:21] <jsalisbury> Before going down the debugging of a specific type of bug, lets step back to the bug triage flow.
[17:22] <jsalisbury> First a bot checks for the apport logs, then the bug is reviewed and a request is made to test the latest Mainline kernel.
[17:22] <jsalisbury> The next thing we need to know is if this bug is a regression or not.
[17:23] <jsalisbury> 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".
[17:24] <jsalisbury> If the bug is a regression, we can perform a kernel bisect to identify the commit that introduced the bug.
[17:24] <jsalisbury> The steps to perform a bisect can be found at:
[17:24] <jsalisbury> https://wiki.ubuntu.com/Kernel/KernelBisection
[17:24] <jsalisbury> 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.
[17:25] <jsalisbury> Basically we identify the last kernel version that did not have the bug and the first kernel version that did have the bug.
[17:26] <jsalisbury> 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.
[17:26] <jsalisbury> Using this information, I build a test kernel up to this commit and ask the bug reporter to test it.
[17:27] <jsalisbury> Based on the test results, I tell git whether or not the kernel exhibited the bug.
[17:28] <jsalisbury> Git will then spit out the next commit id(SHA1), which is again half way in between the last good and first bad commit.
[17:29] <jsalisbury> I then build another test kernel, ask for it to be tested, and feed the result back into git.
[17:29] <jsalisbury> Eventually this process will yield the SHA1 of the patch that introduced the regression.
[17:30] <jsalisbury> Then next step is determined by the patch/commit that introduced the regression.
[17:31] <jsalisbury> 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.
[17:32] <jsalisbury> Like I mentioned earlier there is also a "Reverse" bisect.  A reverse bisect is used to identify a commit in the upstream kernel that fixes a bug.
[17:33] <jsalisbury> This is basically the same process as a standard bisect, but git is told the opposite of the testing results.
[17:33] <jsalisbury> Eventually though the same process, git will report the SHA1 of the patch that fixes the bug.
[17:34] <jsalisbury> Depending on the patch, the fix will then be cherry-picked or backported and an SRU request submitted.
[17:35] <jsalisbury> Whether or not a bisect or reverse bisect is performed, depends on the bug.
[17:36] <jsalisbury> Usually the priority of the bug and/or the number of people affected will help decide.
[17:36] <jsalisbury> If you want to learn more details about git, there is a wiki page at:
[17:37] <jsalisbury> https://help.ubuntu.com/community/Git
[17:38] <jsalisbury> To track bugs, the kernel team created a variety of reports, which can be found at:
[17:38] <jsalisbury> http://reqorts.qa.ubuntu.com/reports/kernel-bugs/reports/index.html
[17:38] <jsalisbury> There is a report for all the supported stable releases, CVE's, bugs that are fixed upstream and a "Hot List".
[17:39] <jsalisbury> The "Hot List" or Priority bug list is used to track important bugs and get them on the kernel developers radar.
[17:40] <jsalisbury> That's a quick overview of kernel team bug triage.
[17:41] <jsalisbury> I hope it was not too high level :-)
[17:41] <jsalisbury> At this point, I'd like to open it up for questions.
[17:42] <jsalisbury> Again, 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:'
[17:44] <jsalisbury> Well, there does not seem to be any questions at this point.
[17:44] <jsalisbury> Again, if your interested in getting involved in kernel bug triage, the best place to start is by reviewing the wiki:
[17:44] <jsalisbury> https://wiki.ubuntu.com/Kernel/BugTriage
[17:44] <jsalisbury> I'm generally available on the Freenode channel #ubuntu-kernel
[17:45] <jsalisbury> Feel free to ping me there if you have kernel or kernel bug related questions.
[17:50] <jsalisbury> We have about 10 minutes left, so feel free to ask any Kernel related questions.
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:52] <jsalisbury> If there are no other questions, I'll wrap up the session at this point.
[17:53] <jsalisbury> Thanks everyone for attending, and thanks to our Community for making Ubuntu so great!
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
=== ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Open Week - Current Session: Ubuntu Quality Team - Instructors: balloons
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2014/04/23/%23ubuntu-classroom.html following the conclusion of the session.
[18:01] <balloons> Hello everyone!
[18:01] <balloons> Welcome to the ubuntu quality team session. My name is Nicholas Skaggs and I'm the QA Community Coordinator. Thanks for attending (or reading this log later!)!
[18:02] <balloons> This session is intended to introduce you to what the quality team does, some of the sites and tools utilized by the team, as well as how you can join and participate.
[18:02] <balloons> You may ask questions at any point.. Just be sure to utilize the #ubuntu-classroom-chat channel. Prefix your question with QUESTION: to ensure I see it.
[18:02] <balloons> Everyone ready?
[18:03] <balloons> So first I'm going to give a brief overview of what quality means and how the team works. Next, I'll talk about the different roles and activities we perform as a team. Along the way, we'll talk about the tools we use as well. Finally, we'll talk about how you can get involved and then do a Q & A.
[18:04] <balloons> So what does quality look like in ubuntu? What does it mean really?
[18:04] <balloons> I recently wrote a post that explains gives you an overview of what QA looks like inside of ubuntu, and where we as a community fit. http://www.theorangenotebook.com/2014/03/a-simple-look-at-testing-within-ubuntu.html.
[18:04] <balloons> Give it a read to help you understand more about the big picture of what is going on.
[18:04] <balloons> Simply put, we help write the tests that are automatically run against each image, in addition to providing manual verification and feedback. On top of that, we also help triage bugs and perform exploratory tests to discover things that our automated tests don't cover.
[18:05] <balloons> So we as a community plug in across the board; writing tests, tools and providing test results ;-)
[18:06] <balloons> We help ensure everyone's work in ubuntu is presented in the best possible way. We want to make sure things 'just work', and the culmination of work that results in the ubuntu image to be the best it can be.
[18:06] <balloons> To help accomplish this, we've defined several different roles on the team, each with a slightly different focus. Check out the roles on this page https://wiki.ubuntu.com/QATeam/Roles.
[18:07] <balloons> The roles help divide and define the different activities and things going on inside the realm of quality within ubuntu. As you can see there are roles for different skills and different skill levels
[18:07] <balloons> If you are new to the team, check out the tester role as a great way to move into helping out. Testers run the development version of ubuntu, and test new apps and code as it comes out. They also provide test results for milestones.
[18:08] <balloons> It's a very fun role.. Finding bugs, and helping track down problems is good fun! Plus, you get to see and experience the new stuff before everyone else.
[18:08] <balloons> Living on the edge has it's benefits and you will certainly grow in knowledge of ubuntu
[18:08] <balloons> Alternatively if you are unable to run the development release, the bug triager role allows you to help test stable updates and do bug triaging using a stable release (LTS or not) of ubuntu.
[18:09] <balloons> This is a handy role for those who want to be involved, but can't commit to living on the edge.
[18:10] <balloons> You can have a large impact in this role, helping to make sure the stable releases work well for everyone (you too!)
[18:10] <balloons> The final 2 roles are for folks interested in creating tools and testcases for ubuntu. Test writers write both manual and automated tests -- you don't have to be a programmer to write a manual testcase ;-)
[18:12] <balloons> Writing and maintaining our manual tests can be done by anyone who is able to break down things into instructions and write in english. The syntax is easy to learn, and we can help you understand how to propose your tests so they are accepted. It's a nice way to ease yourself into future development work, or just contribute in a technical way
[18:12] <balloons> Finally, developers work on the tools we use, and as such programming knowledge (and/or a desire to learn) is required.
[18:12] <balloons> If you aspire to any of the roles, we are here to help, so don't be overwhelmed
[18:13] <balloons> Ok, so let's talk a little about what we do overall as a team during the cycle
[18:13] <balloons> During the course of the cycle, we as a team participate by providing test results for the packages as they are undergoing development. If we find a bug, we'll also report and file it.
[18:13] <balloons> In addition, we develop testcases, best practices and even tools to help us test more effectively
[18:14] <balloons> Our goal is to be more confident and comfortable about what is being shipped as ubuntu. We want things to work, and we want to have tested as much as possible verifying that indeed they do work :-)
[18:14] <balloons> Our testing is done via several avenues. I'll describe each briefly.
[18:15] <balloons> The first thing we encourage is dogfooding the development version of ubuntu. This includes the phablet images as well if you have the hardware to do so ;-)
[18:15] <balloons> Simply install or upgrade to the development release and use it as a regular machine. By attempting to work and perform tasks under the development version you may encounter a bug.
[18:15] <balloons> Your usage of the development version represents a broad and unique testcase. Since you use the software on a regular basis you can also catch regressions and watch new features land.
[18:16] <balloons> Dogfooding is a very fun part of what we do, and it's my ecommendation for getting started with quality.
[18:16] <balloons> You can find out more about doing this under the tester role page (https://wiki.ubuntu.com/QATeam/Roles/Tester) via
[18:16] <balloons> https://wiki.ubuntu.com/QATeam/Roles/Tester#Exploratory_Testing
[18:16] <balloons> https://wiki.ubuntu.com/QATeam/DevelopmentInstall
[18:16] <balloons> https://wiki.ubuntu.com/QATeam/TouchTesting
[18:18] <balloons> Running the development version of ubuntu or your favorite flavor is a wonderful experience and with a little knowledge can be done by anyone wishing to get started
[18:18] <balloons> I encourage those of you wanting to jump in to start here, as I said.
[18:18] <balloons> Ok, so another activity we participate in is a call for testing.
[18:18] <balloons> This is a call to test a specific piece of software, with an accompanying set of tests and instructions for testing.  These calls generally occur as milestones for testing.
[18:19] <balloons> We take specific bits of software and run tests against them looking for functionality and regressions. You will see these announced on the mailing list, and scheduled on the calendar: https://wiki.ubuntu.com/QATeam/Calendar
[18:20] <balloons> So for instance, we as a community just helped in releasing trusty by participating in the milestone for the final images. We used the qatracker to provide the test cases (that we maintain as a team) and logged our results against the tool
[18:20] <balloons> These milestones happen every cycle, but others may occur as well to test specific software
[18:20] <balloons> Now, what is the qatracker you may ask?
[18:21] <balloons> The qatracker is where we submit the test results and get information needed to complete the test, such as the testcase and installation instructions.
[18:21] <balloons> It's a tool developed specifically for the purpose of coordinating our testing
[18:21] <balloons> Checkout the wiki page https://wiki.ubuntu.com/Testing/QATracker
[18:22] <balloons> There are actually several qatracker instances each geared towards testing different things;
[18:22] <balloons> http://iso.qa.ubuntu.com is used to report results for image testing
[18:22] <balloons> http://packages.qa.ubuntu.com is used to report results for package testing
[18:22] <balloons> http://laptop.qa.ubuntu.com is used for laptop/hardware testing
[18:23] <balloons> The tracker helps us work together as a team to perform these testing activities. The wiki page has more details about how it works and provides links to walkthroughs to help you get started submitting results. You'll also find links at the top of each of the trackers that explain how to use them and help you get started.
[18:25] <balloons> It's important that we get results for testing events, as positive results are just as useful as failures. Positive results allow us to feel confident in shipping things. Really the worst scenario isn't negative results, but a lack of test results
[18:25] <balloons> This is why a group of folks testing is a useful thing
[18:26] <balloons> The corner cases of when something works for me, but not for you is revealed.
[18:27] <balloons> So, we've covered contributing test results, and running the development release and contributing bug reports. Let's talk now about contributing tests themselves
[18:28] <balloons> The tests you see on the qatracker, and within the ci dashboard (which we'll speak more about in a moment) are a part of the output of our team's work.
[18:28] <balloons> You can help contribute to the testsuite by writing new tests or helping maintain the current ones
[18:29] <balloons> You can contribute both manual and automated testcases to ubuntu.
[18:29] <balloons> Manual testcases are intended to be run by human testers,  while the automated testcases can be run by a machine.
[18:29] <balloons> As a team, we maintain two projects the Ubuntu Manual Tests (https://launchpad.net/ubuntu-manual-tests/) and the Ubuntu Autopilot Tests (https://launchpad.net/ubuntu-autopilot-tests/) projects.
[18:29] <balloons> Tests are also found within the individual project trees, and we contribute tests there as well
[18:29] <balloons> For the qatracker, The Ubuntu Manual Tests project holds all of our manual test results. Everything you see on the various qatrackers like iso.qa.ubuntu.com is held in the source code repository.
[18:30] <balloons> The testcases are written in plain english, with a simple html syntax. You can see the format for our testcases here https://wiki.ubuntu.com/Testing/TestCaseFormat.
[18:30] <balloons> Anyone can contribute a manual testcase to the project and we welcome contributions :-) Checkout https://wiki.ubuntu.com/QATeam/ContributingTestcases/ for more information!
[18:31] <balloons> Again, I urge you to consider contributing in this area if you have good writing skills and the ability to write clear instructions for others to follow.
[18:32] <balloons> It's a skill to be able to convey technical information in a testcase, and we're always looking for good wordsmiths to help us
[18:32] <balloons> Now, on the automated testing side we deal mostly in three projects
[18:33] <balloons> The Ubuntu Autopilot Tests project holds the autopilot testcases for the desktop tests. Your favorite applications like gedit, rhythmbox, nautilus, the terminal, etc can be found here
[18:34] <balloons> Inside of lp:ubiquity we help maintain the autopilot tests that automated iso installation
[18:34] <balloons> This helps find breakages before we as human testers see the images.. Saving us time, and testing more often than we are able
[18:35] <balloons> Finally, we also contribute to the core apps projects
[18:35] <balloons> https://wiki.ubuntu.com/Touch/CoreApps/
[18:35] <balloons> These apps represent the core apps for the phablet images of ubuntu.
[18:35] <balloons> https://wiki.ubuntu.com/QATeam/ContributingTestcases/#Ubuntu_Touch_Core_Apps
[18:35] <balloons> If this interests you, I encourage you to have a read of http://www.theorangenotebook.com/2014/03/keeping-ubuntu-healthy-core-apps.html as well to understand how to help and what needs fixing
[18:36] <balloons> Each of the core apps (https://wiki.ubuntu.com/Touch/CoreApps) is under continuous development, adding features, etc. We help to ensure the apps work well by helping to maintain the testcases. You can find the test under each individual project on launchpad. Pick your favorite app and go have a look!
[18:37] <balloons> The goal of these automated tests are to augment our manual testing and provide a nice set of regression tests that can be run against each new image. Automated tests are great for spotting regressions since they can execute the same tests on EVERY image; something us as humans aren't as well suited to do.
[18:38] <balloons> So what happens to these automated tests after we write them?
[18:38] <balloons> They are run against every new image and the results are pushed to http://ci.ubuntu.com. This is part of our continuous integration process.
[18:39] <balloons> So for example we can see the results for the desktop images here: ci.ubuntu.com/smokeng/trusty/desktop/
[18:39] <balloons> Clicking on today's result for the amd64 image I can see the tests that were run and the pass rates: http://ci.ubuntu.com/smokeng/trusty/desktop/amd64/20140417/7777/
[18:40] <balloons> Well, actually, since trusty has just released this is a unique time and we're actually looking at the results from 4/17, the release day :-)
[18:40] <balloons> Good thing everything was passing eh? :-)
[18:40] <balloons> you can also see the phablet image results here: http://ci.ubuntu.com/smokeng/trusty/touch/
[18:41] <balloons> There are many tests which are run on each new build of the images. As you can see, often several images are built in one day
[18:42] <balloons> Automated tests are great for doing this much testing!
[18:42] <balloons> On the smoke testing page you can see the automated testing results for our daily images. Images are not published for manual testing until they meet a baseline criteria for installation via automated testing -- this helps us focus our testing efforts :-) In addition, you'll notice the phablet images are tested as well. New releases to devel and stable require these tests to pass as a first critera.
[18:44] <balloons> So in a nutshell, the automated test are run constantly and you can see the output on ci.ubuntu.com. More importantly, we can use the testruns to gate images and packages from releasing to us as testers until they pass the automated testsuite. This avoid us doing unnecessary work
[18:45] <balloons> So, that was a quick runthrough of many different things. In a nutshell we spoke about contributing test results and contributing testcases. To contribute test results, install the development version of ubuntu, and tackle some of the tasks found on the tester role page. https://wiki.ubuntu.com/QATeam/Roles/Tester. For contributing testcases, remember you don't need to be a programmer to contribute; we need manual tests as well. Checkout t
[18:45] <balloons> he test writer role page and the activities available to you. https://wiki.ubuntu.com/QATeam/Roles/TestWriter
[18:46] <balloons> Now I think it's time for some questions!
[18:49] <ClassBot> jose asked: When can we expect images for the unicorn for testing
[18:50] <balloons> Good question. The first images will come online as soon as the initial archive is created and synced. I would suspect to see the first images no later than early next week
[18:50] <ClassBot> There are 10 minutes remaining in the current session.
[18:50] <ClassBot> elfy asked: Any plans to increase visibility of testing for flavours - some had a few issues with no image testing at the end of the last cycle.
[18:52] <balloons> yes, in particular a couple of the flavors only release LTS's, so it's not something they are used to doing. We might consider doing some verification that folks will be around as needed from the flavors. I felt like the situation was well communicated, but perhaps the gravity of the final images wasn't well understood. It's imperative to have people ready to tests at the end of the cycle during final milestone testing
[18:53] <balloons> I also think we could do more to quell fears about upgrading or installing the RC image to help out. At that point in the cycle, we don't expect any problems at all. I suspect more folks could pitch in
[18:54] <ClassBot> elfy asked: Thoughts on a quality IRC channel that's for autopilot - the current channel appears to be orientated that way - anyone trying to get traction on something that *isn't* anything to do with autopilot soon gets drowned out.
[18:55] <ClassBot> There are 5 minutes remaining in the current session.
[18:55] <balloons> There is a #ubuntu-autopilot channel for AP help.. and it's decently used when working on autopilot things.. But certainly the -quality channel is a catch-all and I speak about many different things in it. If you are feeling like the conversation isn't conducive to getting help, we should chat more
[18:56] <balloons> I know I've worked on AP tests for hours in the channel, so if I'm generating noise, my apologies :-)
[18:56] <ClassBot> elfy asked: What smoketesting gets done for flavours in regard to results at ci.ubuntu.com?
[18:58] <balloons> The set of AP tests for images is being run against flavors, although it's not currently appearing on ci.ubuntu.com. You can see the results here. I've been trying to get those results posted on ci.ubuntu.com and hope it happens this cycle
[18:58] <balloons> Sorry, trying to find the link I want, 1 second :-)
[18:59] <balloons> https://jenkins.qa.ubuntu.com/view/Ubiquity/view/All/
[18:59] <balloons> viewing the raw jenkins output is not as nice, but the runs are happening and being watched :-)
[19:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2014/04/23/%23ubuntu-classroom.html
=== 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 || No Sessions Currently in Progress