Testing

Differences between revisions 21 and 22
Revision 21 as of 2013-08-30 15:07:08
Size: 10346
Editor: aldomann
Comment: Use code markup for commands to make them more clear.
Revision 22 as of 2013-09-04 16:05:55
Size: 10392
Editor: amjjawad
Comment:
Deletions are marked like this. Additions are marked like this.
Line 55: Line 55:
##https://wiki.ubuntu.com/UbuntuGNOME/Testing/Activities
Line 56: Line 57:
'''Please head over [[https://wiki.ubuntu.com/UbuntuGNOME/Testing/Activities | Testing Activities Page]] for more information about our Testing Activities and possible test case scenarios'''. '''Please head over [[https://wiki.ubuntu.com/Testing/Activities | Testing Activities Page]] for more information about our Testing Activities and possible test case scenarios'''.

Testing Ubuntu GNOME

This section is dedicated to the current development version of Ubuntu GNOME. As with all Alphas and Betas they are not suitable for a production environment, please take the time to read Common Questions for Testing

13.10 Alpha 2 has now been released, we are now back on the dailies.

For Ubuntu GNOME Saucy Daily Build, please see this.

Please read the release notes for Alpha 2.

Before Getting Started

Testing and using Development Releases of Ubuntu GNOME (or any other flavor of Ubuntu) isn't meant to be for production machines of daily usage. Testing is to make sure the Stable Release is working as good as possible. Find Bugs, Improve Performance, etc - this is what we do until we finalize the testing process and release a stable version. Whenever you are testing, keep in mind few notes:

  1. 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.

  2. You can use Virtual Machines - for example See this. You can use USB Drives or External HDD. You can use your machine. That is totally up to you but please, refer to #1 Smile :)

  3. Using a Development Release is not suitable for daily production machine.
  4. The more you break your installation, the better. That is why, to play it safe, better to use Virtual Machines, Spare Testing Machines and/or USB Drives, specially with Alpha 1 and Alpha 2. Beta Releases are a bit more stable but still under heavy development.
  5. Finally, always remember: Better Safe Than Sorry Smile :)

Getting Involved

I am NEW to Testing, How Can I help?

Congratulation, you are the best and perfect candidate who actually can help us testing a development release. If you are new to all this, please read this page. If you have any question, join the mailing list and just ask Smile :)

Ubuntu GNOME Mailing List

Please do join our Mailing List - this is VERY important.

After you join the mailing list, please send an email to introduce yourself. Don't be shy, we don't bite Wink ;) so, Keep Calm and Join Ubuntu GNOME Mailing List Smile :)

Share Your Findings or Ask Qs

When you compose New Email, please write [Testing] in your subject so everyone on the list will understand what your email is all about - that you are a tester and helping out.

It is VERY important to share your findings with the team. Also, you can ask anything on the mailing list as well. So, it is a must-do step Smile :)

Testing Activities

Please head over Testing Activities Page for more information about our Testing Activities and possible test case scenarios.

Use Raring ISOs

To save downloading the whole iso again for saucy, simply copy your raring image of what ever architecture replacing 'raring' with 'saucy' and use zsync. (You can, of course, simply do a mv, but I like to keep my older iso's handy).

Bugs

Please head over to All about bugs for further information on how bug reporting works and why it is so important. Also, please see How to Report Bugs.

Testing

Testing is split into distinct, but joined areas. The Daily Builds, the QA-testing of Milestone releases and the Milestone releases themselves.

To not get overly complicated, think of it as that we have a schedule to keep to. A few days before a Milestone is due, the daily is plucked and becomes the QA (Quality Assurance) test version for the Milestone release. Once it is confirmed that the QA version works, it then becomes the Milestone.

All release stages are tracked by ISO Tracker where you can get the latest builds, see and allocate any Bugs.

So, in order of how they happen.

Daily Builds

These ISOs are automatically generated every 24 hours using the latest updates on the system from the developers. They are available from ISO tracker. Using the zsync (or rsync) option allows you to update your iso to any of the various dailies you choose to follow without having to re-download the entire iso. 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 (see below).

When do they build?

The Desktops are scheduled to start at 16:29 (UTC) and take approximately 90 minutes to complete

Please note from the release team: Sure, as long as it's clear that it's subject to change - We're not intending to make any promises here. We won't change them around frivolously or anything but it's possible.

The timing of the auto build of Ubuntu GNOME can be found here. If you do notice that builds are not appearing as expected, please contact amjjawad to let him know or just drop an email to Ubuntu GNOME Mailing List.

QA testing of Milestone releases

Cadence, Beta and 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.

QA testing is to ensure the actual install iso works, if you can, please get involved in the qa testing

Rebuilding a Release Candidate

These are carried out manually, during this time the release team do update the notice panel. Please ask on #ubuntu-release if you have questions.

Milestone Releases

Once a Milestone release passes the QA testing, it becomes a Milestone Release and is listed on the Releases as such.

If you would to know more about how this all works, have a read of Stages of testing.

General Testing

During the release cycle, things will get broken. You can really reduce these occurrences by taking the time to read Partial Upgrades.

Known Issues

All the known issues for a particular release are mentioned in the Announcement email, and are available to see at ISO Tracker.

Manual test of ISO and CD

On the help-pages of Ubuntu there is an extensive guide on how to MD5SUM.

Specific Testing

QA tests

You can do more specific tests, like ones done for the Ubuntu ISO : http://iso.qa.ubuntu.com/qatracker

Laptop Testing

Laptops never cease to have their little 'quirks'. You can help on this important area by heading over to Laptop Testing for full details.

Unwanted packages

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 :

  • Install apt-rdependsi

  • 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_package_unwanted (recommended packages are installed by default).

  • You may have to run the commands several times to see the complete chain of depends / recommends.

See Also

UbuntuGNOME/Testing (last edited 2016-11-16 18:29:19 by awjinahn)