The Testing Team is responsible for using formal test cases to check images of Lubuntu. This allows the Release Team to easily gauge the health of the images. This makes it possible to tell whether an image is functional enough to justify a release and determine where resources need to be allocated to make sure an image gets released.
Testing consists of:
Our most important job is preparing for release. A few days before a milestone is due (according to our release schedule), the daily is plucked and becomes the QA (Quality Assurance) test version (these are called Alpha, Beta, and Final). Once it is confirmed that the QA version works, it then becomes the released version.
- Daily images are constantly being tested to give us an early warning notice of any problems that could affect Milestone releases. This also gives us an opportunity to do more heavy testing to discover any bugs we hadn't noticed before.
- Specific testing allows us to help with development.
For more information about testing, please see the Main QA team.
There are blueprints for 15.04. Keep watching there for the official plan and work to do this cycle, which will dictate our focus. The real question is whether or not LXQt will be included or not (though it WILL come in the future).
- Lubuntu 14.04 point releases are maintenance releases, do not expect too many changes. Daily testing and milestone testing will be needed here.
- Lubuntu 14.10 is now released.
Lubuntu 15.04 Beta 1 is now released. Daily testing and milestone testing will be needed here, as we continue to work towards release. Find more details here.
- Lubuntu 15.04 carries on towards final release via the isotracker.
Get a Launchpad account and join the Lubuntu QA team.
Join the main mailing lists so that you receive information about where Lubuntu is heading. Use the lubuntu-qa list for testing discussions.
- On Freenode IRC, join #ubuntu-quality and #ubuntu-release. Note these are general channels shared across all flavors, so you may want to use #lubuntu-devel for specific questions about Lubuntu. #lubuntu is another option but we try to keep this specifically to support, so it's not recommended.
Before you get started
This section is dedicated to the current development version of Lubuntu. As with all alphas and betas they are not suitable for a production environment, please take the time to read Common Questions for Testing.
Whenever you are testing, keep in mind these few notes:
- Using a Development Release is not suitable for daily production machines. That is why, to play it safe, it's better to use virtual machines, spare testing machines and/or USB drives, especially with Alphas. Beta Releases are a bit more stable but still under heavy development.
The most important part of testing is to actually install the system and check how the installation process will work. This is very important. Also, if you have say Alpha 1 installed, it is less helpful to just upgrade it to Alpha 2 or Beta 1. Please, do a fresh new install.
Always make sure to how to MD5SUM of the downloaded ISO as well as the media it's installed on. If either is off by a single bit, it can cause all sorts of inexplicable problems.
Most testing is done with virtual machines, but if you want to install to a hardware system, that's helpful, too. If you do this, make sure to Backup your important data. If you are using Linux, the best and easier way is to make a copy of your /home folder or partition. If you want to do a full system backup, please see this link and this link too.
To save downloading the whole iso again for the testing version, simply copy your trusty image of what ever architecture replacing the old codename with the new one, e.g. 'trusty' with 'utopic' and use zsync.
What to do when
Familiarize yourself with the release schedule. The dates listed for the release of milestone images are typically on Thursday. Two days before that, on Tuesday, images are made available for final testing
Be sure to watch out for point releases on LTS images, too. They often come in the middle of cycles on the development release.
We must have formal testing done and any showstopper bugs resolved within the two days. This doesn't allow for a lot of room for errors. Because of that, it is imperative that the week before official testing opens up, we do daily testing. Make sure to report all successes, failures, and bugs on the ISO tracker.
When images build
The Alternates take approximately 30 - 45 minutes to complete. The Desktops take approximately 90 minutes to complete.
The timing of the auto builds can be found here.
You can also see the status of images at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/RELEASENAME/lubuntu (change RELEASENAME to something like trusty, utopic, vivid, etc). Note if it says successfully built, that does not mean it's uploaded to the tracker yet.
You can also see the logs of automated builds. This is a good way to troubleshoot why an image is not there.
Jenkins runs automated tests. In particular, there's one that deals with Ubiquity that would be a good way to see if we're having problems with the Desktop ISO.
Problems with images
If you do notice that builds are not appearing as expected, please contact wxl and let him know or check with #ubuntu-release.
- all of the architectures or types not being represented
- old daily versions (the version in the form YYYYMMDD should be today's date)
NOTICE: always subscribe Lubuntu Packages Team to bugs encountered within Lubuntu.
Within bugs related to Lubuntu, you will see bugs raised by, or allocated to Julien Lavergne. Please feel free to add to the comments but do NOT alter the status of these bugs as they are being dealt with by our head of development in readiness for the fix being released.
Please head over to All about bugs for further information on how bug reporting works and why it is so important, as well as how to write a proper bug report.
An important part of QA is not only making bug reports, but making them in such a way that they can be triaged. Additionally, triage should be something that QA considers part of their workload. Bug reports are there to help developers know what to work on next. The only way development happens is if these bug reports are clear and clearly marked. That being said, look at the Bug Squad for info on how to write and triage reports. There is a subteam called Bug Control that you need to be approved for that can handle changing all statuses and priorities.
Except for Ubuntu Server, Lubuntu is the only flavor supporting Power PC machines. Currently, the focus is on LTS only.
During the release cycle, things will get broken. You can really reduce these occurrences by taking the time to read Partial Upgrades.
Some packages can be automatically installed, but are not wanted on a default installation. To find the package which automatically installed the package that you don't want :
run apt-rdepends -r --show=Depends the_unwanted_package => It will show which packages depend on the_unwanted_package.
run apt-rdepends -r --show=Recommends the_unwanted_package => It will show which packages recommend the_unwanted_package (Recommended packages are installed by default).
- You may have to run the commands several times to see the complete chain of depends / recommends.
These iso's are automatically generated every 24 hours using the latest updates on the system from the devs. They are available from ISO tracker. They are there to check that bugs that are resolved between the Milestone releases do not break the install. They also are used to confirm that any fix for a bug that seriously affects an initial install which is released for testing now works. Daily builds are suspended when pre-milestone testing is being carried out. There is a process for re-initiating the dailies after the cycle is over. Assuming we have a name, it should happen fairly quickly, as it's dependent on that.
Alpha, Beta and Final (formerly known as Release Candidates (RC)) are also tested using ISO tracker. If you want to help out in this important area of testing, please read through Procedures for further details. These appear a couple of days before the actual Milestone release so that we can check they are okay to become Milestone releases.
Once a Milestone release passes the QA testing, it becomes a Milestone Release and is listed on the Releases as such.
Note this also includes point releases on LTS versions. Basically, a point release brings in all the various bug fixes into one 'new' image. To get in to the build they have to pass SRU testing.
If you would to know more about how this all works, have a read of Stages of testing.
You can do more specific tests, like ones done for the Ubuntu ISO.
Laptops never cease to have their little 'quirks'. You can help on this important area by heading over to Laptop Testing for full details.
Applications test cases
You can also test specific programs :
You can test some aspects of Lubuntu performance with the following programs :
gtkperf : Test the performance of the gtk theme.
phoronix-test-suite: General benchmarks and test suite.
bootchart : Test boot process.
Sometimes during the test cycle one of the developers may ask you to test something specific for them, or their team. For more details of this important area, head over to PPA testing
There are now packages for LXDE components built from upstream git, and re-built when a new revision is committed. It's hosted on the daily build PPA for Lubuntu-dev, packages for currently supported releases plus the development release are available. If you are working on a Lubuntu bug, please do test with these ppa areas to check if it has been fixed upstream.