• Archives

  • Categories:

  • Other profiles

5 ways to get involved today: Ubuntu Testing

At the Ubucon at Southern California Linux Expo on Friday, February 21st I’ll be doing a presentation on 5 ways to get involved with Ubuntu today. This post is part of a series where I’ll be outlining these ways that regular users can get involved with while only having minimal user-level experience with Ubuntu.

Interested in having a polished release but not able to contribute in a very technical way? Testing pre-releases is a great way to get started, even Mark Shuttleworth is getting in on the testing fun!

In this post, I’ll walk you through doing an ISO test, but there are also package and hardware/laptop tests that can be done, full details here: https://wiki.ubuntu.com/Testing/QATracker

Testing an ISO

Log on the the testing tracker

You will want to go to http://iso.qa.ubuntu.com/. The page can be a bit overwhelming at first, but there are two sections you’ll want to focus on, the log in button and the list of builds available for testing.

To log in you’ll need an account with https://login.ubuntu.com/, clicking on the “Log in” button will take you to a page where you can set up one or use your existing one.

Select a build to test

Most days the only build that is currently being tested is the “Daily” image – so in the screenshot above that is “Trusty Daily” and you’ll want to click on that link. The “Trusty Alpha2” and “Trusty Alpha1” images have already been released, so ISO testing on those is no longer necessary.

Select something to test

This screen can be a bit overwhelming too since it lists all the possible builds in the ISO tracker, which is a lot! I highly recommend using the Filters on the left hand side of the screen to select only the builds you’re interested in. In this screenshot I selected only Ubuntu and Xubuntu to make the list short.

Then you can look to see what you want to test. Do you have a new computer? You can test the 64-bit image isos, I circled where you want to click in the screenshot if you want to test the Xubuntu 64-bit ISO (I do!).

Select what test you want to do

At this next screen you will be presented with a series of tests that you can do. The easiest is “Live Session” since it doesn’t require you to install anything, it’s just testing a live session. You then also have various options for Installation-based testing.

But let’s say you have a virtual machine (Virtual Box is free and pretty easy to use for this) or a spare computer you want to do tests on, so for the purpose of this walkthrough we’ll select “Install (entire disk)” test case.

Download and prepare the ISO

Once you’re on the screen for the test case, there will be a link to downloading the ISO. There are many options for downloading, including just clicking it to download via http, downloading via rsync, zsync or torrent; you can read more about all of these options once you learn more about testing. For now, downloading it through http is fine.

While you’re waiting for it to download you can click on “Testcase” in the grey box below that to read through what you’ll be doing in the test case.

Once downloaded, either use the image directly in something like VirtualBox, or put it on a USB stick or burn a DVD.

Begin the test case

Scrolling down on the same page, you will see this:

This is where you will report the results of your test. The “Bugs to look for” are a list of bugs that others have reported that you may encounter, so you might want to look at some of those and include those bug numbers in your test if you encounter them too.

A quick rundown of the meaning of each field is as follows:

Result: Whether or not you were able to get through to the end of the test case with no fatal errors

Critical bugs: Bugs that prevented you from finishing the test case (would generally go along with “failed” above)

Bugs: Bugs that exist, but you were able to work around them and finish the test case (it can be marked as “passed” and still have bugs)

Note: Don’t stress too much over whether you believe a test is really passed or failed and whether bugs are critical or not, there is some judgement involved in here and results are reviewed by release managers who decide whether the ISO is ready for releasing. Just do your best!

Hardware profile: This is an optional field that can give the team an idea of what your hardware is. Using a virtual machine? Actual hardware? How much RAM and what type of graphics card? Put as much information as you can online somewhere and paste your link here. For example, here’s the testing profile I use for my Lenovo G575 and another for when I test in a 1.5G RAM virtual box instance. You can also choose to use the “hardinfo” command to generate information about your hardware and put it online somewhere.

Comment: You can add any additional comments you may have about doing the test case

