On Sun, Jan 8, 2012 at 11:45 AM, Roger Luedecke
I think in a previous thread we identified some issues, and some possible solutions.
I think to help assure the quality of our distro we need to create a QA team, with a good structure. One of the issues will be having strong centralized communication. I believe I can provide an excellent tool for this, as long as nobody is opposed to using an outside tool.
1. Establish QA team and resources 2. Divide the team into units 1. Assign area heads based on speciality. 2. Divide KDE testing into logical blocks of applications, such as plasma team, PIM team, etc. 3. Establish triaging guidelines and methodology. 1. Looks like the wiki has good guidelines on this 2. Check and compile lists from Bugzilla to create test cases 4. Efficient testing 1. Assign testing tasks and blocks to team members (self assigned or team sublead assigned is fine) 2. Track tasks, and keep notes. 1. The tool I have in mind and have access to is supremely suited to this. 5. Report findings 1. File new bug reports in the case of a bug being SOLVED, and flag the old possibly associated bugs with the new report. Check upstream for related reports. 2. Compile task list of outstanding bug findings, and check with upstream to see if problem is known or patched. 1. If the bug is unknown, file a new report with KDE 2. If the bug is patched, add to list of fixes that need to be applied.
I think that about covers it. Queue brainstorm!
I agree with what some others said about keeping a single list of patches against KDE, when they were added, and what they do. There apparently are not that many, so it shouldn't be too hard. These are supposed to be in the .spec file, but many are not, and having them in a central place would probably make it easier. This isn't only for debugging, but just for general maintenance, since just looking at the spec files and patches it is not always clear what they do. Another thing I would suggest is a list of official keywords that can be added to bugs to make it easier to keep track of what specifically they are related to. So bluetooth bugs might be assigned to KDE, but could have a bluetooth keyword. Bugs that maybe hardware-specific could have a hardware-specific keyword. The name of the application affected should probably always be included as a keyword. Making good use of keywords should make it a lot easier to keep track of bugs. Another thing I was thinking about, and may not be a good idea at all, would be to have patches in spec file divided into 4 categories: openSUSE-specific bugfixes, openSUSE-specific features, backported bugfixes, and backported features. Each of these categories would have a project-wide build flag associated with it, so that they can be disabled as a group all at once for all packages in a project. This would make it easy for someone to branch a problematic package into another repo, disable, say, all backported features, and then check to see if that fixes the problem. This may be infeasible in practice, though. While we are at it may also be good for the QA team to do a comprehensive revue of all patches to see which ones might not be good, which ones are obsolete, which ones should be pushed upstream, etc. If this is an initiative for all of openSUSE, might this serve as an opportunity to transition to an openSUSE-specific bugzilla? -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org