Plasma/TestDays: Difference between revisions
No edit summary |
|||
| Line 21: | Line 21: | ||
===Evaluation=== | ===Evaluation=== | ||
After the Test Day we will go through the available information for a proper evaluation of what happened, how it happened and if the end results where good. | |||
We wont just look at what bugs where found, where cleared or where fixed - but how many took part, how many NEW people took part (as that is one of the goals mentioned above), and perhaps see how distro maintainers felt it worked. | |||
All to ensure that everyone found it worthwhile. | |||
If it was a bust we will have to ask ourselves why it was a bust, what we could have done different, how we can improve it to next Test Day and if they are worthwhile. If on the other hand it was a thundering success, we need to ask the same questions: Why was it a success? How can we reproduce this success? When is the next Test Day? | |||
As the test day comes closer we will hopefully be able to formalize and fill out this segment so that evaluation can begin the second Test Day is over! | |||
===Results=== | ===Results=== | ||
Revision as of 13:59, 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
After the Test Day we will go through the available information for a proper evaluation of what happened, how it happened and if the end results where good. We wont just look at what bugs where found, where cleared or where fixed - but how many took part, how many NEW people took part (as that is one of the goals mentioned above), and perhaps see how distro maintainers felt it worked.
All to ensure that everyone found it worthwhile.
If it was a bust we will have to ask ourselves why it was a bust, what we could have done different, how we can improve it to next Test Day and if they are worthwhile. If on the other hand it was a thundering success, we need to ask the same questions: Why was it a success? How can we reproduce this success? When is the next Test Day?
As the test day comes closer we will hopefully be able to formalize and fill out this segment so that evaluation can begin the second Test Day is over!
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.