If you run into any bugs while doing your test, you will need to submit those bugs for them to be recorded. For this you will need an account on launchpad.net, if you don’t have one, get one by clicking here. Once you submit a bug you’ll want to add that bug number to your list of Bugs (or Critical Bugs). Learn more about reporting bugs here.

Note: Reporting bugs can be hard, particularly determining what package to file them against, even I still struggle with this! My recommendation is to do your best, make sure you add your bug to the tracker so people notice it and ask for help on the ubuntu-quality mailing list if you’re really unsure.

Done

Click “Submit Result” and you’ll be finished reporting a test case! The Ubuntu community thanks you :)

Learn more about testing

A more thorough walkthrough with more screenshots can be found here: https://wiki.ubuntu.com/Testing/ISO/Walkthrough

You can sign up for and email the ubuntu-quality mailing list to introduce yourself and ask any questions you may have, they’re a friendly bunch.

Visit the Quality Assurance Team wiki for more about other kinds of testing.

Previous posts in this series

5 ways to get involved today: Ubuntu User Support

At the Ubucon at Southern California Linux Expo on Friday, February 21st I’ll be doing a presentation on 5 ways to get involved with Ubuntu today. This post is part of a series where I’ll be outlining these ways that regular users can get involved with while only having minimal user-level experience with Ubuntu.

One of the most valuable things about using Ubuntu is the vast wealth of help available from fellow community members. Most of the time when I have a problem, I can search for an answer and find one, or ask on one of the several support outlets that exist.

Help

Helping out others was one of the first ways I got involved, and there are many benefits to having this be yours too.

Gentle learning curve

You may need to learn forum or mailing list etiquette, but otherwise you just jump in and help folks with things you know how to help out with. There are no requirements to have special training and you don’t need to know everything. If you’ve been using Ubuntu a few days longer than someone else, you can probably help them out.

No set time commitment

You can help as much or as little as you want. There is very little investment in getting set up with help resources made available by the community and you can spend all day answering questions or just answer one question per week. It’s all up to you.

There are many outlets for helping

Love forums? Prefer Stack Exchange? Or mailing lists? Want to help via IRC? You have many options! The following are the core help areas for the Ubuntu community:

If you’re more interested in passive support, documentation contributions and improvements are always welcome and needed on the Community Help Wiki.

You’re making a difference

It may seem like an easy way to contribute, but you’re lending your talents to one of the things that makes our community great. Regardless of how much you contribute, every person you help is someone who is no longer stumped with their issue and that makes a difference.

Sharing the Beauty: Architecture Class

Back in December I attend a couple classes at Congregation Sherith Israel here in San Francisco aimed at teaching congregants and potential docents about the physical and historical aspects of the building, which is listed on the National Register of Historic Places.

Previous posts:

Classes resumed on Sunday morning with local architect Arnie Lerner who gave us a tour of the interior of the synagogue from the perspective of architecture.

The outside of the building itself is masonry, made of brick covered with sand stone and a steel structure. In interior has a significant amount of painted plaster covering the walls, including up inside the dome. As we learned in a previous class the style of architecture is Beaux-Arts.

Most interesting to me was some of the changes over time and what had been restored. The massive rose window that can be seen from outside, and several of the stained glass windows, have been restored. I had never been up to see the rose window from the inside before, so this was a nice opportunity to take some pictures.

We also learned that the series of front doors had actually been replaced with steel doors sometime in the mid 20th century, with the wooden doors being kept in the partial basement. During a restoration several years ago the doors were brought out of storage and restored, which I’m sure was a vast improvement!

The building also recently had illuminated exit signs and emergency evacuation lighting installed a couple years ago in order to improve safety in the building.

In spite of the suriving the 1906 earthquake (and being one of the few major buildings in the city that did), the building is also undergoing a major seismic right now, were they’ve been working to further strengthen the building. Arnie brought along a core that had been drilled during the process of “core drilling” that is being used. He even brought along a piece of the core so we could get an idea of how big of a space they had to drill to insert the reinforcing rods.

