Plasma/TestDays: Difference between revisions
No edit summary |
|||
| Line 3: | Line 3: | ||
==What is Plasma Test Days?== | ==What is Plasma Test Days?== | ||
The Plasma Test Days will happen the '''19th and 20th of June 2016''' in preparation for the Plasma 5.7 release. During that time we will stress test the upcoming release with the help of the KDE community and we want to invite everyone, no matter what level of experience you have to be part in this project to ensure the stability and quality of Plasma 5.7 for all. | The Plasma Test Days will happen the '''19th and 20th of June 2016''' in preparation for the Plasma 5.7 release. During that time we will stress test the upcoming release with the help of the KDE community and we want to invite everyone, no matter what level of experience you have to be part in this project to ensure the stability and quality of Plasma 5.7 for all. | ||
Our overarching goal is not just to ensure Plasma's future stability but to set up a new path for involvement in KDE where in members of the wider community can easily be a part as well as having a better relationship with distro's shipping Plasma. | |||
After the Test Days our hope is that everyone involved will feel that they got something out of it. That developers feel that they have a better and more clear grasp of common bugs, community members feel that they have greater access to "the inner workings of Plasma" and distro maintainers feel that they have a better relationship with the KDE community and it's members. | |||
===I'm in! How does it work?=== | ===I'm in! How does it work?=== | ||
Revision as of 13:55, 26 April 2016
What is Plasma Test Days?
The Plasma Test Days will happen the 19th and 20th of June 2016 in preparation for the Plasma 5.7 release. During that time we will stress test the upcoming release with the help of the KDE community and we want to invite everyone, no matter what level of experience you have to be part in this project to ensure the stability and quality of Plasma 5.7 for all.
Our overarching goal is not just to ensure Plasma's future stability but to set up a new path for involvement in KDE where in members of the wider community can easily be a part as well as having a better relationship with distro's shipping Plasma.
After the Test Days our hope is that everyone involved will feel that they got something out of it. That developers feel that they have a better and more clear grasp of common bugs, community members feel that they have greater access to "the inner workings of Plasma" and distro maintainers feel that they have a better relationship with the KDE community and it's members.
I'm in! How does it work?
Currently we are setting up the Test Day
Test Iso's
Here we will display the available iso's hopefully using stable bases and the beta of Plasma 5.7 on top. Our goal is to have a wide range of different distro's to be a part of the testing to easier ensure that whatever bug found is Plasma related. Our hope is to have one from KDE neon, Opensuse, Fedora, KaOS and hopefully one using Arch as base.
Test Scenarios
What Happens Afterwards?
This is where the fun starts, after the scenarios have been tested, the information handed over to the test day team, the test day team have written, triaged and checked the bugs and passed them off to the developers for whom they are relevant; we evaluate the Test Day and present the results and possible future Test Days.
Evaluation
Results
To be announced after the testing is done.
Articles, FAQ's and External Links
- Dario's Guide to Bug Triaging - Extensive guide on how to perform bug triagers tasks
- Quick introduction to Bugzilla - This article explains the basics about the bugtracking software that KDE uses: "Bugzilla". It includes the description of a bug reports fields and the workflow of most common tasks like searching into the database.
- A Bug's Life Cycle - This article describes the possible status of a bug report and when each should be used.
- How to triage bugs - This article gives step-by-step what you do during a BugDay, or how to start triaging on your own in our "ongoing triage" (usually for old Konqueror bugs; see #kde-bugs for the current link).
- Preparing a testing environment - This article from the BugWeeks initiative describes how to properly configure and setup a KDE SC environment in order to test the bugs.
- How to create useful crash reports - This article helps users to prepare their KDE packages such they can create detailed backtraces.
- Basic guide about crash reports - This article is a basic/simplified version of the previous one.
- Extra Mile - This article presents the Extra Mile initiative, whose goal is to help KDE applications and workspaces "walk the extra mile". The Extra Mile initiative uses Bugzilla to track extra mile bugs.