TheStages
|
Size: 7414
Comment:
|
Size: 7459
Comment: bug reporting
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 14: | Line 14: |
| It is especially important that Bugs found in the development release be [[Bugs/Upstream|upstreamed]] so that their upstream authors can see them. Often we are using the latest, unmodified alpha code for various projects during the development release, so the odds of it being fixed are much greater if they can be reported to the upstream developers making the changes. | |
| Line 16: | Line 17: |
| Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas. By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you '''must''' raise a bug. You can find information on how to report bugs at [[https://wiki.ubuntu.com/Lubuntu/ReportingBugs | Reporting Bugs]] | Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas. By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you '''must''' [[https://help.ubuntu.com/community/ReportingBugs | raise a bug]]. === My Bug went Private === The bot that goes looking for duplicated bugs is not aware if the bug it is using as master is private. If this happens please go to #ubuntu-bugs and raise it with them. |
| Line 24: | Line 30: |
| Line 25: | Line 32: |
| Testing is split into distinct, but joined areas. The '''Daily Builds''', the '''QA-testing of Milestone releases''' and the '''Milestone releases''' themselves. | Testing is split into distinct, but joined areas. The '''Daily Builds''', the '''Cadence Testing''', the '''QA-testing of Milestone releases''' and the '''Milestone releases''' themselves. |
| Line 36: | Line 43: |
=== Cadence Testing === As a new way to test the builds, we host cadence testing weeks every two weeks, possibly in the middle of a milestone, for example in between Alpha 2 and Alpha 3. It is also tested using [http://iso.qa.ubuntu.com/|ISO QA Tracker]]. It is a good way to keep you busy with testing, but only for a certain time. |
|
| Line 48: | Line 58: |
=== Calls for Testing === Occasionally, we will have unscheduled testing events to test a specific product or feature. Tests for these and instructions will vary, however the qatracker will be utilized if possible to help manage and record the testing. |
|
| Line 80: | Line 93: |
=== PPA Testing === Sometimes during the test cycle one of the developers may ask you to test something specific for them. Most often this is from a '''staging''' area. To temporarily add a '''staging''' area (below is an example using the lubuntu-staging ppa and the application lxinput), install what they want you to test and then remove the staging area following the below example. {{{ sudo apt-add-repository ppa:lubuntu-dev/staging sudo apt-get update sudo apt-get install lxinput sudo apt-add-repository -r ppa:lubuntu-dev/staging sudo apt-get update }}} This will 'grab' the lxinput from the staging area and then remove staging. If the new '''lxinput''' broke your system, then you need to get rid of it and re-install the current version {{{ sudo apt-get remove lxinput sudo apt-get install lxinput }}} This will remove the new '''lxinput''' we got from the ppa, and now that ppa is no longer in use, the install will 'grab' the one from the normal area. If you are working on a bug, it is important to test with these packages to verify it has been fixed. |
More Information
This section provides further information and useful links for testers. As with all alphas and betas they are not suitable for a production environment, please take the time to read Common Questions for Testing
Announcements
At each milestone release, the notes at technical overview are updated.
Bugs
It is especially important that Bugs found in the development release be upstreamed so that their upstream authors can see them. Often we are using the latest, unmodified alpha code for various projects during the development release, so the odds of it being fixed are much greater if they can be reported to the upstream developers making the changes.
Reporting Bugs
Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas. By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you must raise a bug.
My Bug went Private
The bot that goes looking for duplicated bugs is not aware if the bug it is using as master is private. If this happens please go to #ubuntu-bugs and raise it with them.
Dealing with Bug Reports
Triaging (dealing) with bug reports is a really important area. When new fixes come through it is important to let people know. please try a newer version is one such answer. There is also full list of responses. It is important that the person who raised the bug, no matter if it is incomplete, a duplicate or any other reason is made to feel that their bug is important. Simply put, to them, it is the most important bug in the world and should be treated as such.
The Bug Squad
If you'd like to know more about the treatment of bugs, please head over to The Bug Squad new comers are always welcome.
Testing
Testing is split into distinct, but joined areas. The Daily Builds, the Cadence Testing, 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 iso's are automatically generated every 24 hours using the latest updates on the system from the devs. 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.
Cadence Testing
As a new way to test the builds, we host cadence testing weeks every two weeks, possibly in the middle of a milestone, for example in between Alpha 2 and Alpha 3. It is also tested using [http://iso.qa.ubuntu.com/|ISO QA Tracker]]. It is a good way to keep you busy with testing, but only for a certain time.
QA testing of Milestone releases
Alpha, 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
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.
Calls for Testing
Occasionally, we will have unscheduled testing events to test a specific product or feature. Tests for these and instructions will vary, however the qatracker will be utilized if possible to help manage and record the 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/test/5090
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.
Performance tests
You can test some aspects of Ubuntu 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.
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-rdepends
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.
QATeam/Overview/TheStages (last edited 2015-01-23 16:17:15 by xdsl-83-150-81-40)