“Core drilling: a type of vertical reinforcement of masonry walls that relies on drilling a continuous vertical core that is filled with steel reinforcing rods and grouting to resist in-plane shear and out-of-plane bending.” via The Seismic Retrofit of Historic Buildings

From there we then did a long walk around the building, going through the main sanctuary and up the stairs to where the organ is, where we were able to hear a bit more about the building interior.

I also had a nice opportunity to take some close up pictures of the stunning Moses at Yosemite window:

Amusingly, some have said that Moses looks like John Muir, which they say could actually be possible given his influence at the turn of the century when the windows were being produced.

Unfortunately due to the heavy rain we weren’t able to do a tour of the outside, so instead we took time to go up inside the dome, where I had been before but this was my first time during the day.

I have uploaded photos I took during the class here: http://www.flickr.com/photos/pleia2/sets/72157640737135955/

We have the rest of the month off, but I’m looking forward to the 2 classes coming up in March:

  • 3/2 Stained Glass – Ian Berke
  • 3/23 Organ – Jonathan Dimmock

5 ways to get involved today: Ubuntu Documentation

At the Ubucon at Southern California Linux Expo on Friday, February 21st I’ll be doing a presentation on 5 ways to get involved with Ubuntu today. This post is part of a series where I’ll be outlining these ways that regular users can get involved with while only having minimal user-level experience with Ubuntu.

Welcome back! In this second post I will take the opportunity to introduce you to the Ubuntu Documentation team.

Ubuntu Documentation

Like the Ubuntu Weekly Newsletter that I mentioned in my last post, this effort is completely volunteer-run and pulls in community members from throughout the Ubuntu desktop and server community and the flavors. The team is small, but over the past year it’s been growing and could really use some new contributors.

One of the easiest ways to get involved is by reviewing the development version of the Desktop documentation and submitting bugs when you find issues. Review can be in the form of grammatical review or technical review, and we can always use folks who are keeping up with new features so we’re sure to document them.

You have a couple of options when it comes to doing review.

1. Review the 13.10 documentation on the web

https://help.ubuntu.com/13.10/ubuntu-help/

This is the easiest way to quickly get involved. Your task here is reviewing this documentation and seeing if there are any errors or updates to be made for the upcoming 14.04 release.

Tip: We have already updated some of this in the latest development version for 14.04, but there still may be errors to find so reviewing this is useful to us.

2. Build the current development documentation as html

This is a bit more involved because you have to install some things on your system, but it’s the best way to help us because you get the latest version of the documentation that’s currently in development!

The steps for building are as follows:

  • Install the following packages: bzr xsltproc libxml2-utils yelp-tools yelp-xsl
  • At the command line, type: bzr branch lp:ubuntu/ubuntu-docs (this took several minutes for me, be prepared to wait!)
  • Change to the new ubuntu-docs html directory: cd ubuntu-docs/html/
  • To build the HTML documentation, just type: make
  • View the resulting HTML documentation in the html/build/en/ directory. I did this in my home directory, so I just opened file:////home/elizabeth/ubuntu-docs/html/build/en/index.html in my browser (replace “/home/elizabeth/” with whatever directory you ran the bzr command in)

Tip: When reviewing documentation built on your system keep an eye on the address bar to make sure the pages you are reviewing are still your local file:/// ones, there are some links in the documentation that take you to other sites.

Reviewing instructions

To prevent everyone from reviewing the same few pages over and over again, we’ve created a spreadsheet to track which pages still need to be reviewed. Visit the spreadsheet and find a page that hasn’t been reviewed yet and add your name to the Reviewer column. If all the pages have been reviewed once, feel free to pick a page and review it a second time!

The Ubuntu Documentation adheres to the style guide here: DocumentationTeam/StyleGuide. Of particular interest may be the Grammar, Punctuation, and Spelling section. Also note that the Ubuntu documentation uses US English spelling and grammar rules.

If you find a bug, please report it here: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+filebug

Tip: All screenshots are done at the end of the cycle once the UI has frozen, this is done automatically by a team member so it’s typically not required to submit bugs related to screenshots.

If you have any questions or run into any problems, please feel free to email the Ubuntu Doc mailing list at ubuntu-doc@lists.ubuntu.com or chat with us in the #ubuntu-doc IRC channel on irc.freenode.net.

And when you’re ready to go beyond review? Full instructions for contributing (including submitting changes in Mallard rather than submitting bug reports!) here: DocumentationTeam/SystemDocumentation/UbuntuDesktopGuide

5 ways to get involved today: Ubuntu Weekly Newsletter

At the Ubucon at Southern California Linux Expo on Friday, February 21st I’ll be doing a presentation on 5 ways to get involved with Ubuntu today. This post is part of a series where I’ll be outlining these ways that regular users can get involved with while only having minimal user-level experience with Ubuntu.

In my first post of this series, let’s take a look at the Ubuntu Weekly Newsletter!

Every week, the Ubuntu Weekly Newsletter is read by thousands of community members, it’s cross-posted to several resources so for the release of issue 353 on Monday you could find it via:

Contributing to the newsletter is a great way to contribute to something that community finds valuable.

I’m happy to say that today we have some really exceptional work coming from Paul White who participates from beginning to end: link collection, summary writing and editing. We recently gained Emily Gonyer who has been putting in tons of effort each week on summary writing and keeping an eye out for accuracy of articles. And finally, we still regularly have Jim Connett popping in for editorial review at the end of the release cycle.

But we don’t want to burn out these contributors! It’s a lot of work to put together the newsletter every weekend, and we need folks for the following:

Summary writers. Summary writers receive an email every Friday night/Saturday morning with a link to the collaborative news links document for the past week which lists everything that needs summarizing. These people are vitally important to the newsletter. The time commitment is limited and it is easy to get started with from the first weekend you volunteer. No need to be shy about your writing skills, all summaries are reviewed before publishing so it’s easy to improve as you go on. We also provide Style Guidelines to help you out (and you can always look at past issues!).

Editors. Our editors receive an email every Sunday night/Monday (depending on our timing and your time zone) with a link to the wiki page ready to be reviewed. Editors check for grammar, spelling, formatting and other consistency issues. Good written English skills, attention to detail and willingness to adhere to our style guidelines required.

Interested in either of these? Email editor.ubuntu.news@ubuntu.com and we’ll get you added to the list of folks who are emailed each week and you can help as you have time. Please specify whether you are interested in summary writing or editing when you contact us. And if you find you can’t participate or want to be removed, you can always be removed from the list of people contacted each week, just ask :)

OpenStack Infrastructure February 2014 Bug Day

The OpenStack Infrastructure team hosted our last bug day back in December. Since then, elastic-recheck has become a pretty big deal and the community has had to become more diligent about rechecking against actual bugs in the infrastructure, meaning our bug tracker has been much more active! In general, the team has been doing a better job of keeping track of new bugs coming in, so our stats for today didn’t show the kind of dramatic drop that some might hope for.

But these days are still valuable to us! Even I found a couple bugs where I could offer updates, we were able to take time to triage a bunch of New bugs that hadn’t been touched, and shuffle around priority of many others. It’s a great time for us to get a higher level view of everything on our plates so we can make plans accordingly.

Ladybugs

First, I created our etherpad: cibugreview-february2014 (see etherpad from past bug days on the wiki at: InfraTeam#Bugs)

Then I run my simple infra_bugday.py script and populate the etherpad.

Then I grab the bug stats from launchpad and copy them into the pad so we (hopefully) have inspiring statistics at the end of the day. Once bugday makes it into infra proper I hope to update that to include us too, there is a bug for that, and now a review!

Then comes the real work. I open up the old etherpad and go through all the bugs, copying over comments from the old etherpad and making my own comments as necessary about obvious updates I see (and updating my own bugs).

Last step: Let the team go to town on the etherpad and bugs!

Here are the stats from today:

Bug day start total open bugs: 266

  • 45 New bugs
  • 45 In-progress bugs
  • 5 Critical bugs
  • 17 High importance bugs
  • 4 Incomplete bugs

Bug day end total open bugs: 245

  • 0 New bugs
  • 46 In-progress bugs
  • 5 Critical bugs
  • 22 High importance bugs
  • 17 Incomplete bugs

Nice work, thanks again everyone!

And it’s February on the home side

Work and projects have certainly kept me busy, but I’ve also had time for home, self and family things.

Caligula wasn’t the only one who had some dental work done, both MJ and I had to go in at the end of January. I was reminded the hard way that Novocaine upsets my stomach, but aside from the queasy afternoon everything went well.

In the midst of being so busy lately, I realized I should probably work to get out to socialize more outside of work/conference/event things. I do have friends in the city now, so I really need to do a better job of reaching out to them when I’m feeling lonely.

Last week I finished off the 5th week of Couch-to-5K with a brutal 20 minute run, thankfully for week 6 it was back to a mix of running and walking. It was cool to learn that I could run for a full 20 minutes though, even if it was painful and difficult!

Last week my Aunt Mary and Uncle Joe were in town for a conference and I was able to meet up with them for a couple meals. Early in the week we met up for drinks and then for a great dinner at Zero Zero. On Saturday we met them in the late afternoon for a quick visit to Pier 39 (sea lions! view of Alcatraz!) before we drove over the Golden Gate Bridge for an exceptional dinner at Murray Circle Restaurant at Cavallo Point. Afterwards we spent a bit of time there at Fort Baker soaking in the view of the city and the bridge.

The weekend wrapped up with some work at home. We finally received the last lamp we ordered from the bedroom, and also were able to take time to hang the mirror we bought with the first lamp.

It’s so nice to finally have a mirror over the dresser! And with this completed our bedroom is pretty much done. I think completing the living room will be our next project.

We also have our computer project to complete, getting our media server and storage server online. I was reminded of this even further when I got on my desktop this morning and was confronted with a wall of filesystem errors. I’ve put in an order for a couple new drives, which is not what I had planned on doing this week, but will finally give me the opportunity to set up RAID1 for my desktop so I don’t need to be quite so worried about drive failures (I keep backups, but, you know).

A couple articles, PyCon and a keynote in Croatia

It’s hard to believe that January is already over. It was quite the full month with my trip to Perth and then a lot of work and project stuff happening. Looking at my calendar for the year I seem to have a pretty full schedule, during which I’m also dying to squeeze in a visit to my youngest sister and my nephew in Maine (aiming for March).

Last month I was happy to see my Code Review for System Administrators article come out in the January issue of USENIX ;login: logout. It’s an online-only publication but it was great to be able to transform the talk I’ve given on the subject to text, and working with Rikki Endsley is always a pleasure. I was also interviewed several months back my comments made their way into Issue 180 of Linux Format in Jono Bacon’s Equality and open source article.

Apologies for the pay wall for both of these articles, if you’re a USENIX member you can grab the ;login: logout article, and the Linux Format one should be available for general consumption in the next few months.

Logout

In conference news, I’m officially one of the TAs for the Build your own PiDoorbell! Learn Home Automation with Python workshop at PyCon 2014 in Montreal in April. I’ve never attended a PyCon and I’m super excited about meeting up with Akk, Rupa and the other TAs to start learning what we’ll be teaching others. I’m thinking I’ll set up my motion sensor next to Simcoe’s food bowl so I can make sure Caligula doesn’t eat her food. I’ll also be pitching in at the HP booth during the conference days.

PyCon 2014

I also learned on Sunday that not only is HP going to be a sponsor of DORS CLUC 2014, a Linux User Group Convention in Zagreb, Croatia in June but will be giving a keynote! I’ll be there to talk about the fully open source Continuous Integration system that we use for the OpenStack project. Bonus, this will be my opportunity to finally meet Jasna Benčić, a rising tech star who I met through work on several Ubuntu projects a couple years back, including her tireless work on the Ubuntu Weekly Newsletter and Ubuntu Learning.

DORS CLUG

I’ve put in a few more talk submissions to other conferences, so it’s shaping up to be a really exciting year.

Ubuntu California planning for the Southern California Linux Expo

The Ubuntu California team does a lot of small events throughout the year, from release parties and jams to regular Ubuntu Hours all over the state. But our big event of the year is always the Southern California Linux Expo.

We kick off the expo with an Ubucon on SCaLE’s Friday of miniconfs.

Ubucon

I’ve had the pleasure of being invited to speak at this event for the past few years, and this year is no exception! The Ubucon lineup for Friday the 21st is as follows:

My 5 ways to get involved with Ubuntu today talk will cover ways that regular users can get involved with while only having minimal user-level experience with Ubuntu. In preparation, this week I’ll also be launching a series of posts where I’ll be outlining these ways as a bit of a sneak peek as to what to expect during the talk.

On Saturday and Sunday the team will be running an Ubuntu booth in the expo area. Over the years we’ve gotten quite skilled at knowing what we should bring and have used the wiki to list out everything we need to have folks sign up to volunteer and bring things:

https://wiki.ubuntu.com/CaliforniaTeam/Projects/Scale12x

This year I’m fortunate to have Robert Wall making the trek down to SCaLE by car, so he can bring along all the booth items I signed up for (no stuffing them in my suitcase!) as well as having him on booth duty. Also thanks to Philip Ballew, Stephen Briles, Mickey Lyle, Matt Mootz and José Antonio Rey who have already signed up for booth duty throughout the weekend. We also have System76 to thank for providing us a couple demo laptops for the booth and the rumor is Canonical has loaned us a couple of phones running Ubuntu to show off too.

SCaLE11x booth
Our booth at SCaLE11x in 2013

I’ll be dropping by the booth as time allows, but I learned a couple conferences ago that I don’t have the energy to run a booth all weekend and speak at a conference. My second talk of the weekend will be at the main SCaLE conference on Code Review for Systems Administrators on Saturday at 6pm, where I’ll be talking about the system we use for the Infrastructure team of the OpenStack project (my day job!).

Simcoe’s January vet visit and Caligula’s cold

Simcoe’s last vet visiting to do an analysis of her blood levels was back in November. Since we noticed her levels were creeping up at the time, but she also had some sniffles, perhaps that impacted results? We came up a plan with the vet to recheck her in 2 months (rather than 3) and went ahead and scheduled her appointment to coincide with some dental work Caligula was having done.

We dropped Caligula off at the vet the morning of January 25th and commenced worrying about him all day. Unfortunately those sniffles I mentioned Simcoe having back in November were ones that had continued with Caligula over these past couple months with varying severity. We put him on antibiotics in mid January, but they decided to do a sinus x-ray prior to the dental work to figure out what was going on and whether they could go on with the dental work. He was still congested so they decided to give him an antibiotic shot this time and go ahead with the dental work. He came out from the dental work a bit drugged but ok. They followed this up with a culture to see if he had a bacterial infection.

Results from the culture came back Wednesday, he has a strain of Pseudomonas. It’s resistant to both antibiotics he’s already been on so we picked up a third type yesterday and started the treatment last night. Simcoe is sniffling again too, so we my need to put her on it too.

When we went to pick up Caligula following his dental work, we had scheduled a vet visit for Simcoe. Since he had the cat carrier, we put her on a harness and lead to go to the vet, which she really was not at all happy with, she prefers being able to hide in her carrier.

The exam went well, she’s continuing to maintain a health weight, which is always a good sign for a cat with renal failure. Last visit she was 9.5lbs, this time she’s 9.6lbs.

Unfortunately both her BUN and CRE levels have gone up a little, 53 to 57 on BUN and 3.5 to 3.6 on CRE.

BUN: 57 (normal range: 14-36)
CRE: 3.6 (normal range: .6-2.4)

This is something to continue to keep an eye on if the trends continue in this direction.

For now we’re back on the 3 month check in schedule and will handle her sniffles as needed, hopefully this round of antibiotics will do the trick for Caligula.