KDE TechBase - User contributions [en]

Contribute/Quality Team

2013-05-11T10:36:23Z

Mamarok: style change forexternal links

[[Category:Quality]]
[[Category:Testing]]

A software project is only complete when there also is a general Quality Assurance. A broader definition of Software Quality Assurance can be found in the following links:

*http://en.wikipedia.org/wiki/Software_quality_assurance
*http://en.wikipedia.org/wiki/Software_quality_management

Software Quality is usually defined by various standards, on being the recommendations made by [http://en.wikipedia.org/wiki/CISQ CISQ]:

Reliability - Efficiency - Security - Maintainability - adequate Size

A more detailed information about this can be found here: http://en.wikipedia.org/wiki/Software_quality

== Domains in KDE where Quality Assurance is needed ==

*[http://community.kde.org/Getinvolved/Testing Software Testing]
*[http://techbase.kde.org/Contribute#User_Interface Usability]
*[http://community.kde.org/Getinvolved/accessibility Acessibility]
*[http://community.kde.org/Getinvolved/documentation Documentation]
*[http://community.kde.org/Getinvolved/translation Translation]
*[http://techbase.kde.org/Contribute/Bugsquad Bug handling]
*[http://techbase.kde.org/Projects/Release_Team KDE releases]

=== Archive ===

For a more in-depth view on Software Quality, see [[Contribute/Quality Team/Essay]]

Contribute/Bugsquad/Guide To BugTriaging

2013-04-17T06:16:03Z

Mamarok: /* Setting Bugzilla fields (and re-assignation) */ add information about version

Initial version by [[User:DarioAndres|Dario Andres]] (2010-03/2010-04).

Initial corrections by Lydia Pintscher (Nightrose)

===Disclaimer===

This "ultimate" guide is based on my own experience (approximately 2 years) on the KDE bug tracker.

I hope it works for you too :)

=General Considerations=

* '''Be polite''': when you need to request information or feedback be clear and polite, and you will get more information in less time.  Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the other's position while describing your own.

* Don't try to do too many things at the same time; otherwise you will end up with a headache.

If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick Introduction to Bugzilla]

You may want to properly setup your bugzilla account as mentioned at [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla#Configure_your_account_.28Important.29 Configure your account]

=About getting permissions to work in the bug tracker=

Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.

If you want to work in the bug tracker you need to prove that you know what you are doing.

Initially you will ask for support on '''#kde-bugs''' (on IRC) and add comments in the bug report (so other people will see and check them, perform the needed actions, and evaluate your work)

{{Note|Adding comments in a bug report is allowed for every user}}

=Getting Started: Find what to work on (Different Approaches)=

You could use different techniques or approaches to triage the reports according to your current mood or the amount of work you want to do for example.

{{Tip|The two following techniques are complementary.}}

==Check all the bug reports of the day==

In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).

You can focus on crash, normal or wish reports individually (recommended) or all of them together.

'''Good:'''
* You get a complete view of all the reports
* You can easily recognize possible duplicates if the report titles are appropriate
* You can choose any report
* You can quickly clean the bugs that were filed recently (keeping them from rotting)
* You can get quick feedback from the reporter

'''Not so Good:'''
* You don't focus on one product
* You may not pay too much attention to every report, as you are triaging different kinds of reports
* You need a lot of attention to handle the different reports (at the ~same~ time)

This technique could be used ''every week'' (or every day)

===Bugzilla Links===
* All the bugs ('''any type''') reported [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=1d&chfieldto=Now&bug_file_loc=&cmdtype=doit today] or the [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=7d&chfieldto=Now&bug_file_loc=&cmdtype=doit last week]
* All the '''crashes''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All the '''normal bugs''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All the '''feature requests''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]

==Check bug reports of a single product over a period of time==

Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beggining (like 2000)). You can also choose which kind of reports you want to handle.

This technique is useful to audit old bugs or perform a deep clean (in case that the bugs weren't triaged on a daily basis previously).

'''Good:'''
* You focus only on one product / topic, so you don't need to pay too much attention (pay attention anyways!)

'''Not so Good:'''
* The reports of the other application may rot if they aren't checked
* You may not get feedback if the report is too old or the reporter is not accessible anymore

You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).

This technique could be used ''two times a month''.

===Bugzilla Links===

* Template search for all the reports of any status, since 2008: [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= any kind of report], [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=crash&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= crashes], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= normal bugs], [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=wishlist&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= feature requests]
* Template search for all the open reports, since 2008: [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= any kind of report], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= crashes], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= normal bugs], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= feature requests]

=Workflow of the bug triaging activity=

Now that you have a list of bug reports, pick one and start working.

[[File:DarioAndres_GuideToBugTriaging_Workflow.png]]

=Handling reports: What to do with a bug report=

There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful piece of information for the developers to check.

{{Note|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask to the developers or related contributors}}

As KDE has too many users, we get a lot of reports about bugs which are already reported (the so named "duplicates"). Before putting any effort in the current report we should check for the main report.

==Identifying duplicates==

There are a lot of ways of identifying duplicate reports depending of the kind of bug.

===General===

* Search for duplicates should be done initially against the same product of the bug report you are triaging:  If you don't find any related issue, you may need to search in a different product.
 
{{Tip|You can search on different products at the same time}}

{{Note|Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be being tracked at a library product (example, a bug in Plasma Desktop may be a bug in kdelibs, and therefore being tracked in the "kdelibs" product)}}

[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies List of related KDE technologies]

* You may want to filter out the results by date: you can select a date range since some years (or months ago) to "Now" (today)

===For "normal" (non-crash) reports===

# Pick some "keywords" from the current report. This keywords need to explain the inner concept of the bug that was reported (they must represent it).
# Perform a full search over the same product (read general note), initially on the "general" component.  Initially, put the keywords in the title, and perform the search (this will only look for the keywords in the title)
# If your search has results on it, check them all, reading the whole description and trying to identify the situation.
# If you don't get any results, you need to go back and: 
#* Change your keywords (tip: select thesaurus, or similar/related concepts); or
#* Use the keywords in the "Comments" field (so the search will look up in the bug description and comments too)

{{Note|When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"}}

{{Note|It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person (but we have time)}}

===For "crash" reports===

# Perform the same operation as with normal bug reports
# Check for reports with duplicate backtraces:   (Read the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#C.2B.2B_Backtraces_.28identifying_crashes_duplicates.29 Backtraces section] below)

Perform a full search over the same product (read general note), initially on the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")

===Processing search results===

* If you don't find any similar report then we should assume the new bug reports is "unique" (and valid). See next section 

* If you find a similar bug report we have too choices:
** If you are completely sure it is the same issue, you have to mark the report as duplicate.   The bug report you initially picked (name it "copy") is going to be marked as duplicate of the original report (name it "main"). If "copy" has additional information that "main" doesn't have, you may want to add it. (Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase) 
** If you aren't completely sure: you need someone else to double check your work. You may want to add a comment in the current report. Then, you should ask in #kde-bugs IRC channel for someone to look at your comment.
Comment template:
This bug looks related to bug XXXXXX
(XXXXXX being the bug ID of "master")

{{Note|You may found related reports that are already marked as duplicate of a third report. Always try to use this third report as the "main" one (resolve the duplicates chain). However, in some cases, the "main" reports refers to a root issue, and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.}}

==Identifying duplicates (crashes) : C++ Backtraces==

===Definition===

A backtrace is a piece of information that describes what was the application doing when it encountered the error and had to close itself. It is a “function stack” leading to the “crashing point”.

In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.

The backtrace is read from top to bottom. The first line shows ''where'' the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issues). The other lines show the “way to the first function”.

===Example===

Application: Plasma Workspace (kdeinit4), signal: Bus error
[KCrash Handler]
#5 0x00007fb563bb8f02 in KPixmapCache::Private::mmapFile (this=0x92df60,
filename=..., info=0x92dfb0, newsize=33656832) at /usr/src/debug/kdelibs-
4.4.1/kdeui/util/kpixmapcache.cpp:491
#6 0x00007fb563be3c34 in KPixmapCache::Private::mmapFiles (this=0x92df60) at
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:419
#7 0x00007fb563be38e3 in KPixmapCache::Private::init (this=0x92df60) at
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1061
#8 0x00007fb563be576d in KPixmapCache::discard (this=0x1203ca0) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1279
#9 0x00007fb563be5e48 in KPixmapCache::deleteCache (name=...) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1255
#10 0x00007fb55afdc97d in Plasma::ThemePrivate::discardCache (this=0x7a7d30)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:224
#11 0x00007fb55afe009b in Plasma::ThemePrivate::setThemeName (this=0x7a7d30,
tempThemeName=<value optimized out>, writeSettings=<value optimized out>)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:380
#12 0x00007fb55afe19fb in Plasma::Theme::settingsChanged (this=0x70af20) at
/usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:341
#13 0x00007fb55afe2918 in Plasma::ThemePrivate::settingsFileChanged
(this=0x7a7d30, file=<value optimized out>) at /usr/src/debug/kdelibs-
4.4.1/plasma/theme.cpp:335
...

===Description of a backtrace line===

#NumberInTheStack MemoryAddress in Namespace::Class:FunctionMember
(argumentThis=pointerValue, argument1=value, argument2=value, ...) at path/to
/source/code/file.cpp:linenumber

* #NumberInTheStack: is the order number in the function stack. The lesser, the nearer to the crash point. The smaller number may not be zero
* MemoryAddress: we don't put attention to this one.. Ignore
* Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could be also a class name if "Class" is an embedded one.
* Class: C++ class name of the function
* FunctionMember: C++ function name
* argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example "this=0x91ec5f8"  other argument use the same form "parameterName=parameterValue"
* (..): arguments supplied to the function. This information may not be available if *debug information* is not present  
* path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function, and the line number. The path is the one found at '''build time'''. This information may not be useful if '''debug information''' is not available (in that case, the name of the library or application binary may be included. Example: ''/home/kde-devel/kde/lib/libsopranoclient.so.1'')

'''Example''':

#13 0xb759d5d7 in Nepomuk::ResourceData::determineUri (this=0x91ec5f8) at
/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp:671

* The function is the number 13 in the stack
* Function's namespace: "Nepomuk"
* Function's class: "ResourceData"
* Function's function: "determineUri"
* The object "Nepomuk::ResourceData" which called to "determineUri" has the pointer "0x91ec5f8"
* The function is described (where it was build) at "/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp". It leads to the next function in the stack at the line number 671

===Identifying the first (useful) backtrace functions===

The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi)

If the application only had one thread, then it is at the top of the unique thread; otherwise you may need to look at all the thread (the KCrash mark may not be always in the Thread number 1)

Once that you located the "crashing thread start", pickup the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below)

This pairs will be used as "keywords" for the duplicate search

{{Note|This is only a general rule. There are some special cases when the first three function at the top may be the same but the crash may be different (specially on complex application/libraries as Konqueror)}}

If the first backtrace functions aren't available (they are not there, or there are "??") then we can't proceed without [[#Check_the_report_quality_.28and_ask_for_missing_information.29|asking for more information]] (a more complete backtrace).

===Avoiding useless function calls===

Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). This kind of functions should not be used for search as they are not representative of the crash itself and it may return lots of results.

'''Classes and functions to ignore in a backtrace''':
* Kernel/GLibC functions (<tt>__kernel_vsyscall</tt>, <tt>raise</tt>, <tt>abort</tt>)
* Functions from core/base libraries (libraries with filenames like <tt>libpthread.so.0</tt>, <tt>libc.so</tt>, <tt>libstdc++.so</tt>, <tt>libglib-2.0.so</tt>; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
* Qt containers classes (<tt>QMap</tt>, <tt>QList</tt>, <tt>QLinkedList</tt>, <tt>QVector</tt>, <tt>QStack</tt>, <tt>QQueue</tt>, <tt>QSet</tt>, <tt>QMap</tt>, <tt>QMultiMap</tt>, <tt>QHash</tt>, <tt>QMultiHash</tt>)
* Qt deep core classes (<tt>QApplication</tt>, <tt>QCoreApplication</tt>, <tt>QBasicAtomicInt</tt>, <tt>QBasicAtomicPointer</tt>, <tt>QAtomicInt</tt>, <tt>QAtomicPointer</tt>, <tt>QMetaObject</tt>, <tt>QPointer</tt>, <tt>QWeakPointer</tt>, <tt>QSharedPointer</tt>, <tt>QScopedPointer</tt>, <tt>QMetaCallEvent</tt>)
* Qt misc functions (<tt>qt_message_output</tt>, <tt>qt_message</tt>, <tt>qGetPtrHelper</tt>, functions starting with <tt>qt_meta_</tt>)

===Special cases (Advanced)===

There are special crashes related to the X11 graphics server. To identify this crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.

The important things to identify those crashes is recognizing the functions *below* the XIOError call (this is, which functions caused the X11 error).

In most of this crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).

==Bugs caused by external issues (UPSTREAM/DOWNSTREAM)==

Check if the bug is caused by an external plugin/add-on or distribution issue

There are several bugs which may be caused by external add-ons. If you are sure this is the case, you should dismiss the report, telling the reporter to file a new bug in a different place.

* Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)

Distributions can also bring some trouble, specially with packaging.

Some problems that may cause bugs are:
* different versions among KDE packages (kdelibs at one version, kdebase at a different one)
* missing plugins (broken packaging) causing crashes or missing features.

Also, distribution can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize this unofficial add-ons.

If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot; other people may identify if it is a KDE application or an external addition.

{{Note|The '''UPSTREAM''' resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11).
The '''DOWNSTREAM''' resolution refers to bug caused by the Distributions (broken packaging, ...) or by external plugins (unofficial Plasma widgets, other extensions, ...)}}

==Check the report quality (and ask for missing information)==

Now that you know that the bug report is unique, and that is not an external issue, you need to check all the needed information is there.

* Check that report is English and that is easily understandable.  
** If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
**   If the explanation is not clear enough, and you think that the bug could be described in a image, you may want to ask for a screenshot [explanation of Bugzilla attachments]

* If the bug is a graphical glitch or issue, you may want to request a screenshot [explanation of Bugzilla attachments]
* If the issue involves any other component (like the graphics card or drivers) you may need to ask for the versions and component's names
* If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug package symbols, reproduce the bug and generate a new backtrace. Template for this request:

If you can reproduce the crash at will (or you experience this regularly),
can you install the "PACKAGENAME" package and post a complete backtrace here?
(you can get more information at http://techbase.kde.org/User:DarioAndres
/Basic_Guide_about_Crash_Reporting ) Thanks

The names of the missing packages depends of the application and the distribution (as package naming scheme changes..). Look at List of debug package names on several Distributions

'''Useful information which could be also missing''':
* Application version
* KDE Platform (and/or Software Compilation) version
* If the bug is about a crash, request the version of the Qt library
* If the reporter is using an development version, request the Git or SVN revision of the KDE platform and application

{{Note|If you don't get feedback after a period of time, you can mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}

==Setting Bugzilla fields (and re-assignation)==

Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):

* '''Version''': if the report has an application version, you need to set the version in the Bugzilla field. Ideally the version field should reflect the latest version the bug is reproducible with, and of course the other information in the bug (backtrace, description) should also reflect that same version. In the process of triaging old bug reports the version field is a good indicator for a bug that needs newer information.
* '''Priority''': we don't use this field in the KDE bug tracker. The priority is used by the developers to organize their work, it should stay at normal and only changed by the developers of the project.
* '''Severity''': if the bug is important, critical or it causes data loss if should be set to "major" or "critical". If it is about a crash or a freeze it should be set to "crash". If it is any other kind of bug, it should be set to "normal". If it is a feature request (not a regression) it should be set to "wish".
** If you are not really sure if a report describes a real bug or a feature; or if you cannot diagnose the issue, you need to ask in the support channels or wait for other triagers or developers to check the report.
* '''Platform''': this field is only important if the bug is related to one distribution or specific system. (most of the bug reports are common to most of the platforms). Same with the OS field

===Renaming a report: Updating the summary===

Most of the times, the reporter user initially sets the bug report's title, and therefore, the summary doesn't really represent the bug itself. You may want to update the title to contain enough information to identify the issue properly.

A good title may contain:

* A brief explanation of the root cause (if it was found)
* Some of the symptoms people are experiencing
* Additional comments between round brackets/parentheses

{{Tip|Try to use complete and easily readable english sentences as summary}}

* If the bug is about a crash, you may add the first useful ClassName::FunctionName pairs that identify it. You can put them inside square brackets at the end of the title

* If the report has additional information (like a testcase file, or an attached proposed patch) you may add those references as tags at the start of the summary (inside square brackets)

'''Examples''':

[patch] Plasma clock draws garbage when hovering it if the Ctrl key is pressed

Dolphin hangs when trying to view the properties of a big file

[testcase file] Plasma crashes when adding a special file to the panel
[Class1::Function1, Class1::Function2, Class2::Function3]

Applications that use Plasma themes crash when compositing is switched on/off
due an error in KPixmapCache [KPixmapCache::Private::mmapFile,
KPixmapCache::Private::init, KPixmapCache::discard]

[testcase url] Konqueror shows a graphical artifact in webpage's form when
scrolling

===Reassigning bug reports===

Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know to which application/library did the bug belong to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)

{{Warning|Only perform re-assignations if you are sure the bug is in the wrong product.}}

{{Note|Remember to check the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies KDE related technologies list]}}

# Select the correct Bugzilla product.
# If you are sure the current assignee is the default of the current product, you need to click the checkbox to reset the assignee (so the assignee of the new(and correct) Bugzilla product will get notified)
# Commit the changes
# In the next page, select the correct Component and Version, and save the changes

==Adding related people to the CC list==

Sometimes, the reports describe general issues or are filed against common bugzilla products (like "kde" or "kdelibs"); or, on the other round, are filed against specific products (but the underling bug root cause is at some specific library, not directly related to the current bugzilla product assignee)

In both cases, if we don't need/want to reassign the report (because we aren't really sure about it), we can add the assignee of the other related products, or other developers mail address, to the CC list of the bug report.
That means, this person (or people following a mailing list) will get notified about this bug report, and they might look at it.

To know whom to add to the CC list you can:
* Look at the [https://bugs.kde.org/editproducts.cgi list of bugzilla products and components] and find the current default assignee (this requires special "editcomponents" permissions)
* Look at copyright of the source code related to the bug. (You can always access the code using [http://websvn.kde.org/trunk/KDE/ WebSVN])
* Ask in the IRC support channels which person is related to an specific KDE area (#kde-devel)

Common situation '''examples''':

* A report against "Dolphin" describes a Nepomuk-related error.
** Add the Nepomuk default assignee to the CC list

* A report against "Plasma" describes an error which seems to be more general (at kdelibs level), but you are not really sure if you should reassign it.
** Do not reassign and add "kdelibs-bugs___at___kde___dot___org" to the CC list

* A report against the "kde" bugzilla product describes a Konqueror-related issue (and you aren't sure it is a Konqueror-only issue)
** Do not reassign and add "konq-bugs___at___kde___dot___org" to the CC list

* A report against the "kde" bugzilla product describes a Plasma issue
** Reassign the report to the "plasma" bugzilla product; or
** Add "plasma-bugs___at___kde___dot___org" to the CC list

==Other Situations and Cases==

===One report per issue===

There is a policy in KDE bugtracker which establishes that different issues/bugs should not be mixed up in the same bug report, in order to keep the database clean and easy to read.

If any user adds information which is unrelated to the current bug report, gently tell him/her to write it down on a *different/new report. (The new issue described may be already reported somewhere else. In that case, you need to write a reference to the that bug report ID)

=Trying to reproduce the bugs=

An important step of bug triaging is trying to reproduce the bugs, this means, using the information the reporters added to the bug report to force(recreate, reproduce, repeat) the bug in the application.

This is needed in order to differentiate random/race condition bugs of reproducible ones (which may be reproduced by developers too; and they can fix them)

{{Warning|Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or sightly modified) environment. I recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).}}

You may want to use this reference text to setup your testing environment: [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]

{{Note|It is also important to have an updated KDE SC installation to test bugs.}}

==How to test bug reproducibility==

# Read the *complete* bug report (including all the attached information). Note that some bits of information may look unrelated; but they could be useful (or not)
# Use the information in the first comment (the original bug description) to try to reproduce the bug in the application.
# If you can reproduce the bug, then go to the next step
#* If you can't reproduce the bug, use the next comment in the report (which may add new information) to try to reproduce.
#* If you can't reproduce with all the comments in a separate way, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one) and similar combinations. You often have to use your imagination a bit (hopefully we still have time). Hopefully, you may find a combination that may reproduce the bug all (or most of) the times. Write down the "recipe" (steps to reproduce it), you need to include that data into the report later.
# Now that we have a result, we need to add our information/conclusions to the bug report

{{Tip|When trying to reproduce a bug, and if there are more than one piece of information, at first glance, try to identify a *common situation*. (some data or context that is present in all (or most of) the cases). This kind of data may be the key to find out how to reproduce.}}

==Adding new information (and requesting feedback)==

* In any case, add your KDE SC version and system information. (other kind of configuration data may be useful to: "did you tested it on a clean environment or in your existing configuration ?" "do you have library X installed and updated ?" "is your system 32 or 64 bits ?")

'''If you could reproduce the bug''':

* If you had to combine several steps to make your own "recipe" to reproduce, write it down. This kind of information should be useful for the developers.

* If you had to use custom input data (text, or a file); you may want to attach it to the bug report (of course, if it is not attached already)

A template of a comment for this situation could be:

I can reproduce the bug here using KDE SC x.y.z, Qt a.b.c on Distribution,
Kernel d.e.f on XX bits.
In order to reproduce I have to perform the following actions:
1- Action 1
2- Action 2
3- Action 3
4- Bug Appears
Note that you need to have the X configuration set to Y, and use the Z library
- Can anyone else confirm this ?
Thanks

'''If you could not reproduce the bug''':

* Write down which kind of steps you performed to try to get the bug.

* You may want to ask to all the reporters if your step had missing something, or if they notice any other strange (or not-default) situation or configuration which may be related.

* Also, if the report is a bit old (more than two major KDE SC releases old), you could try to ask the reporters if you can reproduce the bug in the latest stable KDE SC release or trunk (development version). The bug may be fixed already (but no one wrote it down into the bug report). If a comment indicates that the bug is resolved, close the bug as WORKSFORME, and refer to the comment in which the reporter indicated being unable to reproduce.

A template of comment for this situation could be:

I couldn't reproduce the bug here using KDE SC x.y.z, Qt a.b.c
on Distribution, Kernel d.e.f on XX bits.
I tried performing this actions:
1- Action 1
2- Action 2
or
1a- Action 1a
2a- Action 2a
However the bug didn't appear/the application didn't crash
- Are you all using library X and this kind of configuration ?
- Can you still reproduce this bug with an updated KDE SC version ?
Thanks

Hopefully you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as WORKSFORME (or FIXED)

=Getting bug triaging support=

During your work you may need help on how to proceed, you can use this resources to get help:

* The '''#kde-bugs channel''' on IRC (Freenode.net). You can ask to the whole channel.
* The BugSquad mailing list <bugsquad ##at## kde ##dot## org>

=BugWeeks=

We are planing to host bug triaging events (where new "students" can learn the tricks) named "BugWeeks" on a regular basis to help cleaning up the KDE bug tracker database.

The BugWeeks initiative is based on the Klassroom initiative in the KDE Community Forums

You can find more information about this at:
* [http://forum.kde.org/viewtopic.php?f=4&t=84473 BugWeeks announcement]
* [http://forum.kde.org/viewforum.php?f=148 BugWeeks subsection on KDE Community Forums]
* [http://forum.kde.org/viewtopic.php?f=148&t=84713 BugWeek 0 - Plasma Desktop bugs] ([http://forum.kde.org/viewtopic.php?f=148&t=84888 Summary])

=FAQ=
=More Information=

==List of related KDE technologies==

* Every KDE application use kdelibs [Bugzilla product: '''"kdelibs"''']
* Applications using the standard KDE file operations use KIO [Bugzilla product: '''"kio"'''] and probably KFile (for the UI part) [Bugzilla product: '''"kfile"''']
* Oxygen widget style (default) [Bugzilla product: '''"oxygen"''' component '''"style"'''] (I'm adding the component because "Oxygen" also refers to a Plasma and icon themes)
* Multimedia usage: Phonon library [Bugzilla product: '''"Phonon"''']
* PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: '''"kdepim"''', '''"kdepimlibs"''', '''"Akonadi"''', '''"kresources"''']
* Applications using KHTML [Bugzilla product: '''konqueror"''']
* Applications using OpenDesktop services uses Attica [Bugzilla product: '''"attica"''']
* Screen management related operations use the Kephal subsystem [Bugzilla product: '''"kephal"''']
* Games use libkdegames [Bugzilla product: '''"libkdegames"''']
* Scanning related applications probably use the KSane lib [Bugzilla product: '''"libksane"''']
* Multimedia applications reading audio tags use taglib [Bugzilla product: '''"taglib"''']
* Hardware related functions use Solid classes [Bugzilla product: '''"solid"''']
* Power Management functions use PowerDevil [Bugzilla product: '''"solid"''', component: '''"powerdevil-daemon"''']

==Special products and cases==

* "systemsettings" contain bug reports of the Shell application SystemSettings and kcmshell4, and reports of the configuration modules "kcm_*"
** Try to identificate if the report is about the shell applications (and set the component to "general", "treeview" or "kcmshell") or about some of the configuration modules (and set the component to "kcm_*name*")

* Konqueror can use different engines, like KHTML or WebKit
** If the report is about a webkit-only issue, reassign to product "kdelibs", component "kdewebkit"

{{Tip|When updating the bugzilla product or component, do not forget to reset to the default assignee}}

==Useful Links==

* [http://techbase.kde.org/Contribute/Bugsquad BugSquad page on Techbase]
* [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick introduction to Bugzilla]
* [https://darioandreskde.wordpress.com/ Dario_Andres blog about bug triaging]
* [https://bugs.kde.org/page.cgi?id=fields.html A Bug's Life Cycle]
* [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]
* [http://techbase.kde.org/Contribute/Bugsquad/How_to_create_useful_crash_reports How to create useful crash reports]
* [http://techbase.kde.org/User:DarioAndres/Basic_Guide_about_Crash_Reporting Basic guide about crash reports]
* [http://aseigo.blogspot.com/2009/01/bugskdeorg.html aseigo's suggestions for bugs.kde.org]

==Debug package names for several distributions==

For every KDE application it is recommended to install the debug information for "kdelibs" and "qt4"

{| class="wikitable" style="border:1px solid #AAA; padding:2px"
|-
! Package
! Ubuntu/Debian
! OpenSuse
! Fedora
! Mandriva
|-
| ''kdelibs''
| kdelibs5-dbg
| kdelibs4-debuginfo
| kdelibs-debuginfo
| kdelibs4-debug
|-
| ''qt''
| libqt4-dbg
| libqt4-debuginfo
| qt-debuginfo
| qt4-debug
|-
| ''kdebase (KDE base applications)''
| kdebase-dbg, kdebase-runtime-dbg, kdebase-workspace-dbg
| kdebase4-debuginfo, kdebase4-runtime-debuginfo, kdebase4-workspace-debuginfo
| kdebase-debuginfo, kdebase-runtime-debuginfo, kdebase-workspace-debuginfo
| kdebase4-debug, kdebase4-runtime-debug, kdebase4-workspace-debug
|-
| ''General example for every KDE "MODULE"''
| kdeMODULE-dbg
| kdeMODULE4-debuginfo
| kdeMODULE-debuginfo
| kdeMODULE4-debug
|-
| ''Phonon (multimedia subsystem)''
| phonon-dbg
| libphonon4-debuginfo / phonon4-debuginfo
| phonon-debuginfo
| phonon-debug
|}

For a detailed list of distributions naming scheme examples you can look at [http://techbase.kde.org/index.php?title=User:DarioAndres/CreateUsefulReports#How_to_obtain_debug_package_for_several_distributions How to obtain debug packages for every distribution].

==Glossary==

* Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet, or to a set of steps.

Contribute/Bugsquad/BugDays/Dolphin2012/Bugs needing the reproduceable keyword

2012-12-08T11:29:52Z

Mamarok: /* Reproduceable bugs */ typo

===Reproducible bugs===

This section is for reports which contain step-by-step instructions that make the bug 100% reproduceable.
* <s>{{Bug|158264}}</s> - Easily reproducable. It was supposedly fixed in SC 4.7, but only one specific case was corrected. So "Version Fixed In: 4.7.0" is incorrect. Also, the version needs updated to 4.9.2 (what I reproduced it on). [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) done. [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]])
* <s>{{Bug|159859}}</s> - This bug still exists. I did, however, note a semi-workaround in [https://bugs.kde.org/show_bug.cgi?id=159859#c6 my comment]. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) keyword+version updated [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]])
* <s>{{Bug|153984}}</s> — It was already tagged with the ''reproduceable'' keyword, I just updated the version. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 20:51, 26 October 2012 (BST)
* {{Bug|160305}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 21:13, 26 October 2012 (BST)
* <s>{{Bug|161385}}</s> — It was already tagged with the ''reproduceable'' keyword. ''Grigoriadis Grigoris'' provided detailed steps and located the root of the issue in the source code (''today''). I updated the version. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 21:22, 26 October 2012 (BST)
* <s>{{Bug|164188}}</s> — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 21:39, 26 October 2012 (BST) I never really saw the point in that one, closed it now. [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 21:28, 29 November 2012 (UTC)
* <s>{{Bug|181337}}</s> — Tagged as ''reproduceable'' and ''triagged'' by ''Jekyll Wu'' after I provided the steps to reproduce the issue. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 22:11, 26 October 2012 (BST)
* {{Bug|188989}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]])
* <s>{{Bug|189177}}</s> - While this bug is reproducable, it hasn't been determined if it's a problem with Dolphin or Ark. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 00:50, 27 October 2012 (BST) I think it's Ark, reassigned. [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 21:35, 29 November 2012 (UTC)
* {{Bug|190656}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 01:10, 27 October 2012 (BST)
* {{Bug|192307}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 02:24, 27 October 2012 (BST)
* {{Bug|194461}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 03:43, 27 October 2012 (BST)
* {{Bug|161663}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 04:43, 27 October 2012 (BST)
* <s>{{Bug|207309}}</s> — Bug in Konqueror because of a missing feature in Dolphin’s KPart. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 06:13, 27 October 2012 (BST)
* <s>{{Bug|210847}}</s> — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 07:45, 27 October 2012 (BST)
* {{Bug|211531}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 07:58, 27 October 2012 (BST)
* {{Bug|192139}} -- [[User:Jta|Jta]] ([[User talk:Jta|talk]]) 09:55, 27 October 2012 (BST) dragging mp3 into the bread cum ">" produce a crash, with a different backtrace as the original.
* {{Bug|217575}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 10:30, 27 October 2012 (BST)
* {{Bug|220330}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 10:48, 27 October 2012 (BST)
* <s>{{Bug|233335}}</s> — Might be considered a '''duplicate''' of {{Bug|217575}}. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 12:30, 27 October 2012 (BST)
* <s>{{Bug|234754}}</s> — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 12:38, 27 October 2012 (BST)
* {{Bug|235457}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 12:48, 27 October 2012 (BST)
* {{Bug|250787}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 15:22, 27 October 2012 (BST)
* {{Bug|251461}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 16:10, 27 October 2012 (BST)
* {{Bug|251620}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 16:40, 27 October 2012 (BST)
* {{Bug|255486}} — May be considered a wish, but I am not sure enough. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 20:41, 27 October 2012 (BST)
* {{Bug|255819}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 20:45, 27 October 2012 (BST)
* {{Bug|256797}} — May be considered an improvement request instead of an actual bug. [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 20:55, 27 October 2012 (BST)
* {{Bug|258955}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 21:16, 27 October 2012 (BST)
* {{Bug|253488}} - This issue is similar to {{Bug|159859}}, which I triaged earlier. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 02:25, 28 October 2012 (UTC)
* <s>{{Bug|254549}}</s> - Not sure if this is a Dolphin bug. One commenter thinks it might be a problem somewhere in kdelibs. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 02:34, 28 October 2012 (UTC) Not sure if it's a bug at all - the same happens when using bash. But I reassigned to KIO. [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 22:28, 31 October 2012 (UTC)
* {{Bug|261148}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 03:59, 28 October 2012 (UTC)
* {{Bug|262464}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 04:23, 28 October 2012 (UTC)
* {{Bug|261816}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 04:51, 28 October 2012 (UTC)
* <s>{{Bug|243705}}</s> - [[User:grigoriadis|grigoriadis]] ([[User talk:grigoriadis|talk]]) 14:05, 28 October 2012 (GMT +02:00) Looks more like a wish to me - changed severity. [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 18:39, 1 November 2012 (UTC)
* <s>{{Bug|271325}}</s> — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 17:24, 28 October 2012 (UTC)
* {{Bug|271600}} — May be considered a wish (''feature request''). [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 17:29, 28 October 2012 (UTC)
* {{Bug|267171}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 17:52, 28 October 2012 (UTC)
* <s>{{Bug|279333}}</s> — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 07:43, 30 October 2012 (UTC) Has been fixed by Emmanuel :-) [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 22:17, 31 October 2012 (UTC)
* {{Bug|265747}} — When pressing enter dolphin calls KFileItem::run on each selected item which in turn creates a new KRun instance. When selecting open with, dolphin uses KFileItemActions(in kio) which calls KRun:run with KFileItemListProperties::urlList.(see KFileItemActionsPrivate::slotRunApplication). [[User:grigoriadis|grigoriadis]] ([[User talk:grigoriadis|talk]]) 23:47, 31 October 2012 (UTC)
* {{Bug|281598}} - Only the first reported issue is still a bug. The second one works fine for me. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 01:59, 31 October 2012 (UTC)
* {{Bug|281608}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 02:03, 31 October 2012 (UTC)
* {{Bug|282919}} - Note that for me, it goes to the root of the file system, not my home folder. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 02:39, 31 October 2012 (UTC)
* {{Bug|283409}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 21:36, 31 October 2012 (UTC)
* {{Bug|286459}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 19:23, 1 November 2012 (UTC)
* {{Bug|287829}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 19:40, 1 November 2012 (UTC)
* {{Bug|279614}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 19:46, 1 November 2012 (UTC)
* {{Bug|283475}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 03:09, 3 November 2012 (UTC)
* {{Bug|283549}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 03:17, 3 November 2012 (UTC)
* {{Bug|287983}} — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 10:22, 3 November 2012 (UTC)
* <s>{{Bug|288932}}</s> — [[User:Gallaecio|Gallaecio]] ([[User talk:Gallaecio|talk]]) 10:54, 3 November 2012 (UTC) Confirmed. Might actually be a kdelibs issue though. [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 15:11, 4 November 2012 (UTC)
* {{Bug|290736}} --- [[User:Marcoz|Marco]] ([[User talk:Marcoz|talk]]) 13:22, 3 November 2012 (UTC)
* {{Bug|292508}} --- [[User:grigoriadis|grigoriadis]] ([[User talk:grigoriadis|talk]]) 23:38, 3 November 2012 (UTC)
* <s>{{Bug|293131}}</s> --- Still reproducible (toggle show hidden files while filtering). [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 21:49, 5 November 2012 (UTC)
* <s>{{Bug|293315}}</s> --- Reproducible (can't resize details view columns by double-clicking gap between headers). [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 21:55, 5 November 2012 (UTC)
* <s>{{Bug|293151}}</s> --- Still reproducible (related to Oxygen's "move by clicking empty space" feature). [[User:Freininghaus|freininghaus]] ([[User talk:Freininghaus|talk]]) 06:59, 6 November 2012 (UTC)
* {{Bug|294832}} - This might be considered a wish, not exactly sure how to classify it. [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 22:28, 8 November 2012 (UTC)
* {{Bug|296802}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 17:29, 9 November 2012 (UTC)
* {{Bug|297435}} - [[User:DniMretsaM|Bryan C.]] ([[User talk:DniMretsaM|talk]]) 17:24, 17 November 2012 (UTC)

Welcome to KDE TechBase

2012-11-29T09:35:26Z

Mamarok: s/Book/e-Book/

<languages />

{| style="margin: 1em 2.5% 0 2.5%; padding: 0 5px;" cellpadding="5"
|-
|colspan=2|[[Image:Discover.png|noframe]]
|-
| style="padding-left: 50px;" |[[Image:Action_launch.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Getting Started|
Setting up a KDE development environment]]
:Learn how to get, build and run KDE.</translate>
|-
| style="padding-left: 50px;"|[[Image:Action_configure.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Development|
Developing with KDE]]</translate>
:<translate>
[[Special:myLanguage/Development/Tutorials|
Tutorials]] | [http://flossmanuals.net/kde-guide/ e-Book] | [http://api.kde.org API Documentation] | [[Special:myLanguage/Development/FAQs|
FAQs]]
and more.</translate>
:<translate>
''Related'' [[Special:myLanguage/Schedules|
Release Schedules and Feature Plans]] | [[Special:myLanguage/Policies|
Code Contribution and Development Guidelines]]</translate>
|-
| style="padding-left: 50px;"|[[Image:Devices_system.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/KDE System Administration|KDE System Administration]]
:Information for system administrators managing KDE deployments. </translate>
|-
|colspan=2|[[Image:Interact.png|noframe]]
|-
| style="padding-left: 50px;"|[[Image:Action_favorites.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Contribute|
Join the KDE Team and Contribute]]
:Contribute patches, keep in touch with and join our community.
:''Related:''[[Special:myLanguage/Policies|
KDE Project Policies]] | [http://www.kde.org/support/support.php Donate Money]</translate>
|-
| style="padding-left: 50px;"|[[Image:Action_contents.svg|noframe|left|40px]] ||
;[[Special:myLanguage/ISV|<translate>
ISV Information</translate>]]<translate>

:Developer information for Independent Software Vendors.</translate>
|-
|colspan=2|[[Image:Develop.png|noframe]]
|-
| style="padding-left: 50px;" |[[Image:Action_wizard.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Projects|
KDE projects]]
:Links to development wikis, task lists, etc. for various KDE Projects.</translate>
|}

Welcome to KDE TechBase

2012-11-29T09:33:51Z

Mamarok: added link to e-book

<languages />

{| style="margin: 1em 2.5% 0 2.5%; padding: 0 5px;" cellpadding="5"
|-
|colspan=2|[[Image:Discover.png|noframe]]
|-
| style="padding-left: 50px;" |[[Image:Action_launch.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Getting Started|
Setting up a KDE development environment]]
:Learn how to get, build and run KDE.</translate>
|-
| style="padding-left: 50px;"|[[Image:Action_configure.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Development|
Developing with KDE]]</translate>
:<translate>
[[Special:myLanguage/Development/Tutorials|
Tutorials]] | [http://flossmanuals.net/kde-guide/ Book] | [http://api.kde.org API Documentation] | [[Special:myLanguage/Development/FAQs|
FAQs]]
and more.</translate>
:<translate>
''Related'' [[Special:myLanguage/Schedules|
Release Schedules and Feature Plans]] | [[Special:myLanguage/Policies|
Code Contribution and Development Guidelines]]</translate>
|-
| style="padding-left: 50px;"|[[Image:Devices_system.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/KDE System Administration|KDE System Administration]]
:Information for system administrators managing KDE deployments. </translate>
|-
|colspan=2|[[Image:Interact.png|noframe]]
|-
| style="padding-left: 50px;"|[[Image:Action_favorites.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Contribute|
Join the KDE Team and Contribute]]
:Contribute patches, keep in touch with and join our community.
:''Related:''[[Special:myLanguage/Policies|
KDE Project Policies]] | [http://www.kde.org/support/support.php Donate Money]</translate>
|-
| style="padding-left: 50px;"|[[Image:Action_contents.svg|noframe|left|40px]] ||
;[[Special:myLanguage/ISV|<translate>
ISV Information</translate>]]<translate>

:Developer information for Independent Software Vendors.</translate>
|-
|colspan=2|[[Image:Develop.png|noframe]]
|-
| style="padding-left: 50px;" |[[Image:Action_wizard.svg|noframe|left|40px]] ||
;<translate>
[[Special:myLanguage/Projects|
KDE projects]]
:Links to development wikis, task lists, etc. for various KDE Projects.</translate>
|}

Amarok/AmarokFileTracking

2012-10-26T00:44:39Z

Mamarok: layout

= What is it? =

Most people do not have static music collections; songs are always being renamed and moved. With most other media players, renaming a file or moving it from folder to folder causes the player to lose track of the file, forcing you to re-add the file to your playlist and possibly to lose any statistics about that song that you may have accumulated. This is time-consuming and annoying. Amarok has implemented file tracking features to cope with this common use-case, allowing Amarok to track your songs as you rename and move your files (referred to as AFT for the rest of this page). Parts of Amarok that can take advantage of this file-tracking behavior are "AFT-enabled".

Currently, Amarok's playlist, statistics, and cached lyrics are AFT-enabled. Playlist functionality includes AFT support for in-line tag editing, the Tag Dialog, and playback. Statistics will track files as they are moved around; you can even move a file out of a collection folder, and put it back in somewhere else and have the stats update to the new location!

= How does it work? =

Amarok's collection scanner, with incremental updates enabled, already detects additions and deletions of files in your colleciton folders and updates the collection automatically. With AFT, when files are scanned by Amarok's collection scanner, a unique hash is either read from the file or calculated from the file. Using this hash, Amarok can check if a file that is being added to the collection is really a file that has simply been renamed or moved. Amarok's playlist and its statistics and lyrics tables are then updated with the new file name information, allowing you to manage your files without having to manage Amarok, or worry about losing years of statistics information!

= Types of AFT Tracking =

There are two types of AFT tracking: ''embedded'', and ''non-embedded''.

Using embedded tracking, a hash value is written into the metadata of your files, into fields specifically reserved by many tag formats for this information. Not all file types can use this type of tracking; currently only MPEG files that use ID3v2 tags, Ogg Vorbis, FLAC, and Ogg FLAC files are supported. This type of tracking is extremely robust; unless you remove the UID entries from your Amarok database or the file's metadata, Amarok will never lose the file. Duplicated files can be tracked separately by creating different hashes for the files.

Using non-embedded tracking, the hash value is calculated from several read-only properties of the file, including the file length and a portion of its data. No modification of your files are required.

There are a few cases in which non-embedded tracking can fail:

# Both editing a file (i.e. its tags) and renaming it outside of Amarok. AFT can handle either of these cases singularly, but not both at once. As a result you should always rescan the file after performing one operation or the other to ensure that AFT can track it.
# Two identical copies of a file. Only one will be tracked.

Note: Because the incremental scanner uses mtimes (modify times) of the selected directories to determine what to rescan, and not of the individual files, if you modify the tags of a file outside of Amarok, the incremental scanner will not re-scan that directory. If you then move one of these files, the tracking will fail. Therefore, if you want tracking to work after you've modified files outside of Amarok you should either: manually run a full rescan of your files, touch the directory that the file resides in (works on most Unix/Linux/Mac filesystems), or "trick" the incremental scanner into scanning the directory those files were in by creating a new file (i.e. with touch) so that the directory's mtime is updated (you can delete the file after the scan).

= Using MusicBrainz identifiers =

As of git [http://gitweb.kde.org/amarok.git/commit/859bbf8ea6163313b7346f569090407551b2ee91 revision 859bbf8e], Amarok can use embedded MusicBrainz track identifiers for embedded tracking functionality. There is one "issue" that you can run into when using MusicBrainz identifiers: since they identify tracks based on characteristics of the audio data, if you have the identical track in different formats they may still have the same exact unique identifier. As a result, Amarok may become confused and only scan one of the tracks when scanning in your files; or it may even flip-flop back and forth between which of the two formats are contained in the collection.

For this reason, identifiers created with the amarok_afttagger program have precedence, as they guarantee file tracking as opposed to song tracking, so if you are running into this issue and the behavior is undesired (after all, depending on your particular needs, you may actually wish to track songs vs. files) then simply tag your files with the amarok_afttagger program and these identifiers will take precedence. Likewise, if you don't care which format of the song is put into Amarok's collection and played, you can simply remove any Amarok-generated embedded identifiers using the amarok_afttagger program, and let the tracking happen via MusicBrainz identifiers.

= How do I turn it on? =

You don't turn on non-embedded AFT tracking -- it's already enabled for every single file in your collection. Enjoy.

If you want the superior file-tracking features of embedded AFT tracking, you use a helper program installed with Amarok called amarok_afttagger. Pass in a list of files and/or directories to write tags to the supported files. You can also regenerate new IDs, or remove IDs from your files with this program. For more information on available features of the program, run "amarok_afttagger --help". Once you run the program on your files, perform a full rescan in Amarok to pull the new identifiers into the database, and you're set to go.

= Safety =

amarok_afttagger uses the tried and tested TagLib library. This library is used in many media applications across multiple platforms, and is well-regarded.

When performing file operations, amarok_afttagger uses an internal library called SafeFileSaver. This uses hash-based checksums and filesystem atomicity guarantees of certain operations to ensure that the file that is being modified by amarok_afttagger is never being modified by another process at the same time. This is the main reason that the program is slow, but the slowness is worth the safety.

In short, the program is believed to be very safe. The author has used it to write identifiers -- and rewrite, multiple times, for testing purposes -- to thousands of files, without any problems.

= It's not working for me / It works great and I want to give kudos =

No problem. Send email to mitchell @t kde d.t org, and please put AFT somewhere in the subject line. You can also file a bug at bugs.kde.org. Thanks!

[[Category:Amarok]]

Amarok/AmarokFileTracking

2012-10-26T00:43:21Z

Mamarok: image position and size

[[Image:idTag.png|48px|right]]

== What is it? ==

Most people do not have static music collections; songs are always being renamed and moved. With most other media players, renaming a file or moving it from folder to folder causes the player to lose track of the file, forcing you to re-add the file to your playlist and possibly to lose any statistics about that song that you may have accumulated. This is time-consuming and annoying. Amarok has implemented file tracking features to cope with this common use-case, allowing Amarok to track your songs as you rename and move your files (referred to as AFT for the rest of this page). Parts of Amarok that can take advantage of this file-tracking behavior are "AFT-enabled".

Currently, Amarok's playlist, statistics, and cached lyrics are AFT-enabled. Playlist functionality includes AFT support for in-line tag editing, the Tag Dialog, and playback. Statistics will track files as they are moved around; you can even move a file out of a collection folder, and put it back in somewhere else and have the stats update to the new location!

== How does it work? ==

Amarok's collection scanner, with incremental updates enabled, already detects additions and deletions of files in your colleciton folders and updates the collection automatically. With AFT, when files are scanned by Amarok's collection scanner, a unique hash is either read from the file or calculated from the file. Using this hash, Amarok can check if a file that is being added to the collection is really a file that has simply been renamed or moved. Amarok's playlist and its statistics and lyrics tables are then updated with the new file name information, allowing you to manage your files without having to manage Amarok, or worry about losing years of statistics information!

== Types of AFT Tracking ==

There are two types of AFT tracking: ''embedded'', and ''non-embedded''.

Using embedded tracking, a hash value is written into the metadata of your files, into fields specifically reserved by many tag formats for this information. Not all file types can use this type of tracking; currently only MPEG files that use ID3v2 tags, Ogg Vorbis, FLAC, and Ogg FLAC files are supported. This type of tracking is extremely robust; unless you remove the UID entries from your Amarok database or the file's metadata, Amarok will never lose the file. Duplicated files can be tracked separately by creating different hashes for the files.

Using non-embedded tracking, the hash value is calculated from several read-only properties of the file, including the file length and a portion of its data. No modification of your files are required.

There are a few cases in which non-embedded tracking can fail:

# Both editing a file (i.e. its tags) and renaming it outside of Amarok. AFT can handle either of these cases singularly, but not both at once. As a result you should always rescan the file after performing one operation or the other to ensure that AFT can track it.
# Two identical copies of a file. Only one will be tracked.

Note: Because the incremental scanner uses mtimes (modify times) of the selected directories to determine what to rescan, and not of the individual files, if you modify the tags of a file outside of Amarok, the incremental scanner will not re-scan that directory. If you then move one of these files, the tracking will fail. Therefore, if you want tracking to work after you've modified files outside of Amarok you should either: manually run a full rescan of your files, touch the directory that the file resides in (works on most Unix/Linux/Mac filesystems), or "trick" the incremental scanner into scanning the directory those files were in by creating a new file (i.e. with touch) so that the directory's mtime is updated (you can delete the file after the scan).

== Using MusicBrainz identifiers ==

As of git [http://gitweb.kde.org/amarok.git/commit/859bbf8ea6163313b7346f569090407551b2ee91 revision 859bbf8e], Amarok can use embedded MusicBrainz track identifiers for embedded tracking functionality. There is one "issue" that you can run into when using MusicBrainz identifiers: since they identify tracks based on characteristics of the audio data, if you have the identical track in different formats they may still have the same exact unique identifier. As a result, Amarok may become confused and only scan one of the tracks when scanning in your files; or it may even flip-flop back and forth between which of the two formats are contained in the collection.

For this reason, identifiers created with the amarok_afttagger program have precedence, as they guarantee file tracking as opposed to song tracking, so if you are running into this issue and the behavior is undesired (after all, depending on your particular needs, you may actually wish to track songs vs. files) then simply tag your files with the amarok_afttagger program and these identifiers will take precedence. Likewise, if you don't care which format of the song is put into Amarok's collection and played, you can simply remove any Amarok-generated embedded identifiers using the amarok_afttagger program, and let the tracking happen via MusicBrainz identifiers.

== How do I turn it on? ==

You don't turn on non-embedded AFT tracking -- it's already enabled for every single file in your collection. Enjoy.

If you want the superior file-tracking features of embedded AFT tracking, you use a helper program installed with Amarok called amarok_afttagger. Pass in a list of files and/or directories to write tags to the supported files. You can also regenerate new IDs, or remove IDs from your files with this program. For more information on available features of the program, run "amarok_afttagger --help". Once you run the program on your files, perform a full rescan in Amarok to pull the new identifiers into the database, and you're set to go.

== Safety ==

amarok_afttagger uses the tried and tested TagLib library. This library is used in many media applications across multiple platforms, and is well-regarded.

When performing file operations, amarok_afttagger uses an internal library called SafeFileSaver. This uses hash-based checksums and filesystem atomicity guarantees of certain operations to ensure that the file that is being modified by amarok_afttagger is never being modified by another process at the same time. This is the main reason that the program is slow, but the slowness is worth the safety.

In short, the program is believed to be very safe. The author has used it to write identifiers -- and rewrite, multiple times, for testing purposes -- to thousands of files, without any problems.

== It's not working for me / It works great and I want to give kudos ==

No problem. Send email to mitchell @t kde d.t org, and please put AFT somewhere in the subject line. You can also file a bug at bugs.kde.org. Thanks!

[[Category:Amarok]]

File:IdTag.png

2012-10-26T00:34:59Z

Mamarok:

Amarok/AmarokFileTracking

2012-10-26T00:02:29Z

Mamarok: moving page from ako

[[Image:idTag.png|right]]

== What is it? ==

Most people do not have static music collections; songs are always being renamed and moved. With most other media players, renaming a file or moving it from folder to folder causes the player to lose track of the file, forcing you to re-add the file to your playlist and possibly to lose any statistics about that song that you may have accumulated. This is time-consuming and annoying. Amarok has implemented file tracking features to cope with this common use-case, allowing Amarok to track your songs as you rename and move your files (referred to as AFT for the rest of this page). Parts of Amarok that can take advantage of this file-tracking behavior are "AFT-enabled".

Currently, Amarok's playlist, statistics, and cached lyrics are AFT-enabled. Playlist functionality includes AFT support for in-line tag editing, the Tag Dialog, and playback. Statistics will track files as they are moved around; you can even move a file out of a collection folder, and put it back in somewhere else and have the stats update to the new location!

== How does it work? ==

Amarok's collection scanner, with incremental updates enabled, already detects additions and deletions of files in your colleciton folders and updates the collection automatically. With AFT, when files are scanned by Amarok's collection scanner, a unique hash is either read from the file or calculated from the file. Using this hash, Amarok can check if a file that is being added to the collection is really a file that has simply been renamed or moved. Amarok's playlist and its statistics and lyrics tables are then updated with the new file name information, allowing you to manage your files without having to manage Amarok, or worry about losing years of statistics information!

== Types of AFT Tracking ==

There are two types of AFT tracking: ''embedded'', and ''non-embedded''.

Using embedded tracking, a hash value is written into the metadata of your files, into fields specifically reserved by many tag formats for this information. Not all file types can use this type of tracking; currently only MPEG files that use ID3v2 tags, Ogg Vorbis, FLAC, and Ogg FLAC files are supported. This type of tracking is extremely robust; unless you remove the UID entries from your Amarok database or the file's metadata, Amarok will never lose the file. Duplicated files can be tracked separately by creating different hashes for the files.

Using non-embedded tracking, the hash value is calculated from several read-only properties of the file, including the file length and a portion of its data. No modification of your files are required.

There are a few cases in which non-embedded tracking can fail:

# Both editing a file (i.e. its tags) and renaming it outside of Amarok. AFT can handle either of these cases singularly, but not both at once. As a result you should always rescan the file after performing one operation or the other to ensure that AFT can track it.
# Two identical copies of a file. Only one will be tracked.

Note: Because the incremental scanner uses mtimes (modify times) of the selected directories to determine what to rescan, and not of the individual files, if you modify the tags of a file outside of Amarok, the incremental scanner will not re-scan that directory. If you then move one of these files, the tracking will fail. Therefore, if you want tracking to work after you've modified files outside of Amarok you should either: manually run a full rescan of your files, touch the directory that the file resides in (works on most Unix/Linux/Mac filesystems), or "trick" the incremental scanner into scanning the directory those files were in by creating a new file (i.e. with touch) so that the directory's mtime is updated (you can delete the file after the scan).

== Using MusicBrainz identifiers ==

As of git [http://gitweb.kde.org/amarok.git/commit/859bbf8ea6163313b7346f569090407551b2ee91 revision 859bbf8e], Amarok can use embedded MusicBrainz track identifiers for embedded tracking functionality. There is one "issue" that you can run into when using MusicBrainz identifiers: since they identify tracks based on characteristics of the audio data, if you have the identical track in different formats they may still have the same exact unique identifier. As a result, Amarok may become confused and only scan one of the tracks when scanning in your files; or it may even flip-flop back and forth between which of the two formats are contained in the collection.

For this reason, identifiers created with the amarok_afttagger program have precedence, as they guarantee file tracking as opposed to song tracking, so if you are running into this issue and the behavior is undesired (after all, depending on your particular needs, you may actually wish to track songs vs. files) then simply tag your files with the amarok_afttagger program and these identifiers will take precedence. Likewise, if you don't care which format of the song is put into Amarok's collection and played, you can simply remove any Amarok-generated embedded identifiers using the amarok_afttagger program, and let the tracking happen via MusicBrainz identifiers.

== How do I turn it on? ==

You don't turn on non-embedded AFT tracking -- it's already enabled for every single file in your collection. Enjoy.

If you want the superior file-tracking features of embedded AFT tracking, you use a helper program installed with Amarok called amarok_afttagger. Pass in a list of files and/or directories to write tags to the supported files. You can also regenerate new IDs, or remove IDs from your files with this program. For more information on available features of the program, run "amarok_afttagger --help". Once you run the program on your files, perform a full rescan in Amarok to pull the new identifiers into the database, and you're set to go.

== Safety ==

amarok_afttagger uses the tried and tested TagLib library. This library is used in many media applications across multiple platforms, and is well-regarded.

When performing file operations, amarok_afttagger uses an internal library called SafeFileSaver. This uses hash-based checksums and filesystem atomicity guarantees of certain operations to ensure that the file that is being modified by amarok_afttagger is never being modified by another process at the same time. This is the main reason that the program is slow, but the slowness is worth the safety.

In short, the program is believed to be very safe. The author has used it to write identifiers -- and rewrite, multiple times, for testing purposes -- to thousands of files, without any problems.

== It's not working for me / It works great and I want to give kudos ==

No problem. Send email to mitchell @t kde d.t org, and please put AFT somewhere in the subject line. You can also file a bug at bugs.kde.org. Thanks!

[[Category:Amarok]]

Projects/Amarok

2012-10-26T00:01:05Z

Mamarok:

Techbase landing page for Amarok

{{Construction}}

*[http://techbase.kde.org/Amarok/AmarokFileTracking Amarok File Tracking]

[[Category:Amarok]]
[[Category:Draft]]

Projects/Amarok

2012-10-25T23:59:09Z

Mamarok: Create new landing page

Techbase landing page for Amarok

{{Construction}}

*[http://techbase.kde.org/Amarok/AFT|Amarok Tracking Feature]

[[Category:Amarok]]
[[Category:Draft]]

Category:Testing

2012-10-16T11:28:40Z

Mamarok: create category page

Pages holding the <nowiki>[[Category:Testing]]</nowiki> tag:

Thread:Talk:Policies/SVN Commit Policy/This is still about SVN

2012-09-28T18:16:03Z

Mamarok: New thread: This is still about SVN

Apaprently to find the valid commit hooks we still need to look at this page, even if most of KDE uses git since quite some time. Any plans of porting this to the git tutorial in techbase?

Contribute/Bugsquad/CannedResponses

2012-08-18T22:25:17Z

Mamarok:

his page gathers some canned responses for bug triaging. Thanks for keeping this updated.

==Closing outdated crash reports==

*" Thank you for your report. Unfortunately the code of <product> has changed sufficiently so the backtraces are not really useful anymore. If you still can reproduce this crash with version x.y or later, please open a new report with a new backtrace, pasted directly in the comment. Thank you for your understanding."

{{Category:Bugsquad}}

Contribute/Bugsquad/CannedResponses

2012-08-18T22:24:56Z

Mamarok: added response for outdated crash reports

his page gathers some canned responses for bug triaging. Thanks for keeping this updated.

Closing outdated crash reports:

*" Thank you for your report. Unfortunately the code of <product> has changed sufficiently so the backtraces are not really useful anymore. If you still can reproduce this crash with version x.y or later, please open a new report with a new backtrace, pasted directly in the comment. Thank you for your understanding."

{{Category:Bugsquad}}

Contribute/Bugsquad/CannedResponses

2012-08-18T22:20:16Z

Mamarok:

his page gathers some canned responses for bug triaging. Thanks for keeping this updated.

{{Category:Bugsquad}}

Contribute/Bugsquad/CannedResponses

2012-08-18T22:19:46Z

Mamarok: Created page

his page gathers some canned responses for bug triaging. Thanks for keeping this updated.

{{Category:Testing}}

Schedules/Extragear

2012-08-14T21:07:30Z

Mamarok:

This page is intended to be a central location for Extragear projects to keep users and contributors (translators, packagers, etc.) informed about upcoming releases in a very accessible way.

<br>

{| border="1"
|-
! Project
! Next release (roughly)
! Next Release Code branch
! Next Release Translation branch
! Comments
|-
| K3b
| 1 March 2010
| [http://websvn.kde.org/trunk/extragear/multimedia/k3b/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-multimedia/ trunk kde4]
| String freeze starting from January 31 2010 (in effect)
|-
| KAudiocreator
|
|
|
|
|-
| Kaffeine
|
|
|
|
|-
| [http://extragear.kde.org/apps/kcoloredit/ KColorEdit]
| KDE release
| [http://websvn.kde.org/trunk/extragear/graphics/kcoloredit/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-graphics/ trunk kde4]
|
|-
| [http://www.kde-apps.org/content/show.php/KDE+Partition+Manager?content=89595 KDE Partition Manager]
| Q2/2010
| [http://websvn.kde.org/trunk/extragear/sysadmin/partitionmanager/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-sysadmin/ trunk kde4]
| 
|-
| [http://ww.kdevelop.org KDevelop]
| 1 May 2010
| [http://websvn.kde.org/trunk/extragear/sdk/kdevelop/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-sdk/ trunk kde4]
| string freeze starting 31 March 2010
|-
| KDiff3
| January 31, 2009
| [http://websvn.kde.org/trunk/extragear/utils/kdiff3/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-utils/ trunk kde4]
|
|-
| KFax
| KDE release
|
|
|
|-
| KFTPGrabber
|
|
|
|
|-
| KGrab
| KDE release
|
|
|
|-
| [http://extragear.kde.org/apps/kgraphviewer/ KGraphViewer]
| KDE release
| [http://websvn.kde.org/trunk/extragear/graphics/kgraphviewer/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-graphics/ trunk kde4]
|
|-
| KIconedit
| KDE release
|
|
|
|-
| [http://www.kmldonkey.org KMLDonkey]
| KDE release
| [http://websvn.kde.org/trunk/extragear/network/kmldonkey/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-network/ trunk kde4]
|
|-
| KNemo
| January 17, 2010
| [http://websvn.kde.org/trunk/extragear/network/knemo/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-network/ trunk kde4]
| String freeze in effect
|-
| KPager
|
|
|
|
|-
| KPhotoalbum
| May 9 2009
| trunk
| trunk
| Message freeze, April 3 2009
|-
| KPlayer
|
|
|
|
|-
| KPovmodeler
| KDE release
|
|
|
|-
| KRecipes
| 2.0, date unknown
| [https://projects.kde.org/projects/extragear/utils/krecipes/repository/?rev=2.0 git 2.0]
| [http://websvn.kde.org/branches/stable/l10n-kde4/templates/messages/extragear-utils/ stable]
| GUI strings frozen, docs ''not'' frozen
|-
| KSig
|
|
|
|
|-
| [http://ktorrent.org/ KTorrent]
| 8 november 2009
| [http://websvn.kde.org/branches/stable/extragear-kde4/network/ktorrent stable kde4]
| [http://websvn.kde.org/branches/stable/l10n-kde4/templates/messages/extragear-network/ stable kde4]
| String freeze in effect
|-
| Kuickshow
|
|
|
|
|-
| Muon Suite
| Final Release: August 2012, pre-releases monthly
|
|
|
|-
| KWlan
|
|
|
|
|-
| RSIBreak
|
|
|
|
|-
| Skanlite
| KDE release
| trunk
|
|
|-
| [http://skrooge.org Skrooge]
| 2010-02-06 (version 0.6.0)
| [http://websvn.kde.org/trunk/extragear/office/skrooge trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-office/ trunk kde4]
| String freeze in effect
|-
| [http://www.kde-apps.org/content/show.php?content=29153 Yakuake]
| July 8th, 2010
| [http://websvn.kde.org/trunk/extragear/utils/yakuake/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-utils/ trunk kde4]
| String freeze started June 24th, 2010
|-
| Kile
| June 8th, 2011 (Version 2.1)
|
|
| String freeze started 23 May 2011
|-
| [http://www.krusader.org/ Krusader]
| 2.4.0-beta1 released on June 26, 2011.
| [http://websvn.kde.org/trunk/extragear/utils/krusader/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-utils/ trunk kde4]
| String freeze since June 26, 2011 until 2.4.0 release.
|-
| BlueDevil
| 1.0.5 (stable) and 1.1.1 (trunk) released planned on July 15, 2011.
|
| stable, trunk
| String freeze since June 29, 2011 until 1.0.5 and 1.1.1 releases.
|-
| [http://amarok.kde.org/ Amarok]
| Early 2013
| git master
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-multimedia/ trunk kde4]
|
|-
| [http://digikam.org digiKam]
| July 27th 2011 [http://www.digikam.org/drupal/about/releaseplan]
| [https://projects.kde.org/projects/extragear/graphics git master]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-graphics/ trunk kde4]
| String freeze starting June 30th 2011.
|-
| [http://techbase.kde.org/Projects/KMyMoney KMyMoney]
| 4.6.1 from Stable around November 5th, 2011
| [http://websvn.kde.org/trunk/extragear/office/kmymoney/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-office/ trunk kde4]
| String freeze started October 22nd, 2011
|-
| massif-visualizer
| 0.3 is planned to be released on September 4, 2011
|
|
| String freeze started on August 8, 2011
|-
| [http://tellico-project.org Tellico]
| 2.3.4
| [http://websvn.kde.org/trunk/extragear/office/tellico/ trunk]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-office/ trunk kde4]
| String freeze: September 5th, 2011 -- September 18th, 2011.
|-
| [http://www.rekonq.sourceforge.net rekonq]
| ~ October 11, 2011 (Version 0.8)
| [http://gitorious.org/rekonq/mainline/trees/master git master]
| [http://gitorious.org/rekonq/mainline/trees/master git master]
| String freeze for 3 weeks starting September 21, 2011 (0.8 release)
|-
| KDE Telepathy
| November 18th, 2011 (version 0.2)
|
|
| String freeze starting October 26th, 2011.
|-
| Calligra
| Calligra 2.6 planned for December 2012
|
|
| String freeze starting October 12th, 2011.
|-
| [http://konversation.kde.org Konversation]
| In the first week of December, 2011
| [http://gitorious.org/konversation/konversation/trees/master git master]
| [http://websvn.kde.org/trunk/l10n-kde4/templates/messages/extragear-network/ trunk kde4]
| String freeze started on November 17th, 2011.
|-
| Wicd Client KDE
| 17th of December, 2011 (version 0.3)
|
|
| String freeze started on December 6th, 2011.
|}

Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX

2012-08-14T10:49:59Z

Mamarok:

==Introduction==
This bug day will take place on <date> but feel free to start early. The aim of this bug day is to get as many <product>-related bugs done as possible. Our target for triage is bugs listed in [http://bugs.kde.org bugs.kde.org] under the product <product>.

===Goals of this Bug Day===

* '''Main goals'''
** Check if bugs reported for older versions of <product-currentversion> are still reproducible.
** Check for duplicates of newer bugs
** Check if bugs reported for <product> which are previously UNCONFIRMED are reproducible.
* If a bug's description is somewhat unclear, try to provide a better step-by-step procedure on how to reproduce it. This will make it easier for developers to find and fix the bug. If necessary, ask the reporter and change the status to NEEDSINFO -> WAITINGFORINFO
(* Some bugs will only be reprocudible on certain graphics hardware, so please always provide the graphics card and driver you are using.)
* Some bugs may not be reproducible on every installation of KDE. Thus we use a 4-eye principle, having at least 2 triagers look at the bugs before we make any changes on the bugs themselves.
* Some more information on how to mark bugs can be found on [http://techbase.kde.org/index.php?title=Contribute/Bugsquad This page].
* Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated. (You can even join now!)
* You should be working with KDE SC <currentrelease> (preferably Git trunk) for testing these bugs.

{{Warning|Always make a note on the bug of what the status is in the version you are testing with (be explicit as to what version of 4 you are using, mentioning whether it is a source build and which distro the packages come from).}}

===Is it a big bug?===
Prioritizing is good. If a major application doesn't work, this should be taken care of.

===Version field===
Keep an eye on what the "Version:" fields say in Bugzilla. If it says "unspecified", change the version field to match what the report says, i.e. to match version the bug was first reported in.

===Keep this page updated!===
After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself on the CC field in bugzilla to be informed about updates. When a bug is closed on bugzilla, it should be updated on this page.

You can do this with the tag <s>...</s>

==Details==
Please select a period of bugs from the [[#Division_of_Labour|Division of Labour]] section below and mark your name next to it and mark it with your irc nickname to show that you are working on it. When you have completed all the bugs in that section, please mark it as complete.

For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below. '''If you wish to close or mark as duplicate a bug, please list it here even if you have the bugzilla permissions to do so, in order to get a second opinion from another triager. This will help to reduce the number of incorrect actions taken on bugs.'''

==Sign-in==
Tell developers what you are testing with. (If you expect to upgrade between now and Bug Day, put what version you are using now next to the bugs/comments that you put on this page.)

Please give distro/version, Git branch/trunk with revision and graphics hardware/driver below:

{|
|-
!IRC Nickname !! KDE version used for testing !! Hardware
|-
|[[User:<wikiusername>]] || ||
|}

{{Tip|Please be sure to sign every bug or comment you add to this page with your irc nickname. You can use the wiki markup <nowiki>~~~</nowiki> to insert your wiki username automatically (but only do this if it is the same as your IRC nickname, otherwise write your IRC nickname in by hand).}}

==Division of Labour==

Please choose a batch that is not already taken and then query bugs.kde.org for all bugs in that batch. Please mark you irc nickname in the table below to show which batches bugs you are working on to avoid duplication of effort.

{|
|-
!Batch !! No of bugs !! IRC Nickname !! Status !! Query
|-
| 1 || 20 || [[User:<wikiusername>]] || done || [ Query]
|}

''(total bugs: <number>)''

== Completed Bugs ==
Below lists the various sections for completed bugs. This aids everyone in double checking each other's work. In addition this allows those of us that don't have bugzilla permissions to list bugs so that the folks with the permissions can follow up.

Please note that this is an experimental layout designed to reduce the number of edit conflicts on this page. Each section is its own subpage. The best way to work with this is to enable section editing by going to "My preferences" > "editing" > "Enable section editing via [edit] links". When you click edit you will automatically edit the subpage.

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing Version Field changed}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs with step-by-step Instructions}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as RESOLVED}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as DUPLICATE}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as INVALID}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as NEW}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing attention from "product" developers}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing the reporter's feedback}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing users with particular setups}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bug reports against performance issues}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs not related to today}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs that you cant do}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Wishes}}

{{Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX}}

Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX

2012-08-14T10:48:45Z

Mamarok: /* Completed Bugs */

Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX

2012-08-14T10:48:00Z

Mamarok: create Template page

==Introduction==
This bug day will take place on <date> but feel free to start early. The aim of this bug day is to get as many <product>-related bugs done as possible. Our target for triage is bugs listed in [http://bugs.kde.org bugs.kde.org] under the product <product>.

===Goals of this Bug Day===

* '''Main goals'''
** Check if bugs reported for older versions of <product-currentversion> are still reproducible.
** Check for duplicates of newer bugs
** Check if bugs reported for <product> which are previously UNCONFIRMED are reproducible.
* If a bug's description is somewhat unclear, try to provide a better step-by-step procedure on how to reproduce it. This will make it easier for developers to find and fix the bug. If necessary, ask the reporter and change the status to NEEDSINFO -> WAITINGFORINFO
(* Some bugs will only be reprocudible on certain graphics hardware, so please always provide the graphics card and driver you are using.)
* Some bugs may not be reproducible on every installation of KDE. Thus we use a 4-eye principle, having at least 2 triagers look at the bugs before we make any changes on the bugs themselves.
* Some more information on how to mark bugs can be found on [http://techbase.kde.org/index.php?title=Contribute/Bugsquad This page].
* Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated. (You can even join now!)
* You should be working with KDE SC <currentrelease> (preferably Git trunk) for testing these bugs.

{{Warning|Always make a note on the bug of what the status is in the version you are testing with (be explicit as to what version of 4 you are using, mentioning whether it is a source build and which distro the packages come from).}}

===Is it a big bug?===
Prioritizing is good. If a major application doesn't work, this should be taken care of.

===Version field===
Keep an eye on what the "Version:" fields say in Bugzilla. If it says "unspecified", change the version field to match what the report says, i.e. to match version the bug was first reported in.

===Keep this page updated!===
After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself on the CC field in bugzilla to be informed about updates. When a bug is closed on bugzilla, it should be updated on this page.

You can do this with the tag <s>...</s>

==Details==
Please select a period of bugs from the [[#Division_of_Labour|Division of Labour]] section below and mark your name next to it and mark it with your irc nickname to show that you are working on it. When you have completed all the bugs in that section, please mark it as complete.

For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below. '''If you wish to close or mark as duplicate a bug, please list it here even if you have the bugzilla permissions to do so, in order to get a second opinion from another triager. This will help to reduce the number of incorrect actions taken on bugs.'''

==Sign-in==
Tell developers what you are testing with. (If you expect to upgrade between now and Bug Day, put what version you are using now next to the bugs/comments that you put on this page.)

Please give distro/version, Git branch/trunk with revision and graphics hardware/driver below:

{|
|-
!IRC Nickname !! KDE version used for testing !! Hardware
|-
|[[User:<wikiusername>]] || ||
|}

{{Tip|Please be sure to sign every bug or comment you add to this page with your irc nickname. You can use the wiki markup <nowiki>~~~</nowiki> to insert your wiki username automatically (but only do this if it is the same as your IRC nickname, otherwise write your IRC nickname in by hand).}}

==Division of Labour==

Please choose a batch that is not already taken and then query bugs.kde.org for all bugs in that batch. Please mark you irc nickname in the table below to show which batches bugs you are working on to avoid duplication of effort.

{|
|-
!Batch !! No of bugs !! IRC Nickname !! Status !! Query
|-
| 1 || 20 || [[User:<wikiusername>]] || done || [ Query]
|}

''(total bugs: <number>)''

== Completed Bugs ==
Below lists the various sections for completed bugs. This aids everyone in double checking each other's work. In addition this allows those of us that don't have bugzilla permissions to list bugs so that the folks with the permissions can follow up.

Please note that this is an experimental layout designed to reduce the number of edit conflicts on this page. Each section is its own subpage. The best way to work with this is to enable section editing by going to "My preferences" > "editing" > "Enable section editing via [edit] links". When you click edit you will automatically edit the subpage.

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing Version Field changed}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs with step-by-step Instructions}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as RESOLVED}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as DUPLICATE}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as INVALID}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs to be marked as NEW}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing attention from <product> developers}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing the reporter's feedback}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs needing users with particular setups}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bug reports against performance issues}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs not related to today}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Bugs that you cant do}}

{{:Contribute/Bugsquad/BugDays/ProductDayX/Wishes}}

Contribute/Bugsquad/OrganizingABugDay/Templates

2012-08-14T10:37:04Z

Mamarok:

Find here the template pages for Bug Days:

*[http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour Division of Labour]
*[http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX ProductDayX]

Contribute/Bugsquad/OrganizingABugDay/Templates

2012-08-14T10:36:45Z

Mamarok:

Find here the template pages for Bug Days:

*[[http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour Division of Labour]]
*[[http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX ProductDayX]]

Contribute/Bugsquad/OrganizingABugDay/Templates

2012-08-14T10:36:19Z

Mamarok: add link to templates

Find here the template pages for Bug Days:

[[http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour Division of Labour]]
[[http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates/ProductDayX ProductDayX]]

Contribute/Bugsquad/OrganizingABugDay

2012-08-14T10:30:41Z

Mamarok: /* Checkpoints */ added templates

=How to organize a BugDay=

{{note|This is a WIP page on how we organize our BugDays. Information is collected and refined here, so more people can take part in planning and conducting such events. When it's done we should have a good checklist as well as some checkpoints (including when to do what).}}

==Choosing a target==

First of all you need to pick a good target for the BugDay including whether to triage or krush. Generally you should keep the following in mind:

* Make sure you contact the developers of the product you're working on early enough to get their support (2-3 weeks in advance).
* Choose an application that's important enough for users so some of them join the effort.

===Triage===

Parts of KDE that qualify are usually applications with a bug count so high its developers have trouble keeping up. The [https://bugs.kde.org/weekly-bug-summary.cgi weekly summary statistic page] on our bug tracker can serve as a starting point.

===Krush===

Krush days are usually suitable for finding plenty of bugs in advance of a release. It's also easier for inexperienced people to take part if beta versions are available via regular distribution channels.

(Could be done at the beginning of the beta phase, with the new features in green published by the developers at, by example, http://techbase.kde.org/Schedules/KDE4/4.6_Feature_Plan)

==Organizing==

Organizing a BugDay should be a joint effort which is coordinated using the BugSquad mailinglist (bugsquad@kde.org). If you want as many people as possible to help, make sure you post to the mailinglist in time.

* Often developers will have special requests (like intervals of bugs or specific components to triage). Take that into account.
* Let the developers tell you which version of their software people should use when working on bugs.

===Techbase page===

Currently we use pages on Techbase to give verbose information about a BugDay and distribute work. A template URL for such a page is:

http://techbase.kde.org/Contribute/Bugsquad/BugDays/ProductDayX

Just replace Product with the application (eg. KWin) and X with the number of the BugDay (ie. 1 for the 1st BugDay for this application).

Notes:
* Use previous BugDay pages as a template.
* For triage, use a script to generate the batches (put scripts on svn, link here and put documentation somewhere)
* Make sure you adapt the page to the BugDay's needs.
* Make one or more developers check if they have special hints to add for the BugDay.

===LiveCD===

(to be written)

==Marketing==

Marketing should be somewhat coordinated. Be sure to distribute responsibilities in time.

* Create an article to be published on dot.kde.org. Make sure you submit it in time (2 weeks before the event!).
* Release informal follow-up blog posts on planetkde.org. Denominate the people who do that so there's no confusion.
* If possible get the triaged product's developers to blog about the BugDay as well asking their users to help.
* In addition you can translate the dot article to other languages and get people to post it on local KDE sites.
* Use micro-blogging to create some buzz (identi.ca, twitter).

(what should be in a dot article? to be written)
(who to contact to publish the dot acrticle? to be written)

==During the BugDay==

During a BugDay new users will often join and either say nothing or just greet everyone. Most of the time those users need help but might be hesitant to ask. In the past it has often helped to check for new people joining and start talking to them when they do offering help. Thus at least one experienced member of BugSquad should always have an eye on IRC. It might be a good idea to designate someone to do that.

Apart from that:
* If there are new people around, keep an eye on what they do. Make them feel their work is appreciated, but also double-check some of it in order to avoid mistakes (we know we all made them when we started).
* Don't be shy to advertise our mailinglist.
* Make sure the BugDay is in the IRC channel's topic (as well as a link to the BugDay's Techbase page).
* If possible, make some of the application's developers join our IRC channel so they can help with certain bugs. Seeing your own work appreciated motivates.
* Be a bit verbose about what you're doing on IRC as to not make the channel seem too deserted. Seeing other people work might be motivating.

=Checkpoints=

(to be written, should contain a timetable of when you should do what when organizing a BugDay)

= Templates =

Find the templates for the BugDays [http://techbase.kde.org/Contribute/Bugsquad/OrganizingABugDay/Templates here]

Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour

2012-08-14T10:28:37Z

Mamarok: Mamarok moved page Contribute/Bugsquad/BugDays/DivisionOfLabour to Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour: moving to correct location

==Introduction==
This triage day will run from <enterdate>. Our target for triage is bugs listed in [http://bugs.kde.org bugs.kde.org] under the product Konqueror.

Please select a period of bugs from the [[#Division_of_Labour|Division of Labour]] section below and mark your name next to it and mark it with your irc nickname to show that you are working on it. When you have completed all the bugs in that section, please mark it as complete.

Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated.

You should be working with <productversion> for testing these bugs.

For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below, or if you have the required bugzilla permissions, take the appropriate action as described in the sections below.

==Division of Labour==
Please choose a <period> that is not already taken and then query bugs.kde.org for all bugs in that <period>. Please mark you irc nickname in the table below to show which month's bugs you are working on to avoid duplication of effort.

{|
|-
!<period> !! irc nickname !! status
|-
|
|}

==Bugs to be marked as RESOLVED==
Only bugs from older releases which have clear instructions on how to reproduce them should be marked as resolved (if you can no longer reproduce of course)

==Bugs to be marked as INVALID==
Bugs which are no longer valid go here. A link to the bug and why it qualifies as invalid should be provided.

==Bugs to be marked as DUPLICATE==
Duplicates found should be placed here with a link to the bug which you think it is a duplicate of.

==Confirmed bugs to be marked as NEW==
Bugs that have been confirmed should go here. A comment should also be left on the bug with a note of what version of <productversion> was used to confirm it.

==Bugs to be marked as [test case]==

Bugs that have had a test case (an example of how to reproduce the bug) added should be entered below.

==Bugs needing users with particular setups==
Bugs that require particular software or hardware that you don't have available should be listed here with a description of the non-standard requirement.

==Non english locales==
Bugs requiring non-English locales should be listed here, along with the locale they require.

==Bugs needing attention from <product> developers==
Add bugs here if you need to find out whether the observed behavior is intended, or if there's some other reason that it would be useful for a <product> developer to take a look. Make sure you indicate ''why'' the bug needs attention from them.

==Bugs awaiting feedback==
Bugs for which feedback has been requested, which should be revisited in 30 days to see if there's any response. Please list all bugs here for which feedback has been requested.

{{DivisionOfLabour}}

Contribute/Bugsquad/BugDays/DivisionOfLabour

2012-08-14T10:28:37Z

Mamarok: Mamarok moved page Contribute/Bugsquad/BugDays/DivisionOfLabour to Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour: moving to correct location

#REDIRECT [[Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour]]

Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour

2012-08-14T10:27:06Z

Mamarok: Mamarok moved page DivisionOfLabour to Contribute/Bugsquad/BugDays/DivisionOfLabour: move to correct location

DivisionOfLabour

2012-08-14T10:27:06Z

Mamarok: Mamarok moved page DivisionOfLabour to Contribute/Bugsquad/BugDays/DivisionOfLabour: move to correct location

#REDIRECT [[Contribute/Bugsquad/BugDays/DivisionOfLabour]]

Contribute/Bugsquad/OrganizingABugDay/Templates/DivisionOfLabour

2012-08-14T10:25:40Z

Mamarok: created DivisionOfLabour template

Contribute/Bugsquad/OrganizingABugDay/Templates

2012-08-14T10:18:40Z

Mamarok: added link to DivisionOfLabour

Find here the template pages for Bug Days:

[[DivisionOfLabour]]

Contribute/Bugsquad/OrganizingABugDay/Templates

2012-08-14T09:50:06Z

Mamarok: create templates page

Find here the template pages for Bug Days:

[../DivisionOfLabour]

Template:BugComment

2012-08-05T15:19:14Z

Mamarok: correct paste...

[http://bugs.kde.org/show_bug.cgi?id={{{1}}}#c{{{2}}} comment #{{{2}}} for bug #{{{1}}}]

Template:BugComment

2012-08-05T15:18:06Z

Mamarok: Create template for bug comments

[https://bugs.kde.org/enter_bug.cgi?product={{{1}}}&format=guided Report bug for '''{{{1}}}'''], see also: [https://bugs.kde.org/enter_bug.cgi?product={{{1}}} quick link without wizard]

Template:BugReport

2012-08-05T15:16:43Z

Mamarok: Created Template for bug reports

[https://bugs.kde.org/enter_bug.cgi?product={{{1}}}&format=guided Report bug for '''{{{1}}}'''], see also: [https://bugs.kde.org/enter_bug.cgi?product={{{1}}} quick link without wizard]

User:Rogerhc

2012-08-05T15:04:36Z

Mamarok: remove bug category

Hi, I have enjoyed KDE as my desktop for several years. These days I run KDE on Kubuntu.

I'm a non-technically minded person. Not sure I can help much here.

My initial interest in KDE TechBase is I have found a bug (behavior) in Konqueror (v.3.5.2) Web browser and want to find out how to report this.

==Konqueror (v.3.5.2) Web browser bug {{bug|149099}}==
I have filed this bug including a testcase here: {{bug|149099}}

Bug is Konqueror does not handle the little [+] links that are supposed to expand items in, for example, the following page's table of contents: http://wikitravel.org/en/San_Francisco

I discovered Konqueror can handle those links better when style margin-left:-3.5ex that moves those [+] left for correct visual effect (see above page's table of contents for example) is changed to margin-left:0. Unfortunately zeroing that margin destroys the sensible look of that table of contents.

I hope this feedback will help someone more technically skilled than I solve this Konqueror Web browser bug.

--[[User:Rogerhc|Rogerhc]] 07:34, 22 August 2007 (CEST)

Contribute/Bugsquad/BugDays

2012-08-05T14:19:06Z

Mamarok: /* Previous Bug Days */ moved KWin day to archive

This page contains links to the pages for all past bug triage events.

==Next Bug Day==
{{:Contribute/Bugsquad/NextBugDay}}

We don't just do bugs on BugDays! Don't hesitate to join us at #kde-bugs on irc.freenode.net, we have plenty for you to do. ;) Check the topic to see what we are currently working on. And if you are new, please read the "how to triage bugs" page.

==Previous Bug Days==
A Bug Day is where the Bugsquad goes back through bugs in bugzilla for a particular application and closes all reports that are no longer valid.

* [[/KWinDay1|KWin Day 1: Sunday, October 10th 2010]] (All of KWin)

* [[/DolphinDay1|Dolphin Bug Day 1: Sunday, August 1st 2010]] (All of Dolphin)

* [[/PhononDay|Phonon Bug Day 1: Sunday, November 8th 2009]] (KDE Multimedia subsystem triage)

* [[/PlasmaDay1|Plasma Bug Day 1: Sunday, April 26th 2009]] (All of Plasma Triage)

* [[/KMailDay3|KMail Bug Day 3: Sunday, March 15th 2009]] (All of KMail)

* [[/KDEPimWeek1|KDE Pim Bug Week 1: Sunday, November 23rd - Saturday, December 6th 2008]] (KMail and KOrganizer)

* [[/KDEPimDay2|KDE Pim Bug Day 2: Sunday, November 9th 2008]] (All of KDE Pim)

* [[/KOfficeDay1/Triage|KOffice Bug Day 1, triage: Sunday, October 26th 2008]] (All of KOffice Triage)

* [[/KonquerorDay6|Konqueror Bug Day 6: Sunday, October 12th 2008]] (Konqueror-General Triage)

* [[/KDEPimDay1|KDE Pim Bug Day 1: Sunday, September 28th 2008]] (KDE Pim and Groupware Triage)

* [[/KMailDay2|KMail Bug Day 2: Sunday, September 14th 2008]] (All of KMail Triage)

* [[/KMailDay1|KMail Bug Day 1: Sunday, August 31st 2008]] (All of KMail Triage)

* [[/KopeteDay2|Kopete Bug Day 2: Sunday, July 20th 2008]] (All of Kopete Triage)

* [[/KopeteDay1|Kopete Bug Day 1: Sunday, July 6th 2008]] (All of Kopete Triage)

* [[/AmarokDay1|Amarok Bug Day 1: Sunday, June 15th 2008]] (All of Amarok Triage)

* [[/KonquerorDay5|Konqueror Bug Day 5: Sunday, June 1st 2008]] (Konqueror-General Triage)

* [[/KonquerorDay4|Konqueror Bug Day 4: Sunday, May 18th 2008]] (Konqueror-General Triage)

* [[/KonquerorDay3|Konqueror Bug Day 3: Sunday, May 4th 2008]] (Konqueror-General Triage)

* [[/KonquerorDay2|Konqueror Bug Day 2: Sunday, April 20th 2008]] (KHTML Triage)

* [[/06APR08|Konqueror Bug Day 1: Sunday, April 6th 2008]] (KHTML Triage)

==Previous Krush Days==
A Krush day is where the Bugsquad tests the target application and reports all the bugs they can find in it.

* [[/KOfficeDay2|KOffice Bug Day 2: Sunday, Januar 25th 2009]] KOffice Krush (IN preparation for 2.0 release)
* [[/KOfficeDay1/Krush|KOffice Bug Day 1, krush: Sunday, October 26th 2008]] KOffice Krush (In preparation for 2.0 release)
* [[/KDEPIMKrush1|KDE PIM Krush Day 2: Sunday, June 8th 2008]] KDE PIM Krush (In preparation for 4.1 release) (Continuation from previous KDE PIM Krush Day 1 on the same page).
* [[/KDEPIMKrush1|KDE PIM Krush Day 1: Sunday, May 25th 2008]] KDE PIM Krush (In preparation for 4.1 release).

==Previous bug triage events==
Prior to the convening of the Bugsquad in its current form, there were a number of Bug Triage and Krush events. Tehcbase pages used for these events can be found below.

* [[Contribute/Bugsquad/KrushDays|KDE4 Krush Days]]

* [[Contribute/Bugsquad/Bug_weekends|Konqueror Bug Weekends]]

==Special triage pages==

* [[/KMailWrapup|KMail Triage Wrapup]] (Bugs that still need to be touched to be done)

* [[/KdelibsOngoing1|kdelibs]] (If you're bored, you can pick some of those :)

* [[/KonquerorOngoing1|Konqueror]] (... or of those)

Contribute/Quality Team

2012-07-12T08:32:38Z

Mamarok: /* Domains in KDE where Quality Assurance is needed */ added link to Release Team

[[Category:Quality]]
[[Category:Testing]]

A software project is only complete when there also is a general Quality Assurance. A broader definition of Software Quality Assurance can be found in the following links:

http://en.wikipedia.org/wiki/Software_quality_assurance
http://en.wikipedia.org/wiki/Software_quality_management

Software Quality is usually defined by various standards, on being the recommendations made by [http://en.wikipedia.org/wiki/CISQ CISQ]:

Reliability - Efficiency - Security - Maintainability - adequate Size

A more detailed information about this can be found here: http://en.wikipedia.org/wiki/Software_quality

== Domains in KDE where Quality Assurance is needed ==

*[http://community.kde.org/Getinvolved/Testing Software Testing]
*[http://techbase.kde.org/Contribute#User_Interface Usability]
*[http://community.kde.org/Getinvolved/accessibility Acessibility]
*[http://community.kde.org/Getinvolved/documentation Documentation]
*[http://community.kde.org/Getinvolved/translation Translation]
*[http://techbase.kde.org/Contribute/Bugsquad Bug handling]
*[http://techbase.kde.org/Projects/Release_Team KDE releases]

=== Archive ===

For a more in-depth view on Software Quality, see [[Contribute/Quality Team/Essay]]

Schedules/Release Schedules Guide

2012-07-12T08:30:50Z

Mamarok: typo

KDE is becoming a very big project. To be able to make a release of KDE a lot
of cooperation between all developers is needed. To make clear to everyone
what is required to make a successful release a schedule is made.
This schedule should be seen as a guideline and not as a strict scheme.
To get involved with KDE releases, please join the [http://techbase.kde.org/Projects/Release_Team Release Team]

Hopefully this release schedule can contribute to the fun and quality of KDE.

== KDE Release Schedules ==

Two schedules are presented here. A major release takes approx. 5 (!!) months
from the first announcement to the final release. A minor release takes approx.
2 months. Schedules for [[#Schedule (Major Release)|major]]
releases and for [[#Schedule (Minor Release)|minor]] releases.

The dates mentioned serve as an indication only. They reflect the expected
duration of a certain phase. If required by the circumstances, the release
dude is free to increase the time between steps. In this case, the release
dude will inform all KDE mailinglists about the adjustments in the release
schedule as well as the reason for the adjustments.

''Example:'' "The KFM authors want to add javascript support in KHTML before
the freeze and will need at least 3 more weeks for this. Therefore the
freeze of the KDE libraries has been delayed till at least 1 Aug 2001."

If a developer would like to see the release delayed he/she should inform
the release dude about this as soon as possible. The release dude will
decide whether the release will be delayed or not. (Possibly after
consulting others)

''Example:'' "Can we wait with the release till Qt3.54 has been released?
I want to use the xyz widget the Trolls have added in my abc application."

=== Schedule (Major Release) ===

{| border="1" cellpadding="5" cellspacing="0" style="border: #80B3FF solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|-
|bgcolor="#EEEEEE"| '''Step 1'''
|bgcolor="#EEEEEE"| '''Start of the Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 0
|-
|colspan="3"|
* A release dude is appointed who will implement this schedule.
* It is decided which libraries will be released.
* A [[#release_announcement|Release Announcement]] is made which is also published on the appropriate mailing lists.
|-
||'''Evaluation''' || || '''Date:''' wk 3
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed. <br />A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 2'''
|bgcolor="#EEEEEE" | '''Library Freeze'''
|bgcolor="#EEEEEE" | '''Date:''' wk 4
|-
|colspan="3"|
* [[#core_lib|Core libraries]] are [[#feature_freeze|feature-frozen]] for the SVN trunk.
* It is decided which applications will be released.
* A [[#release_announcement|Release Announcement]] is made.
|-
||'''Evaluation''' || || '''Date:''' wk 7
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br /> A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 3'''
|bgcolor="#EEEEEE" | '''Application Freeze'''
|bgcolor="#EEEEEE" | '''Date:''' wk 8
|-
|colspan="3"|
* [[#core_lib|Core libraries]] enter [[#deep_freeze|deep-freeze]] for the SVN trunk.
* [[#core_app|Core applications]] are [[#feature_freeze|feature-frozen]] for the SVN trunk.
* An alpha-release is made in both source and binary form.
* It is decided which libraries will be released.
* A [[#release_announcement|Release Announcement]] is made.
|-
||'''Evaluation''' || || '''Date:''' wk 11
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br />A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 4'''
|bgcolor="#EEEEEE" | '''Ready for translation'''
|bgcolor="#EEEEEE" | '''Date:''' wk 12
|-
|colspan="3"|
* [[#core_lib|Core libraries]] are [[#deep_freeze|deep-frozen]] for the SVN trunk.
* [[#core_app|Core applications]] are [[#deep_freeze|deep-frozen]] for the SVN trunk.
* A source-only beta-release is made which will be translated.
* A [[#release_announcement|Release Announcement]] is made.
* A "What's Changed?" should be written!!
|-
||'''Evaluation''' || || '''Date:''' wk 15
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed. <br /> A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 5'''
|bgcolor="#EEEEEE" | '''Final Release'''
|bgcolor="#EEEEEE" | '''Date:''' wk 16
|-
|colspan="3"|
* Debugging messages are turned off by default.
* The code is checked for left over debug output.
* A source-only gamma-release is made without translations.
* The SVN trunk is copied to tags/
* All parts are free to modify again.
* A [[#release_announcement|Release Announcement]] is made which is also published on the appropriate mailing lists.
* Translations can finalize and packagers can start to prepare themselves.
* The "What's changed?" should be finished by now!
* A "Press Release" should be written.
|-
||'''Evaluation''' || || '''Date:''' wk 18
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br /> A [[#release_announcement|Release Announcement]] is made if the next step is delayed.
|-
|bgcolor="#EEEEEE" | '''Step 6'''
|bgcolor="#EEEEEE" | '''Tagging of the Release'''
|bgcolor="#EEEEEE" | '''Date:''' wk 18
|-
|colspan="3"|This should happen during a weekend.
* All translations should be finished and have been put into SVN.
* The gamma-release is now the final-release. It should not have changed much since the previous step. The according tags/ copy is created in SVN.
* The tarballs of the release are made available to the packagers (and the packagers only).
* The creation of the tarballs are announced to kde-pr and kde-distributors. (These lists are not world readable) The translators are informed as well.
* The FTP-mirror maintainers are informed about the upcoming release and the mirrors.html file is updated (on both ftp and www).
|-
|bgcolor="#EEEEEE" | '''Step 7'''
|bgcolor="#EEEEEE" | '''Final Release'''
|bgcolor="#EEEEEE" | '''Date:''' wk 19
|-
|colspan="3"|This should happen on a Monday, one week after Step 6.
* kde-pr sends out the press release.
* kde-pr informs all KDE lists and updates the web-pages.
* Announcements to comp.os.linux.announce, comp.windows.x.kde, de.alt.comp.kde and possibly others are made.
* The binary and source packages are made world-wide available on the ftp-server.
* The release is complete.
* '''<font size="+2">PARTY!!!!</font>'''
|}

=== Schedule (Minor Release) ===

{| border="1" cellpadding="5" cellspacing="0" style="border: #80B3FF solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|-
|bgcolor="#EEEEEE"| '''Step 1'''
|bgcolor="#EEEEEE"| '''Start of the Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 0
|-
|colspan="3"|
* A release dude is appointed who will implement this schedule.
* It is decided which applications and libraries will be released.
* A [[#release_announcement|Release Announcement]] is made which is also published on the appropriate mailing lists.
|-
||'''Evaluation''' || || '''Date:''' wk 3
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br /> A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE"| '''Step 2'''
|bgcolor="#EEEEEE"| '''Application Freeze'''
|bgcolor="#EEEEEE"| '''Date:''' wk 4
|-
|colspan="3"|
* [[#core_lib|Core libraries]] enter [[#deep_freeze|deep-freeze]] for the SVN branch to release.
* [[#core_app|Core applications]] are [[#feature_freeze|feature-frozen]] for the SVN branch to release.
* A [[#release_announcement|Release Announcement]] is made.
|-
||'''Evaluation''' || || '''Date:''' wk 6
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br />A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE"| '''Step 3'''
|bgcolor="#EEEEEE"| '''Ready for translation'''
|bgcolor="#EEEEEE"| '''Date:''' wk 6
|-
|colspan="3"|
* [[#core_lib|Core libraries]] are [[#deep_freeze|deep-frozen]] for the SVN branch to release.
* [[#core_app|Core applications]] are [[#deep_freeze|deep-frozen]] for the SVN branch to release.
* Debugging messages are turned off by default.
* The code is checked for left over debug output.
* The SVN branch is created
* A source-only gamma-release is made which can be translated. Packagers can prepare themselves using the gamma-release.
* A [[#release_announcement|Release Announcement]] is made.
* A "What's changed?" should be written.
* A "Press Release" should be written.
|-
|bgcolor="#EEEEEE"| '''Step 4'''
|bgcolor="#EEEEEE"| '''Final Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 8
|-
|colspan="3"|This should happen during a weekend.
* All translations should be finished and have been put into SVN.
* The gamma-release is now the final-release. It should not have changed since the previous step. The release tags/ path is created in SVN.
* The tarballs of the release are made available to the packagers. (And the packagers only).
* The creation of the tarballs are announced to kde-pr and kde-distributors. (These lists are not world readable) The translators are informed as well.
* The FTP-mirror maintainers are informed about the upcoming release and the mirrors.html file is updated. (on both ftp and www)
|-
|bgcolor="#EEEEEE"| '''Step 5'''
|bgcolor="#EEEEEE"| '''Final Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 9
|-
|colspan="3"|This should happen on a Monday, one week after Step 4.
* kde-pr sends out the press release.
* kde-pr informs all KDE lists and updates the web-pages.
* Announcements to comp.os.linux.announce, comp.windows.x.kde, de.alt.comp.kde and possibly others are made.
* The binary and source packages are made world-wide available on the ftp-server.
* The release is complete.
* '''<font size="+2">PARTY!!!!</font>'''
|-
|}

== Terms ==
;<div id="major_rel">Major Release</div>
:A major KDE release has two version numbers, eg KDE 1.1. Only a major KDE release will incorporate new features.

;<div id="minor_rel">Minor Release</div>
:For minor releases a shortened release schedule will be used. A minor KDE release has three version numbers, eg. KDE 1.1.1. A minor KDE release concentrates on fixing bugs, minor glitches and small usability issues. A minor release is based on a SVN branch of a previous release and does not affect the trunk of SVN.

;<div id="release_announcement">Release Announcement</div>
:A Release Announcement is an announcement related to a release and coupled to a certain step or evaluation. A Release Announcement is sent to ALL KDE mailinglists. It contains a pointer to this document ("KDE Release Schedule") The anouncement includes the current state of the release and describes which parts of SVN are free to modify, feature-frozen or deep-frozen. Each announcement includes in a "What Next?" section what the next step of the release will be and how many weeks/days are left till this step is reached. Release Announcements are repeated weekly, if the next step is within the next week, the announcement is repeated daily.

;<div id="no_freeze">Free to modify</div>
:No special restrictions with regard to changes.

;<div id="feature_freeze">Feature frozen</div>
:No new features, texts may be changed, focus should be on bug fixing.

;<div id="deep_freeze">Deep frozen</div>
:No new features, no changes of texts, only severe bugs may be fixed after two developers have seen a patch and agreed on it.

;<div id="core_lib">Core libraries</div>
:All the libraries which will be released.

;<div id="core_app">Core applications</div>
:All the applications which will be released.

Schedules/Release Schedules Guide

2012-07-12T08:30:18Z

Mamarok: added link to http://techbase.kde.org/Projects/Release_Team

KDE is becoming a very big project. To be able to make a release of KDE a lot
of cooperation between all developers is needed. To make clear to everyone
what is required to make a successful release a schedule is made.
This schedule should be seen as a guideline and not as a strict scheme.
To get involved with KDE releases, please join the [[http://techbase.kde.org/Projects/Release_Team Release Team]]

Hopefully this release schedule can contribute to the fun and quality of KDE.

== KDE Release Schedules ==

Two schedules are presented here. A major release takes approx. 5 (!!) months
from the first announcement to the final release. A minor release takes approx.
2 months. Schedules for [[#Schedule (Major Release)|major]]
releases and for [[#Schedule (Minor Release)|minor]] releases.

The dates mentioned serve as an indication only. They reflect the expected
duration of a certain phase. If required by the circumstances, the release
dude is free to increase the time between steps. In this case, the release
dude will inform all KDE mailinglists about the adjustments in the release
schedule as well as the reason for the adjustments.

''Example:'' "The KFM authors want to add javascript support in KHTML before
the freeze and will need at least 3 more weeks for this. Therefore the
freeze of the KDE libraries has been delayed till at least 1 Aug 2001."

If a developer would like to see the release delayed he/she should inform
the release dude about this as soon as possible. The release dude will
decide whether the release will be delayed or not. (Possibly after
consulting others)

''Example:'' "Can we wait with the release till Qt3.54 has been released?
I want to use the xyz widget the Trolls have added in my abc application."

=== Schedule (Major Release) ===

{| border="1" cellpadding="5" cellspacing="0" style="border: #80B3FF solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|-
|bgcolor="#EEEEEE"| '''Step 1'''
|bgcolor="#EEEEEE"| '''Start of the Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 0
|-
|colspan="3"|
* A release dude is appointed who will implement this schedule.
* It is decided which libraries will be released.
* A [[#release_announcement|Release Announcement]] is made which is also published on the appropriate mailing lists.
|-
||'''Evaluation''' || || '''Date:''' wk 3
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed. <br />A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 2'''
|bgcolor="#EEEEEE" | '''Library Freeze'''
|bgcolor="#EEEEEE" | '''Date:''' wk 4
|-
|colspan="3"|
* [[#core_lib|Core libraries]] are [[#feature_freeze|feature-frozen]] for the SVN trunk.
* It is decided which applications will be released.
* A [[#release_announcement|Release Announcement]] is made.
|-
||'''Evaluation''' || || '''Date:''' wk 7
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br /> A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 3'''
|bgcolor="#EEEEEE" | '''Application Freeze'''
|bgcolor="#EEEEEE" | '''Date:''' wk 8
|-
|colspan="3"|
* [[#core_lib|Core libraries]] enter [[#deep_freeze|deep-freeze]] for the SVN trunk.
* [[#core_app|Core applications]] are [[#feature_freeze|feature-frozen]] for the SVN trunk.
* An alpha-release is made in both source and binary form.
* It is decided which libraries will be released.
* A [[#release_announcement|Release Announcement]] is made.
|-
||'''Evaluation''' || || '''Date:''' wk 11
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br />A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 4'''
|bgcolor="#EEEEEE" | '''Ready for translation'''
|bgcolor="#EEEEEE" | '''Date:''' wk 12
|-
|colspan="3"|
* [[#core_lib|Core libraries]] are [[#deep_freeze|deep-frozen]] for the SVN trunk.
* [[#core_app|Core applications]] are [[#deep_freeze|deep-frozen]] for the SVN trunk.
* A source-only beta-release is made which will be translated.
* A [[#release_announcement|Release Announcement]] is made.
* A "What's Changed?" should be written!!
|-
||'''Evaluation''' || || '''Date:''' wk 15
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed. <br /> A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE" | '''Step 5'''
|bgcolor="#EEEEEE" | '''Final Release'''
|bgcolor="#EEEEEE" | '''Date:''' wk 16
|-
|colspan="3"|
* Debugging messages are turned off by default.
* The code is checked for left over debug output.
* A source-only gamma-release is made without translations.
* The SVN trunk is copied to tags/
* All parts are free to modify again.
* A [[#release_announcement|Release Announcement]] is made which is also published on the appropriate mailing lists.
* Translations can finalize and packagers can start to prepare themselves.
* The "What's changed?" should be finished by now!
* A "Press Release" should be written.
|-
||'''Evaluation''' || || '''Date:''' wk 18
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br /> A [[#release_announcement|Release Announcement]] is made if the next step is delayed.
|-
|bgcolor="#EEEEEE" | '''Step 6'''
|bgcolor="#EEEEEE" | '''Tagging of the Release'''
|bgcolor="#EEEEEE" | '''Date:''' wk 18
|-
|colspan="3"|This should happen during a weekend.
* All translations should be finished and have been put into SVN.
* The gamma-release is now the final-release. It should not have changed much since the previous step. The according tags/ copy is created in SVN.
* The tarballs of the release are made available to the packagers (and the packagers only).
* The creation of the tarballs are announced to kde-pr and kde-distributors. (These lists are not world readable) The translators are informed as well.
* The FTP-mirror maintainers are informed about the upcoming release and the mirrors.html file is updated (on both ftp and www).
|-
|bgcolor="#EEEEEE" | '''Step 7'''
|bgcolor="#EEEEEE" | '''Final Release'''
|bgcolor="#EEEEEE" | '''Date:''' wk 19
|-
|colspan="3"|This should happen on a Monday, one week after Step 6.
* kde-pr sends out the press release.
* kde-pr informs all KDE lists and updates the web-pages.
* Announcements to comp.os.linux.announce, comp.windows.x.kde, de.alt.comp.kde and possibly others are made.
* The binary and source packages are made world-wide available on the ftp-server.
* The release is complete.
* '''<font size="+2">PARTY!!!!</font>'''
|}

=== Schedule (Minor Release) ===

{| border="1" cellpadding="5" cellspacing="0" style="border: #80B3FF solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|-
|bgcolor="#EEEEEE"| '''Step 1'''
|bgcolor="#EEEEEE"| '''Start of the Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 0
|-
|colspan="3"|
* A release dude is appointed who will implement this schedule.
* It is decided which applications and libraries will be released.
* A [[#release_announcement|Release Announcement]] is made which is also published on the appropriate mailing lists.
|-
||'''Evaluation''' || || '''Date:''' wk 3
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br /> A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE"| '''Step 2'''
|bgcolor="#EEEEEE"| '''Application Freeze'''
|bgcolor="#EEEEEE"| '''Date:''' wk 4
|-
|colspan="3"|
* [[#core_lib|Core libraries]] enter [[#deep_freeze|deep-freeze]] for the SVN branch to release.
* [[#core_app|Core applications]] are [[#feature_freeze|feature-frozen]] for the SVN branch to release.
* A [[#release_announcement|Release Announcement]] is made.
|-
||'''Evaluation''' || || '''Date:''' wk 6
|-
|colspan="3"|
* It is evaluated whether the next step needs to be delayed.<br />A [[#release_announcement|Release Announcement]] is made with the result of the evaluation.
|-
|bgcolor="#EEEEEE"| '''Step 3'''
|bgcolor="#EEEEEE"| '''Ready for translation'''
|bgcolor="#EEEEEE"| '''Date:''' wk 6
|-
|colspan="3"|
* [[#core_lib|Core libraries]] are [[#deep_freeze|deep-frozen]] for the SVN branch to release.
* [[#core_app|Core applications]] are [[#deep_freeze|deep-frozen]] for the SVN branch to release.
* Debugging messages are turned off by default.
* The code is checked for left over debug output.
* The SVN branch is created
* A source-only gamma-release is made which can be translated. Packagers can prepare themselves using the gamma-release.
* A [[#release_announcement|Release Announcement]] is made.
* A "What's changed?" should be written.
* A "Press Release" should be written.
|-
|bgcolor="#EEEEEE"| '''Step 4'''
|bgcolor="#EEEEEE"| '''Final Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 8
|-
|colspan="3"|This should happen during a weekend.
* All translations should be finished and have been put into SVN.
* The gamma-release is now the final-release. It should not have changed since the previous step. The release tags/ path is created in SVN.
* The tarballs of the release are made available to the packagers. (And the packagers only).
* The creation of the tarballs are announced to kde-pr and kde-distributors. (These lists are not world readable) The translators are informed as well.
* The FTP-mirror maintainers are informed about the upcoming release and the mirrors.html file is updated. (on both ftp and www)
|-
|bgcolor="#EEEEEE"| '''Step 5'''
|bgcolor="#EEEEEE"| '''Final Release'''
|bgcolor="#EEEEEE"| '''Date:''' wk 9
|-
|colspan="3"|This should happen on a Monday, one week after Step 4.
* kde-pr sends out the press release.
* kde-pr informs all KDE lists and updates the web-pages.
* Announcements to comp.os.linux.announce, comp.windows.x.kde, de.alt.comp.kde and possibly others are made.
* The binary and source packages are made world-wide available on the ftp-server.
* The release is complete.
* '''<font size="+2">PARTY!!!!</font>'''
|-
|}

== Terms ==
;<div id="major_rel">Major Release</div>
:A major KDE release has two version numbers, eg KDE 1.1. Only a major KDE release will incorporate new features.

;<div id="minor_rel">Minor Release</div>
:For minor releases a shortened release schedule will be used. A minor KDE release has three version numbers, eg. KDE 1.1.1. A minor KDE release concentrates on fixing bugs, minor glitches and small usability issues. A minor release is based on a SVN branch of a previous release and does not affect the trunk of SVN.

;<div id="release_announcement">Release Announcement</div>
:A Release Announcement is an announcement related to a release and coupled to a certain step or evaluation. A Release Announcement is sent to ALL KDE mailinglists. It contains a pointer to this document ("KDE Release Schedule") The anouncement includes the current state of the release and describes which parts of SVN are free to modify, feature-frozen or deep-frozen. Each announcement includes in a "What Next?" section what the next step of the release will be and how many weeks/days are left till this step is reached. Release Announcements are repeated weekly, if the next step is within the next week, the announcement is repeated daily.

;<div id="no_freeze">Free to modify</div>
:No special restrictions with regard to changes.

;<div id="feature_freeze">Feature frozen</div>
:No new features, texts may be changed, focus should be on bug fixing.

;<div id="deep_freeze">Deep frozen</div>
:No new features, no changes of texts, only severe bugs may be fixed after two developers have seen a patch and agreed on it.

;<div id="core_lib">Core libraries</div>
:All the libraries which will be released.

;<div id="core_app">Core applications</div>
:All the applications which will be released.

Development/Further Information

2012-05-29T06:56:27Z

Mamarok: /* KDE 4 Development Books */

{{Template:I18n/Language Navigation Bar|Development/Further Information}}
== Web Sites ==
* [http://www.KDE.org KDE Home]
* [http://dot.kde.org KDE Dot News]
* [http://www.planetkde.org Planet KDE]

==Blogs==

== Books ==
Below are a list of books associated with KDE 4 development. These may be specific to applications, using the Qt Toolkit, or specifically KDE 4 books.

===KDE 4 Development Books===

[mailto:manishchaks@gmail.com Manish Chakravarty ] from [http://kde.in KDE India] is working on a KDE 4 programming book.
The scheduled release date is the the 15th of August 2007

As a result of a [http://dot.kde.org/2012/02/05/kde-development-%E2%80%93-beginners-guide/ Sprint] held in October 2011 we now have a [http://flossmanuals.net/kde-guide/ Beginner's Guide to KDE Development] available to ease the new contributors way into KDE development.

===Qt 4 Development Books===

==== English ====

'''[http://www.qt4-book.com/ The Book of Qt 4: The Art of Building Qt Applications] by Daniel Molkentin'''

Daniel Molkentin, author of this book, is a core developer of KDE. He uses practical examples to explain Qt characteristics like the signal slot concept and its event system. He guides the reader through developing applications both with and without Qt's graphical GUI builder "Qt Designer." Topics covered include: tools needed to create dialog boxes; steps to follow when developing a GUI-based application; layout; how to visualize data using Qt's "model-view concept"; the QtSql model; the graphics library; as well as how to work with XML, databases, threads, and debugging. The book also includes lots of useful hints on how to use Qt's own datatypes, containers and algorithms and how to develop user-friendly applications.

Available via: [http://www.amazon.com/Book-Qt-Art-Building-Applications/dp/1593271476 Amazon]

'''[http://www.apress.com/book/view/1590598318 Foundations of Qt Development] by Johan Thelin'''

Foundations of Qt Development is based on Qt 4.2, and is aimed at C++ programmers who want to become proficient using this excellent toolkit to create graphical applications that can be ported to all major platforms. The book is focused on teaching you to write your own code in addition to using existing code. And common areas of confusion are identified, addressed, and answered. Youll learn everything you need to know to get up and running fast.

'''[http://www.informit.com/store/product.aspx?isbn=0131879057 An Introduction to Design Patterns in C++ with Qt 4] by Alan Ezust, Paul Ezust'''

Now, with the help of An Introduction to Design Patterns in C++ with Qt 4.1, you can master C++ and design patterns together, using the world's #1 open source framework for cross-platform development: Qt 4.1. This complete tutorial and reference assumes no previous knowledge of C, C++, objects, or patterns. You'll walk through every core concept, one step at a time, learning through an extensive collection of Qt 4.1-tested examples and exercises. Learn objects fast: classes, inheritance, polymorphism, and more. Master powerful design patterns, from Iterator and Visitor to Abstract Factory and Facade. Discover efficient high-level programming techniques utilizing libraries, generics, and containers. Build graphical applications using Qt widgets, models, and views.

Available via: [http://www.amazon.com/gp/product/0131879057 Amazon]<br />

Available on-line at [http://cartan.cas.suffolk.edu/moin/OopDocbook?page=index.html Suffolk University]

'''[http://www.informit.com/store/product.aspx?isbn=0131872494 C++ GUI Programming with Qt 4] by Jasmin Blanchette, Mark Summerfield'''

The only official best-practice guide to Qt 4.1 Programming. Using C++ GUI Programming with Qt 4 you'll discover the most effective Qt 4 programming patterns and techniques as you master key technologies ranging from Qt's model/view architecture to Qt's powerful new 2D paint engine. The authors provide readers with unparalleled insight into Qt's event model and layout system. Then, using realistic examples, they introduce superior techniques for everything from basic GUI development to advanced database and XML integration.

Available via: [http://www.amazon.com/gp/product/0131872494 Amazon]

Free download is available from [http://www.qtrac.eu/C++-GUI-Programming-with-Qt-4-1st-ed.zip Mark Summerfield's web page] (ZIP with PDF, 5.5 MiB)

'''Note''': the 2nd edition is now available which was updated for Qt 4.3 and is available from [http://www.amazon.com/Programming-Prentice-Source-Software-Development/dp/0132354160 Amazon]

'''[http://www.informit.com/store/product.aspx?isbn=0131240722 C++ GUI Programming with Qt 3]'''

The first official Trolltech guide to Qt 3.2 programming written by Trolltech software engineer Jasmin Blanchette and Trolltech's documentation manager Mark Summerfield, with a foreword by Matthias Ettrich, Trolltech lead developer and founder of the KDE project. The book teaches every facet of Qt 3 programming, ranging from basic user interfaces and layout managers to 2D/3D graphics, drag-and-drop, signaling, networking, XML, database integration, even internationalization and multithreading. The book in PDF format and sources can be downloaded from linked publisher's page.

Available via: [http://www.amazon.com/gp/product/0131240722 Amazon]<br />

Available on-line at: [http://www.phptr.com/content/images/0131240722/downloads/blanchette_book.pdf Prentice-Hall] (free PDF download)

'''[http://www.pragmaticprogrammer.com/titles/ctrubyqt/ Rapid GUI Development with QtRuby]'''

See how to use the powerful Qt3 library to create cross-platform GUI applications for Linux and OS X in Ruby. Covers installation, basic and advanced programming, event models, and Korundum. A must if you want to develop software with QtRuby/Korundum.

'''[http://www.charlesriver.com/Books/BookDetail.aspx?productID=114877 Open Source Game Development: Qt Games for KDE, PDA's, and Windows]'''

This book provides beginning and intermediate game programmers with a step-by-step resource to desktop game programming. The reader is introdcuded into the development of a desktop game application using Qt3/Qt4/Qtopia/KDE as development platform. Desktop game relevant topics such as pathfinding, AI, sound, 2D and 3D graphics and network programming are introduced in the scope of Qt and KDE. All topics are accompanied by plenty of source code examples in the book and on the companion CD-ROM.

Available via: [http://www.amazon.com/gp/product/1584504064 Amazon]

==== German ====

[https://www.opensourcepress.de/index.php?26&backPID=15&tt_products=23 Qt 4: Einführung in die Applikationsentwicklung von Daniel Molkentin]

==== Russian ====
[http://www.bhv.ru/books/book.php?id=186572 Qt4.5. Профессиональное программирование на C++]

===C++ Programming Books===

==== English ====

'''A Complete Guide to Programming in C++'''

Suited for both complete novices and advanced users of C++. Takes a clear and logical approach using uncluttered English and purposeful examples. With examples and website content, it represents great value for the money and is highly recommended as both a tutorial for students and newcomers to C++ and a dip-in guide for more advanced practitioners. This book teaches you the C++ STL in a natural way while learning C++, while many others relegate the STL to an appendix.

Available via: [http://www.amazon.com/gp/product/0763718173 Amazon]

'''Problem Solving, Abstraction, and Design Using C++'''

This book presents introductory programming material. Only the features of C++ that are appropriate to introductory concepts are introduced. Object-oriented concepts are presented. Abstraction is stressed throughout the book and pointers are presented in a gradual and gentle fashion for easier learning.

Available via: [http://www.amazon.com/exec/obidos/ASIN/0201612771/ Amazon]

'''[http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html Thinking in C++]'''

The effective presentation, along with dozens of helpful code examples, make this book a standout. The text first sets the stage for using C++ with a tour of what object-oriented programming is all about, as well as the software design life cycle. The author then delves into every aspect of C++, from basic keywords and programming principles to more advanced topics, like function and operator overloading, virtual inheritance, exception handling, namespaces, and templates. C++ is a complex language, and the author covers a lot of ground using today's Standard C++, but without getting bogged down in excessive detail.

Available via: [http://www.amazon.com/exec/obidos/ISBN=0139798099/ Amazon]<br />
Available via: [http://www1.fatbrain.com/FindItNow/Services/home.cl?from=YGY567&store=1 Fatbrain]

'''Accelerated C++: Practical Programming by Example'''

If you don't have a lot of time, but still want to learn the latest in C++, you don't have to learn C first. You might learn more by digging into current language features and classes from the very beginning. That's the approach that's offered by Accelerated C++, a text that delves into more advanced C++ features like templates and Standard Template Library (STL) collection classes early on. This book arguably can get a motivated beginning programmer into C++ more quickly than other available tutorials.

Available via: [http://www.amazon.com/exec/obidos/ASIN/020170353X/ Amazon]

'''Effective C++: 50 Specific Ways to Improve Your Programs and Design'''

Highly recommended by KDE core developers! It is not a book on syntax, so this should not be the 1st C++ book that you read -- but it should *definitely* be the 2nd! An absolutely terrific book focusing on basic C++ and object-oriented programming techniques. A crucial book for anyone new to C++ to read.

2nd Edition Available via: [http://www.amazon.com/exec/obidos/ASIN/0201924889/ Amazon]<br />
3rd Edition Available via: [http://www.amazon.com/exec/obidos/ASIN/0321334876/ Amazon]

'''More Effective C++: 35 New Ways to Improve Your Programs and Designs'''

From the author of the indispensable Effective C++, here are 35 new ways to improve your programs and designs. Drawing on years of experience, Meyers explains how to write software that is more effective: more efficient, more robust, more consistent, more portable, and more reusable. In short, how to write C++ software that's just plain better. For programmers at the intermediate level and above.

Available via: [http://www.amazon.com/exec/obidos/ASIN/020163371X/ Amazon]

'''C++ FAQs'''

This book answers all the questions one can imagine about C++. The author explains the reasoning and principals behind good OO design in a simple and well informed manner. See also the free online [http://www.parashift.com/c++-faq-lite/ C++ FAQ LITE]. If you like the online lite version, you will be ecstatic about the printed book version because it covers much more.

Available via: [http://www.amazon.com/exec/obidos/ASIN/0201589583/ Amazon]

'''[http://www.icce.rug.nl/documents/cplusplus/cplusplus.html C++ Annotations]'''

This online book is intended for knowledgeable users of C who would like to make the transition to C++. It is a guide for C++ programming courses given at the University of Groningen, Netherlands. As such, the book is not a complete C++ handbook. Rather, it serves as an addition to other documentation sources.

Available via: [http://www.amazon.com/exec/obidos/ASIN/020163371X/ Amazon]

'''The C++ Programming Language'''

By Bjarne Stroustrup, the creator of C++. This book is not for people who do not have programming experience in C++ already. This is not a ground up tutorial on how to program in C++, and it is not a fast read. What this book is, however, is probably the best reference book on C++ in existance.

Available via: [http://www.amazon.com/exec/obidos/ASIN/0201700735/ Amazon]

===Other Books===

'''[http://doc.trolltech.com/guibooks.html Books on GUI design]'''

Trolltech's recommendations of books about GUI design.

===Historic===
'''[http://developer.kde.org/documentation/books/kde-2.0-development/index.html KDE 2.0 Development]'''

A 540 page book available online and in print. Covers KParts, DCOP, aRts, KDevelop, licensing, introductory programming, and other topics. The [http://kde20development.andamooka.org support site] has the full text in various formats along with community annotation and discussion of KDE development. This book is as close to an Official Book by the KDE Project as possible. All authors and technical editors are KDE developers.

== IRC Channels ==
In general, IRC channels mentioned here are available on FreeNode. Connect to irc.kde.org, and check these channels out for further information.

*KDE User Channel - [irc://irc.kde.org:6667/kde #kde]
*KDE Development - [irc://irc.kde.org:6667/kde-devel #kde-devel]
*Phonon - [irc://irc.kde.org:6667/phonon #phonon]
*Decibel - [irc://irc.kde.org:6667/decibel #decibel]
*Solid - [irc://irc.kde.org:6667/solid #solid]
*Plasma - [irc://irc.kde.org:6667/plasma #plasma]
*KDE EDU - [irc://irc.kde.org:6667/kdeedu #kdeedu]
*KDE Games - [irc://irc.kde.org:6667/kdegames #kdegames]
*KDE PIM - [irc://irc.kde.org:6667/kontact #kontact]
*KDevelop IDE - [irc://irc.kde.org:6667/kdevelop #kdevelop]
*Amarok - [irc://irc.kde.org:6667/kdevelop #amarok]

== Newsgroups ==
== Forums ==
== Events ==
== Courses and Certifications ==
== Audio and Video Casts ==
== Source Code Repositories ==

Development/Further Information

2012-05-29T06:48:08Z

Mamarok: /* KDE 4 Development Books */ added flossmanuals book

{{Template:I18n/Language Navigation Bar|Development/Further Information}}
== Web Sites ==
* [http://www.KDE.org KDE Home]
* [http://dot.kde.org KDE Dot News]
* [http://www.planetkde.org Planet KDE]

==Blogs==

== Books ==
Below are a list of books associated with KDE 4 development. These may be specific to applications, using the Qt Toolkit, or specifically KDE 4 books.

===KDE 4 Development Books===

[mailto:manishchaks@gmail.com Manish Chakravarty ] from [http://kde.in KDE India] is working on a KDE 4 programming book.
The scheduled release date is the the 15th of August 2007

As a result of a [http://dot.kde.org/2012/02/05/kde-development-%E2%80%93-beginners-guide/ Sprint] held in October 2011 we now have a [http://flossmanuals.net/kde-guide/ Beginner's Guide to KDE Development] available to ease the new contributors way into KDE developmetn.

===Qt 4 Development Books===

==== English ====

'''[http://www.qt4-book.com/ The Book of Qt 4: The Art of Building Qt Applications] by Daniel Molkentin'''

Daniel Molkentin, author of this book, is a core developer of KDE. He uses practical examples to explain Qt characteristics like the signal slot concept and its event system. He guides the reader through developing applications both with and without Qt's graphical GUI builder "Qt Designer." Topics covered include: tools needed to create dialog boxes; steps to follow when developing a GUI-based application; layout; how to visualize data using Qt's "model-view concept"; the QtSql model; the graphics library; as well as how to work with XML, databases, threads, and debugging. The book also includes lots of useful hints on how to use Qt's own datatypes, containers and algorithms and how to develop user-friendly applications.

Available via: [http://www.amazon.com/Book-Qt-Art-Building-Applications/dp/1593271476 Amazon]

'''[http://www.apress.com/book/view/1590598318 Foundations of Qt Development] by Johan Thelin'''

Foundations of Qt Development is based on Qt 4.2, and is aimed at C++ programmers who want to become proficient using this excellent toolkit to create graphical applications that can be ported to all major platforms. The book is focused on teaching you to write your own code in addition to using existing code. And common areas of confusion are identified, addressed, and answered. Youll learn everything you need to know to get up and running fast.

'''[http://www.informit.com/store/product.aspx?isbn=0131879057 An Introduction to Design Patterns in C++ with Qt 4] by Alan Ezust, Paul Ezust'''

Now, with the help of An Introduction to Design Patterns in C++ with Qt 4.1, you can master C++ and design patterns together, using the world's #1 open source framework for cross-platform development: Qt 4.1. This complete tutorial and reference assumes no previous knowledge of C, C++, objects, or patterns. You'll walk through every core concept, one step at a time, learning through an extensive collection of Qt 4.1-tested examples and exercises. Learn objects fast: classes, inheritance, polymorphism, and more. Master powerful design patterns, from Iterator and Visitor to Abstract Factory and Facade. Discover efficient high-level programming techniques utilizing libraries, generics, and containers. Build graphical applications using Qt widgets, models, and views.

Available via: [http://www.amazon.com/gp/product/0131879057 Amazon]<br />

Available on-line at [http://cartan.cas.suffolk.edu/moin/OopDocbook?page=index.html Suffolk University]

'''[http://www.informit.com/store/product.aspx?isbn=0131872494 C++ GUI Programming with Qt 4] by Jasmin Blanchette, Mark Summerfield'''

The only official best-practice guide to Qt 4.1 Programming. Using C++ GUI Programming with Qt 4 you'll discover the most effective Qt 4 programming patterns and techniques as you master key technologies ranging from Qt's model/view architecture to Qt's powerful new 2D paint engine. The authors provide readers with unparalleled insight into Qt's event model and layout system. Then, using realistic examples, they introduce superior techniques for everything from basic GUI development to advanced database and XML integration.

Available via: [http://www.amazon.com/gp/product/0131872494 Amazon]

Free download is available from [http://www.qtrac.eu/C++-GUI-Programming-with-Qt-4-1st-ed.zip Mark Summerfield's web page] (ZIP with PDF, 5.5 MiB)

'''Note''': the 2nd edition is now available which was updated for Qt 4.3 and is available from [http://www.amazon.com/Programming-Prentice-Source-Software-Development/dp/0132354160 Amazon]

'''[http://www.informit.com/store/product.aspx?isbn=0131240722 C++ GUI Programming with Qt 3]'''

The first official Trolltech guide to Qt 3.2 programming written by Trolltech software engineer Jasmin Blanchette and Trolltech's documentation manager Mark Summerfield, with a foreword by Matthias Ettrich, Trolltech lead developer and founder of the KDE project. The book teaches every facet of Qt 3 programming, ranging from basic user interfaces and layout managers to 2D/3D graphics, drag-and-drop, signaling, networking, XML, database integration, even internationalization and multithreading. The book in PDF format and sources can be downloaded from linked publisher's page.

Available via: [http://www.amazon.com/gp/product/0131240722 Amazon]<br />

Available on-line at: [http://www.phptr.com/content/images/0131240722/downloads/blanchette_book.pdf Prentice-Hall] (free PDF download)

'''[http://www.pragmaticprogrammer.com/titles/ctrubyqt/ Rapid GUI Development with QtRuby]'''

See how to use the powerful Qt3 library to create cross-platform GUI applications for Linux and OS X in Ruby. Covers installation, basic and advanced programming, event models, and Korundum. A must if you want to develop software with QtRuby/Korundum.

'''[http://www.charlesriver.com/Books/BookDetail.aspx?productID=114877 Open Source Game Development: Qt Games for KDE, PDA's, and Windows]'''

This book provides beginning and intermediate game programmers with a step-by-step resource to desktop game programming. The reader is introdcuded into the development of a desktop game application using Qt3/Qt4/Qtopia/KDE as development platform. Desktop game relevant topics such as pathfinding, AI, sound, 2D and 3D graphics and network programming are introduced in the scope of Qt and KDE. All topics are accompanied by plenty of source code examples in the book and on the companion CD-ROM.

Available via: [http://www.amazon.com/gp/product/1584504064 Amazon]

==== German ====

[https://www.opensourcepress.de/index.php?26&backPID=15&tt_products=23 Qt 4: Einführung in die Applikationsentwicklung von Daniel Molkentin]

==== Russian ====
[http://www.bhv.ru/books/book.php?id=186572 Qt4.5. Профессиональное программирование на C++]

===C++ Programming Books===

==== English ====

'''A Complete Guide to Programming in C++'''

Suited for both complete novices and advanced users of C++. Takes a clear and logical approach using uncluttered English and purposeful examples. With examples and website content, it represents great value for the money and is highly recommended as both a tutorial for students and newcomers to C++ and a dip-in guide for more advanced practitioners. This book teaches you the C++ STL in a natural way while learning C++, while many others relegate the STL to an appendix.

Available via: [http://www.amazon.com/gp/product/0763718173 Amazon]

'''Problem Solving, Abstraction, and Design Using C++'''

This book presents introductory programming material. Only the features of C++ that are appropriate to introductory concepts are introduced. Object-oriented concepts are presented. Abstraction is stressed throughout the book and pointers are presented in a gradual and gentle fashion for easier learning.

Available via: [http://www.amazon.com/exec/obidos/ASIN/0201612771/ Amazon]

'''[http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html Thinking in C++]'''

The effective presentation, along with dozens of helpful code examples, make this book a standout. The text first sets the stage for using C++ with a tour of what object-oriented programming is all about, as well as the software design life cycle. The author then delves into every aspect of C++, from basic keywords and programming principles to more advanced topics, like function and operator overloading, virtual inheritance, exception handling, namespaces, and templates. C++ is a complex language, and the author covers a lot of ground using today's Standard C++, but without getting bogged down in excessive detail.

Available via: [http://www.amazon.com/exec/obidos/ISBN=0139798099/ Amazon]<br />
Available via: [http://www1.fatbrain.com/FindItNow/Services/home.cl?from=YGY567&store=1 Fatbrain]

'''Accelerated C++: Practical Programming by Example'''

If you don't have a lot of time, but still want to learn the latest in C++, you don't have to learn C first. You might learn more by digging into current language features and classes from the very beginning. That's the approach that's offered by Accelerated C++, a text that delves into more advanced C++ features like templates and Standard Template Library (STL) collection classes early on. This book arguably can get a motivated beginning programmer into C++ more quickly than other available tutorials.

Available via: [http://www.amazon.com/exec/obidos/ASIN/020170353X/ Amazon]

'''Effective C++: 50 Specific Ways to Improve Your Programs and Design'''

Highly recommended by KDE core developers! It is not a book on syntax, so this should not be the 1st C++ book that you read -- but it should *definitely* be the 2nd! An absolutely terrific book focusing on basic C++ and object-oriented programming techniques. A crucial book for anyone new to C++ to read.

2nd Edition Available via: [http://www.amazon.com/exec/obidos/ASIN/0201924889/ Amazon]<br />
3rd Edition Available via: [http://www.amazon.com/exec/obidos/ASIN/0321334876/ Amazon]

'''More Effective C++: 35 New Ways to Improve Your Programs and Designs'''

From the author of the indispensable Effective C++, here are 35 new ways to improve your programs and designs. Drawing on years of experience, Meyers explains how to write software that is more effective: more efficient, more robust, more consistent, more portable, and more reusable. In short, how to write C++ software that's just plain better. For programmers at the intermediate level and above.

Available via: [http://www.amazon.com/exec/obidos/ASIN/020163371X/ Amazon]

'''C++ FAQs'''

This book answers all the questions one can imagine about C++. The author explains the reasoning and principals behind good OO design in a simple and well informed manner. See also the free online [http://www.parashift.com/c++-faq-lite/ C++ FAQ LITE]. If you like the online lite version, you will be ecstatic about the printed book version because it covers much more.

Available via: [http://www.amazon.com/exec/obidos/ASIN/0201589583/ Amazon]

'''[http://www.icce.rug.nl/documents/cplusplus/cplusplus.html C++ Annotations]'''

This online book is intended for knowledgeable users of C who would like to make the transition to C++. It is a guide for C++ programming courses given at the University of Groningen, Netherlands. As such, the book is not a complete C++ handbook. Rather, it serves as an addition to other documentation sources.

Available via: [http://www.amazon.com/exec/obidos/ASIN/020163371X/ Amazon]

'''The C++ Programming Language'''

By Bjarne Stroustrup, the creator of C++. This book is not for people who do not have programming experience in C++ already. This is not a ground up tutorial on how to program in C++, and it is not a fast read. What this book is, however, is probably the best reference book on C++ in existance.

Available via: [http://www.amazon.com/exec/obidos/ASIN/0201700735/ Amazon]

===Other Books===

'''[http://doc.trolltech.com/guibooks.html Books on GUI design]'''

Trolltech's recommendations of books about GUI design.

===Historic===
'''[http://developer.kde.org/documentation/books/kde-2.0-development/index.html KDE 2.0 Development]'''

A 540 page book available online and in print. Covers KParts, DCOP, aRts, KDevelop, licensing, introductory programming, and other topics. The [http://kde20development.andamooka.org support site] has the full text in various formats along with community annotation and discussion of KDE development. This book is as close to an Official Book by the KDE Project as possible. All authors and technical editors are KDE developers.

== IRC Channels ==
In general, IRC channels mentioned here are available on FreeNode. Connect to irc.kde.org, and check these channels out for further information.

*KDE User Channel - [irc://irc.kde.org:6667/kde #kde]
*KDE Development - [irc://irc.kde.org:6667/kde-devel #kde-devel]
*Phonon - [irc://irc.kde.org:6667/phonon #phonon]
*Decibel - [irc://irc.kde.org:6667/decibel #decibel]
*Solid - [irc://irc.kde.org:6667/solid #solid]
*Plasma - [irc://irc.kde.org:6667/plasma #plasma]
*KDE EDU - [irc://irc.kde.org:6667/kdeedu #kdeedu]
*KDE Games - [irc://irc.kde.org:6667/kdegames #kdegames]
*KDE PIM - [irc://irc.kde.org:6667/kontact #kontact]
*KDevelop IDE - [irc://irc.kde.org:6667/kdevelop #kdevelop]
*Amarok - [irc://irc.kde.org:6667/kdevelop #amarok]

== Newsgroups ==
== Forums ==
== Events ==
== Courses and Certifications ==
== Audio and Video Casts ==
== Source Code Repositories ==

Contribute/Quality Team

2012-05-22T12:32:33Z

Mamarok: Added definitions with links

[[Category:Quality]]
[[Category:Testing]]

A software project is only complete when there also is a general Quality Assurance. A broader definition of Software Quality Assurance can be found in the following links:

http://en.wikipedia.org/wiki/Software_quality_assurance
http://en.wikipedia.org/wiki/Software_quality_management

Software Quality is usually defined by various standards, on being the recommendations made by [http://en.wikipedia.org/wiki/CISQ CISQ]:

Reliability - Efficiency - Security - Maintainability - adequate Size

A more detailed information about this can be found here: http://en.wikipedia.org/wiki/Software_quality

== Domains in KDE where Quality Assurance is needed ==

*[http://community.kde.org/Getinvolved/Testing Software Testing]
*[http://techbase.kde.org/Contribute#User_Interface Usability]
*[http://community.kde.org/Getinvolved/accessibility Acessibility]
*[http://community.kde.org/Getinvolved/documentation Documentation]
*[http://community.kde.org/Getinvolved/translation Translation]
*[http://techbase.kde.org/Contribute/Bugsquad Bug handling]

=== Archive ===

For a more in-depth view on Software Quality, see [[Contribute/Quality Team/Essay]]

Contribute/Quality Team

2012-05-22T09:45:16Z

Mamarok: moved old text to Essay, made a link

[[Category:Quality]]

For a more in-depth view on Software Quality, see [[Contribute/Quality Team/Essay]]

Contribute/Quality Team/Essay

2012-05-22T09:42:41Z

Mamarok: moved Contribute/Quality Team to Contribute/Quality Team/Essay: The current text is far too long

== Introduction ==

In short, the task of the KDE quality team is to detect the loose ends in an application, and try to tie them together. The team objectives are similar of those of a project manager in a commercial organization. The main challenge of the team member is to interact with different areas of the application development, as there is much to learn.<br /><br />

But that does not mean you have to know all these areas: you can focus in one specific point of the application, like answering users questions, writing articles, documentation, creating artwork, whatever you want! Just find a lacking area and start working! After you feel you have the time and will to try something new, come back here to check the information available for that specific task. This guide's job is to organize all practical information to help you.<br /><br />

There is also a version of this guide at the KDE Wiki Site (wiki.kdenews.org), but it is not updated anymore. If you discover errors or if you know how to make this guide better, feel free to modify the KDE repository (if you have a SVN account), or e-mail the quality.kde.org Webmaster with your changes.

== Documentation ==

Writing documentation is a great way to start helping your application and the KDE project. If you decide to help out, your words will be translated to all languages covered by the KDE translations teams, and you will be helping thousands (millions?) to understand better their desktop and applications. Anyone with reasonable English skills and good knowledge of an application can help.

Modifying the documentation of an application involves: having your local KDE sources working folder, locating the files you want to work with, opening them, adding your improvements and sending the projects your modifications. To quickly learn how to do this, please check the Why Build and Maintain a KDE SVN Working Folder? guide.

Documenting an application involves help documents and context help. Context help is the quick pop up containing a short explanation you get when using the context help hotkey (usually Shift+F1) and clicking on a widget. This help is limited to the objective function of that widget, but it may be exactly what the user was needing to know, thus avoiding the need to open the full help system.

Help documents, (or an application manual, the set of help documents for an application), offer more comprehensive help about an application, and can include detailed information, examples, links to other documentation, information about menu commands, dialogs, screenshots, etc... Since the documentation is translated to many different languages, all the references in the help documents to screenshots, menu items, widgets or dialogs have to be translated in synchrony with the actual application and screenshots. To address this, the document format and tools used for help documents are designed for multi-lingual documents.
Context Help: Whatsthis

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: WhatsThis Tutorial, by Aaron J. Seigo.
Application Help Or Manuals

The KDE help system is based on the docbook format. This format and related tools make it easier to translate and to maintain the documentation for the whole project. The format was specifically designed by the OASIS group with technical documents in mind, and it is a XML based specification. The documentation for each module can be found in the doc folder.

Writing the documents in docbook format is highly recommended. But if you want, you can start improving the documentation now, and learn the docbook format later. but if you do so, please use text only format (ASCII). This way it will be easier for the documenters to transform it to docbook later.

Do not start from scratch if documentation for your application exist: try to improve it. Explain all commands, the main window organization, in sum, all aspects of the interface. A more complete list of what to write about is in the Questions You Should Answer When You Document KDE page, from the KDE Documentation Team Website.

Try to be user friendly, and try to write to the public of your application. Don't forget to proof your text for American English. You can find these tips and consistency rules in The KDE Style Guide. It is short, simple and obligatory. Its purpose is to maintain a uniform level of quality in the documentation.

For writing using the docbook format, the recommended place to start is the The Crash Course to Docbook. It will give you the basic knowledge to start. For more KDE specific stuff, please refer to The KDE Markup Guide to write your first document.

To help you in this process, you can use many tools. Kate is recommended for writing XML documents, and it is specially useful if you install the XML plug-in from the kdeaddons module. Don't forget to enable it after installing, by opening Kate, clicking the Settings menu, and the in the Configure Kate... menu item. Click the application/plugins icon inside the left side tree view, and check the Kate XML Completion and Kate XML Validation boxes. Now you will be able to see the XML menu when using Kate. If you are editing a docbook document, click the XML menu, then assign meta DTD and selecting the KDE docbook DTD, and you will transform Kate in a powerful docbook editor.

== User Interface ==

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it. The good part is that given the Qt/KDE Framework, there are some things even a non developer can implement.

The KDE Usability Mailing List is very active and a good place for discussing your ideas. If you are already an usability expert, please check OpenUsability.org, a project that brings open source developers and usability experts together, and is collaborating closely with KDE.
Before Starting: Guidelines And Useful Documents

You don't need to read the documents listed here to perform simple tasks, like verifying shortcuts' coherence with other KDE programs, making simple logical analysis or presenting anecdotal usability feedback and opinions. More knowledge is required to perform a more profound study, but you will find all the information needed easily.

The basic KDE documents on usability are KDE User Interface Guidelines (design standards) and KDE User Interface Guidelines (design principles). The first is a comprehensive collection of standards for KDE applications, or in other words, down to earth conventions and rules for immediate use. The second is a general set of useful principles for designing user interface, and a good place to start studying.

There are books and other good sources of information about this fascinating subject, many of them online. The KDE Usability Website has an excellent collection of usability information, including windows, apple and gnome user interface guidelines, usability course notes and even an online book on the subject.
Analysis

You can perform very useful analysis using the KDE user interface guidelines and other usability material. Suggestions on what to cover include:

KDE User Interface Guidelines (design standards) conformance: It sets standards for the maximum dialog size, exiting applications and closing documents, capitalization rules, among others. It is really a very good to start reviewing the user interface, as it covers all mains aspects of common applications: dialogs, menus, toolbars, shortcuts and accelerators, drag and drop, the status bar, etc... All KDE application should at least follow these standards, and below we assume they do.

Shortcut keys coherency and accessibility: to reduce the learning time required for an application, shortcut keys should, first, follow as closely as possible the scheme already used by other KDE applications, and second, follow the scheme used by similar applications. One good example is making Konqueror use the same basics hotkeys as Mozilla or Internet Explorer. If you don't agree with a shortcut used in widely in KDE, don't make your application different, try to persuade other people to change to your approach instead. Another good target is to minimize the use of more than two keys at the same time for the most important functions, as handicapped people may have difficulties accessing commands with tree or more keys at the same time. Verify if a commonly used action lack a shortcut, and do some research on what key should be used for it: consistency is the main priority, look what other KDE or similar applications do.

Dialogs review: The basic rules are the user should not be required to read about things unrelated to his current task or decide about things he does not want to. He should get things done easily, fast and with minimum data entry. Worthy points to review are if the dialogs are clear, if the widgets are displayed in a logical sequence, avoiding unnecessary information, if the information is presented in relevance order, if related options are grouped together, either in a simple dialog or a more complex multi-tab dialog. You can use the KDE User Interface Guidelines (design principles) as a guide, checking if its principles are being followed. The Configuration dialogs are constantly being redesigned, because new options are constantly being added and obsolete ones removed, making them obvious targets for review. Examples of improvements are the Panel Configuration Dialog Redesign or the Clock Applet Configuration Dialog.

You have a powerful tool to help you improving the dialogs: the Qt Designer. Using the Qt framework, you have two basic option to write dialogs: a text editor, as writing the general code of application (usually .cpp files) or the Qt Designer(.ui files). If the dialog you are reviewing was developed using the Qt Designer, you may redesign it yourself, even if you have little knowledge of programming. Search for all .ui files among the source files of your application. Open them (you can use the faster ui file viewer) to see if it is the desired dialog. If you cannot find the dialog you are analyzing, it may be because it is hand coded or a shared dialog from KDE libraries (module kdelibs from KDE CVS).

Even if the dialog was written by hand inside the code (no .ui file), you can make a proof of concept using the designer, a mock-up, to show other people your ideas and state clearly the seriousness of your proposal. Trolltech makes available as part of the Qt Designer Manual, a small guide on how to create dialogs using the Qt Designer that should enable you to create simple dialogs or mockups.
Usability Tests

An example of empirical test is your own experience with the software. The challenge is to transform it from subjective opinion to objective facts people can work with. One idea is to perform a simple user test, you being the user, setting tasks to perform, documenting the process, taking notes of the problems you find and providing solutions. Most of your conclusions can be used in a way or another to improve the application. But it can be even more useful if the test could be extended to more people, as you are probably not a regular user: you have more intellectual curiosity, different habits and are more capable of working around design flaws. To prove that, the evidence is that you are reading these lines...

It is easy to perform a usability test with other users, and it may result in major improvements in your application. Select the most important tasks to perform with your application and find some friends to perform them. The people you select should fit the profile of the user the application targets, so make a small questionnaire about people's background. More information and tips on how to perform an usability test can be found in the short and useful Infodesign usability testing page (also in PDF format). Employ a chronometer to record the time taken to perform each task and take note of all pitfalls found. Tabulate the data and try to extract conclusions and recommendations. There is invaluable insight and information to be obtained in this kind of test. An example of field test with KDE is the Relevantive Report on KDE usability.

== Bug And Wish Reports Management ==

The main communication tool between developers and users, and the main quality tool is the KDE bugs and wishes database. The database is implemented using the Bugzilla tool for tracking bugs and wishes, developed initially for the Mozilla web browser. Bugs.kde.org is the the web front end implementation of KDE's Bugzilla, and the main place to go when managing bugs, but there are other front ends: the KBugBuster, from the kdesdk module and the e-mail interface, used to add comments, change bugs status, etc...

Many bug reports are filed daily, especially after releases. There are too many to be handled by the developers, so the amount of open reports increases over time. Additionally old bug reports have to be revisited regularly to see if they still apply to the current version. Reviewing the bugs database also give you insight about the most needed features and most pernicious bugs, allowing you to point them, and the developers to actually fix bugs or spend time to add new features to KDE, instead of managing bugs.

Always direct users to the KDE bug tracker system to discuss bugs and wishes, because this way issues will not be forgotten. If the point is a bit more polemic, it is sensible to start a discussion in the application mailing list or in KDE usability mailing list, but instruct them to start by filing the bug, because by searching for similar bugs or wishes they may find answers or insight.
Before Starting

To start, open an account on bugs.kde.org if you don't have one. The database records not only the bugs and wishes status, but also related discussions, screenshots, patches, etc.. turning it to a very complete source of information. Please try the following pages at bugs.kde.org, to get used to KDE bugzilla capabilities. The KBugBugster is also useful, but less flexible.

* Simple search form
* Advanced search form
* New wishes/bugs wizard

There are a few fundamental name conventions that you should know:

* Bug status (UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, VERIFIED and CLOSED). (NOTE: Because KDE is missing a team which double checks that bugs are really fixed, the VERIFIED and CLOSED states are not used).
* Resolution (FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME).
* Severity (WISH, LOW, HIGH CRITICAL).

At the beginning, you will only be able to comment on bug reports which are not your own. Only after acquiring more knowledge on the application and on KDE Bugzilla system, you may ask for rights to confirm bug reports and close non verifiable ones.

You need a current KDE installation in order to be able to test if a bug is still uptodate. This means you should either test with 'trunk', that is the latest development-version of KDE, or the latest branch of KDE. For KDE 3 this is KDE 3.5. Then, you can confirm them, or close if not verifiable. Please refer to the Maintaining your own updated KDE version guide for more information on how to keep an update version of KDE.

Also it is important to have a KDE version compiled with debug information. KDE binaries compiled with debug information are bigger and run slower, but provide invaluable information to the developers when applications crash, as they are able to locate where in the source code it crashed, and sometimes even why. Whenever an application crashes, the KDE crash handler appears. You can now retrieve the backtrace information to add to a bugreport.
Managing Reports

The main tool for bug triage is knowledge of your application. You will learn that you don't need to be a developer to have a good understanding of it: reading bug reports and comments about them, writing documentation or working with the application's user interface will do the trick.

You should always start by stating your opinion in the bug reports and letting the developers take the appropriate action. If you feel you are ready to manage bugs effectively, know well the application and have a bit experience with bugzilla, it is time to ask for permissions. The Quality Team mailinglist, the KDE system administrator, or the mailinglist of the application you are working with, are the right places to ask for it. The developers will probably be happy to have someone working with them, and in the end of the day it is your own reputation as a good contributor that is in the line, as developers will still watch what you are doing. Some of the task below require these permissions.

A good way to start is checking if bugs are still valid:

* Believe the reporter: if you cannot reproduce a new bug, first ask for more context information, then think about closing it or asking to close it.
* The bug may be triggered by a combination of factors, or the bug may be fixed in the main branch, but not in the stable branch (if so, ask in the bug report for a backport. If it is not doable, the developers will say so).
* Add any additional information you can give, e.g. backtrace, additional observations, how to (better) reproduce the faulty behavior or simply add with which day's version the bug still appears.
* If you can reproduce an UNCONFIRMED bug, please write that in the bugreport and change its status to NEW.
* If a program hangs, you can "kill -SIGSEGV Processid" the process to get a backtrace.
* Check if the report is filed into the correct product and component category too. KDE is a very modular, and massively reuse code, and sometimes is hard even for the developers to detect in which component the bug is, so be careful. If the report is not already assigned to some other developer than the current component owner, make sure to select the "Reassign bug to owner of selected component" when moving a report. If a report is filed into a category where there is no single maintainer/active developer and you know which developer is responsible or works on the code (a look into the source or reading kde-cvs mailing list can help), you may assign a bug report to him/her directly.
* Check if a report describes an error already described in another closed or open report: Resolve it as DUPLICATE with reference to the prior report.
* Check if the same report was submitted more than one time. Please close the identical bug (the one with the highest number) as INVALID and not as DUPLICATE because otherwise they show up wrongly in the most frequently reported bugs statistics.

Browser (Konqueror) bugs are usually very easy to check and there are lots of them:

* Add "(regression)" to the title if the page was correctly rendered in a previous stable release.
* It's a good idea to put the site into the title where an error was encountered to ease duplicate spotting.
* A parallel installation of a Gecko-based browser and Opera can give you an idea how a web page probably should look like.
* Try to generate a stripped down testcase of a faulty rendered webpage. Add "(testcase)" to the title if a testcase is attached to the bug report.
* If a webpage doesn't exist any longer or was obviously rewritten and there was no testcase provided, close the report as WONTFIX.
* If the reporter or a comment mentions that a page works fine in Safari, it can help the developers to note that in the title too.

Check if the severity is appropriate, but if you don't agree, state so in the bugreport. Let the maintainer change the severity, as it is used by them to remind to fix crucial issues.

Check if the title contains a good summary, e.g. feature requests titled "Feature wanted" don't help when glancing over the report list. If a patch is provided add "(patch)" to the title.

Note: Don't use the "Change Several Bugs at Once" feature for moving reports. There is a bug in Bugzilla which confirms every reports which gets moved.

== Programming ==

Even if you have some programming experience, diving into the KDE project can be a bit daunting at first. It is a very vast project and there are many things that you will have to learn before you can really become productive as a developer. And it may take some time too.

So you want to make a start. But where do you begin? How can you find your way in this labyrinth of webpages, mailinglists, files, HOWTO's, etc.? The objective of this guide is to set out a learning path for a would-be KDE developer. These are just suggestions, of course. If you feel are already proficient with C++ or Qt, jump the respective steps.
Step One: Brush Up Your C++

C++ is the programming language for KDE. If you don't know the language of if your exposure to C++ has been limited, you should learn it. There are many books on the market that can help you and you will find many on-line tutorials that will teach you the C++ essentials. Get hold of Bruce Eckels Thinking in C++ on the web. It is excellent and it is free.

Using KDevelop as your IDE is strongly recommended, so make your life easy and use KDevelop to help you adapt to Qt and KDE. You will be learning to use KDevelop in parallel with exploring C++, Qt and KDE. Make sure that you have KDevelop 3.0 installed and go to www.kdevelop.org. There is plenty of information there. But start with the KDevelop 3.x tutorials.

A good idea is, after reading some of the information below, building an empty program, just generating an empty KDE project. That will give you a skeleton code that produces standard windows, menu, etc. Examine the code, try to understand it. This is very good first step on understanding the basics of a KDE app.
Step Two: Study the Qt Toolkit

Although KDE applications are written in C++ it is nearly all done using the Qt application framework. Qt is a product from a Norwegian company called Trolltech and you can find all information that you need about it on their webpage. Don't miss the most important page for would be developers: Qt Reference Documentation. You will find exactly the same page on your PC if you have a full installation of Qt. Read at least the Whitepaper and browse the beginning of the tutorials.
Work Your Way Through The Qt Tutorials

The first tutorial from Trolltech is fun and it will teach you a lot about Qt. Try to make it work using KDevelop and make the changes necessary to turn it into a real KDE project. (You could try to get rid of some of the on screen widgets and replace them by menu options.) Then you can work on the second tutorial and try to turn that into a real KDE application too.

Another use the Independent Qt Tutorial. The Independent Qt Tutorial is a on-line book introducing the different areas of Qt step-by-step with task orientated chapters rich on examples and a detailed discussion of the different areas of the Qt toolkit.
Study The Qt Examples

Try to understand the other examples that come with the Qt library. Pick at least one and try to recreate it, starting from a KDE skeleton application provided by KDevelop and typing in the code for yourself.
Step Three: Familiarize Yourself With a Real KDE Project

Pick a simple KDE application that you like, any one will do, then go to webcvs find the sources and browse the files that you find there, or download the sources using anonymous svn. Look at the different versions of one file and use the Diff to previous option for this purpose. The fact that you can choose your starting point for a comparison and that you can see the changes clearly using the colored option makes this a great learning tool for understanding the evolution of the code. Pick one area of the application and try to really understand it.
Read All Info On The kde.org Sites

Go back to the kdevelop website and read the other articles there on KDE development. Go to the KDE Developer's Corner and discover yet another treasure trove of information. Go to the home pages of your favorite applications (you will find links to these on the KDE Homepage) and see if the developers have put up some specific information that you can use. Some projects will have their own developers pages. Have a look at the KOffice Developers Resources as an example. You should try to find the API documentation for the project on which you want to work. And don't forget the Wiki pages! They are an excellent source of information too.
Follow KDE Policies

If you are willing to contribute code to the KDE project, it is important to know its policies, understand the role of the application maintainers and the release schedule freezes. You will be working inside project driven by volunteer work, where the doer usually decides the best implementation. The KDE Development Policies page lists the rules to be followed by KDE contributors. There are Commit policies, licencing policies, security policies, and library documentation policies. If you have any comments or doubts about these policies, please direct them to the kde policies mailing list.

To get a feeling for what is going on and what the current problems are, who is who and what they are working on, you should subscribe to a couple of mailing lists. Don't forget to visit the archives to get some historical perspective and to get an answer to your many question before you start asking for the obvious.
Step Four: Become an Active Bugbuster

Go to bugs.kde.org, register and use the querytool to find the open bugs for your favorite application. Find an annoying bug and start hacking. Be sure to work on a recent version of the application? You can check very quickly if that part of the code is still up to date with webcvs. This is the right moment to build an unstable-version, either from SVN or from a daily snapshot. Check the [http://community.kde.org/KDE/Junior_Jobs Junior Jobs] for a list of tasks related to open bugs or wishes that are marked for newbie developers. These tasks are usually a great way to start, as the developers or maintainers are explicitly telling you that you are welcome to fix the bug or implement the wish, and at the same time, the task should not be too complex.

After all of this you will probably be very close to making your first contribution. So if you have found a way to solve a bug, or to advance your project in some other way, adapt the code, post your patch, cross your fingers and hope that it will get accepted.

If you have doubts about helping out KDE, you are welcome to post them in the kde-quality mailing list. To support new contributors is the main goal of the project, so feel free to ask anything related to start helping KDE. For more technical programming doubts, use the application development mailing list, or in its absence, the the kde-devel mailing list.

And don't forget that after reading this you feel that it may be too much and too complicated for you, that there are other ways in which you can help. Visit the KDE Quality Team to find out what else you can do.

== Communication And Promotion ==

An open source product is a result of voluntary work, and the key to its success is the ability to attract new volunteers. Widespread use means usually more probability of attracting prospect contributors, developers, documenters, translators, individuals or part of a corporation or government into contributing. To promote your application, you can write an submit to news sites articles or guides showing interesting features or tips, write HOWTOS (a small guide for explaining how to perform a specific task), submit previews of future features available in the SVN version.

But even if your application is extensively deployed, this does not automatically means that you will attract people who test beta software and file bug reports, and eventually, people who could join the developers, the quality teams, the translators or the documenters. The first step is trying to be newbie friendly, and to educate newcomers. For instance, directing users in mailing lists to the right sources of information, in a friendly manner is a step in this direction. Lists are potential sources of new contributors, and building a strong community means teaching them they can act to improve the software they use.

Lowering the the barriers to contributing can lure more people to walk the first step. The kde-look.org website makes this easy by allowing people to quickly post their work and receive feedback. Some new contributors can go a long way with feedback, good information and some trust. The kde wiki site (wiki.kdenews.org) is an excellent tool to let people formalize discussions and suggestions. Sometimes, the developers refrain from discussing issues with users because most of the messages and suggestions are naive, because there is already a tool to track issues (bugs and wishes: the KDE bugzilla implementation, and because they may be busy implementing features or fixing bugs. The KDE quality team can fill this gap and organize the users feedback into meaningful proposals.
Interacting With Users

Linux is growing into mainstream acceptance. This is both an opportunity and a challenge.

The challenge is to communicate with more and more users who have a different background. They are used to pay for software and expect the software house to do all the work and complain when something is wrong. Many of them will be less than helpful, and simply won't understand the restrictions of open source development, but this is a natural initial behavior.

The opportunity is to use the new flux of people to improve KDE, in any form. Also, users sometimes bring valuable feedback in confuse or improper way. Further dialog with the user can clear the issue, become a new bug or wish report or add valuable comments to existing bug and wish reports, turning the rant into useful information. Obviously, the best way to do it is to instruct the user to fill the report himself. Filling a bug is the first step for a kde contributor, a very valuable step. Every new user for bugs.kde.org (KDE bugs and wishes database) is a small victory, as the user started to understand what free software is about.

The main channel of communication with users are the user mailing list for your application, or in the absence of one, The KDE general users mailing list, or The KDE linux mailing list. Subscribing to these mailing lists is recommended. Other sources of user feedback are The KDE forum and The KDE wiki site. These channels are also a good place to spot potential contributors to KDE. Point them this guide and the KDE Quality Team mailing list if they are interested.

Keeping your application web page up to date with HOWTOs to perform the most complicated tasks, frequent asked questions (FAQ) responses, a summary of features and capabilities and recent news and articles also help. This gives a professional feeling to the application, implies that the application is actively maintained and offer good services to users. If your updates to the documentation did not make the KDE release schedule, post it in the application website. There is a tutorial on how to write a web page for KDE.org new layout.
Promoting Your Application

Linux is still in his infancy in terms of desktop deployment. Most people probably never tried your application, so it is important to promote it, in order to compete in market. Promotion is fundamental, as it not only increases the probability that your product is considered as a valid option, but it helps avoiding dangerous pre-concepts and myths.

One of the best ways to promote your application is to submit articles to news sites. The first and obvious choice is The KDE News Site (The Dot), but there are others sites where you can send articles. It is even useful to submit the article first to a news site and the submit a link in The Dot, as they give more importance to exclusive material. Your article can be a tutorial or walktrough (explaining how to perform certain tasks, better yet if in a graphical way), a preview (show features of an upcoming release), a test (user interface test, a benchmark, etc...) or a review. Present detailed information and screenshots, and compare similar software if applicable. There is always something to write about.

You can send articles or news (links). Articles are original material you wrote, and news are links to stories you consider good publicity for your application or KDE.

To learn more about how to work with the media to promote your application, read the Media HOWTO.
Interacting With Other Quality Team Members

Sometimes you or other members of the KDE Quality Team will need help to do something for the first time, or simply would like some peer review before proposing a change, posting an article, HOWTO or web page or writing a new doc. The idea is to help each other as we go, as nobody is a specialist in all areas, and there is a wide range of actions for the KDE Quality Team. So if you have any doubt, want to post a draft and receive feedback, the main tool is the KDE Quality Team mailing list.

One example of this interaction is this guide. This guide was originally written by Carlos Woelz, but the idea is to update it frequently with experiences and tips from the Quality Team members. A copy of this guide will always be available at the KDE wiki site for modification, and the website will be synced with wiki in regular intervals. Your experience is important, please correct any mistakes you find and add additional tips and information as you go.

One of the goals of this project is to provide step by step guides for new contributors. If you document your steps as you perform tasks not covered yet, you can easily add a new one.

Contribute/Quality Team

2012-05-22T09:42:41Z

Mamarok: moved Contribute/Quality Team to Contribute/Quality Team/Essay: The current text is far too long

#REDIRECT [[Contribute/Quality Team/Essay]]

Contribute

2012-05-21T15:41:01Z

Mamarok: /* Getting Involved in Bug Hunting and Application Quality */ fixed link

<languages />
<translate>

{{Template:I18n/Language Navigation Bar|Contribute}}
This page intends to give an overview of the different aspects of KDE development in particular for programming related issues. ''The KDE project welcomes anyone willing to help''.


{{Note|There are a lot of ways to get involved in KDE development, which can be summed up in several categories:
:''Documentation, Translation, Development, Usability, Accessibility, Artwork, Promotion
''Not a coder? See KDE's pages on [http://kde.org/community/getinvolved/ how to get involved] to see other ways you can help. Also see: [[Contribute/Bugsquad|Bugsquad]]!''
}}

== News and Mail Sources == 


The general direction of the KDE project is determined by those who do the work - there is no single high level plan for what KDE will look like in the future.


If you want to find out what is currently happening, then there are a number of sources you might like to consider:
; [http://www.kde.org/mailinglists/ Mailing Lists]
: Probably the best way to find out what's going on in KDE development. Archives are available [http://lists.kde.org here]


; [http://commitfilter.kde.org/ CommitFilter]
: Receive notification of commits to the KDE source code repositories in areas that interest you.


; [http://commit-digest.org/ KDE Commit-Digest]
: Weekly summary of commits to projects in the KDE source code repositories.


; [http://dot.kde.org/ The Dot]
: The KDE news site.

== Reporting Bugs == 


The easiest way to contribute to KDE is to [http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs report any bugs] you find in KDE using the [https://bugs.kde.org/ KDE Bug Tracking System] (also known as '''Bugzilla''').


If the application you are using crashes then the '''Dr Konqi''' utility will appear and guide you through the process of reporting the crash. Learn more by reading [[Development/Tutorials/Debugging/How_to_create_useful_crash_reports|how to create useful crash reports]].

== Getting Started with Coding == 


Getting started at coding for KDE is a matter of finding something to fix, and fixing it. You may want to consult the module overview to help find what you are looking for; once you have fixed something, you will want to send in a patch. If you do that a few times, you may want to apply for a KDE Contributor account so you can improve things directly.


* [[Contribute/List of KDE Modules|Module overview]]
* [[Contribute/Send Patches|Sending patches]]
* [[Contribute/Get a Contributor Account|Applying for a KDE Contributor Account]]
* [[Contribute/First Steps with your KDE SVN Account|First steps with your new Contributor account]]

=== C++ === 


KDE is mostly written in C++. If you are not familiar with C++, you should do at least some work on it. There are a number of good books on C++ - an excellent source is [http://mindview.net/Books/TICPP/ThinkingInCPP2e.html Bruce Eckel's "Thinking in C++"], which is available both as a free download and as a printed document. It isn't essential to understand everything before you start in KDE, but you do need to understand basic syntax and operations.

=== Qt === 


To become proficient with KDE coding, you should understand the Qt toolkit. If you are not familiar with Qt, you should work through the tutorials included with [http://doc.qt.nokia.com/latest Qt Reference Documentation].


If you need a gentler introduction to Qt, or would just like an alternative view, then you may wish to look at the [http://qt4.digitalfanatics.org/tiqt/ The Independent Qt Tutorial] (Currently offline due to book contract).


If you prefer to learn Qt by reading a traditional book, take a look at the [http://qt.nokia.com/developer/books/ Books about Qt page]. More suggestions on becoming familiar with Qt4 are available [http://doc.qt.nokia.com/latest/how-to-learn-qt.html How to Learn Qt page].

=== KDE === 


A range of information on KDE techniques is available in the [[Development/Tutorials|tutorial section]]. Note that some of these tutorials still target KDE3, though they should be at least partly applicable.


You will also find useful information on KDE coding in the [[Development/FAQs|FAQs]] section. This information may also be somewhat dated for KDE4, however much of it is broadly applicable, even outside KDE.


You can also read [[Development/Further Information#Books|KDE coding books]].


Last, but by no means least, KDE comes with extensive class (Application Programmer Interface) documentation. This is available in the
[[Development/Tutorials/API Documentation|KDE API Reference Manuals]] section, which also contains a number of useful links on how to write or update the class documentation. You can also generate these on your own machine, or refer to a more up-to-date online version at [http://api.kde.org/ API Reference].


A more detailed description of the steps above is available in our [http://quality.kde.org/develop/howto/howtohack.php Programming Guide].

==== Context Help: Whatsthis ====

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: [http://bddf.ca/~aseigo/whatsthis_tutorial/ WhatsThis Tutorial], by Aaron J. Seigo.

== Getting Involved in Bug Hunting and Application Quality == 


There is a large number of applications within KDE, and not all of them have a maintainer dedicated to managing bugs and generally helping out with all the issues associated with turning some working code into a polished application.


If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the [http://techbase.kde.org/Contribute/Quality_Team Quality Team website] for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called [http://community.kde.org/KDE/Junior_Jobs Junior Jobs] to encourage new contributions.


Of course, you can become involved in bug hunting without being part of the KDE Quality Team - just create yourself an account on the KDE [http://bugs.kde.org bug tracking system], and start searching / sorting through the bugs. Again, you don't have to have programming skills - it helps the programmers enormously just to have a procedure that allows a bug to be consistently reproduced.


The [[Contribute/Bugsquad|Bugsquad]] tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the KDE community if you cannot program.

== User Interface ==

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it.

The [http://mail.kde.org/mailman/listinfo/kde-usability KDE Usability Mailing List] is very active and a good place for discussing your ideas, and their homepage is at http://techbase.kde.org/Projects/Usability. If you are already an usability expert, please check [http://www.openusability.org/ OpenUsability.org], a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Some documents guiding documents include the [http://developer.kde.org/documentation/standards/kde/style/basics/index.html KDE User Interface Guidelines (design standards)] and [http://developer.kde.org/documentation/design/ui/index.html KDE User Interface Guidelines (design principles)].

Some projects for analysis of user interfaces may include: checking that shortcut keys are coherent across KDE applications, making sure that dialogs are directly relevant to the interaction that the user would expect, and finding users of KDE software to see how they perform common workflows.

==Getting Answers to Your Questions== 


If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:
<blockquote>
:* '''Read the Developer FAQ'''. Many common developer questions have been answered in the [[Development/FAQs|KDE Developer FAQ]]
:* '''Search/browse KDE websites'''. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the [http://techbase.kde.org KDE TechBase website]. And if possible, help edit it for clarity, and use the talk page if something is unclear.
:* '''Search mailing lists'''. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists either at [http://lists.kde.org/ lists.kde.org]. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
:* '''Search engines'''. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also [http://groups.google.com/ search] the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.


:* '''Read the source code'''. http://websvn.kde.org and https://projects.kde.org/ are available to help browse code. Read some commit logs and diffs for the code you might want to work with, It adds perspective.
:* '''Ask on KDE mailing lists'''. If you still do not have an answer, try asking your question on one of the KDE mailing lists listed above.
:* For questions relating to core development or third-party KDE development, unless you are particularly interested in [http://konqueror.kde.org/ Konqueror], [http://www.koffice.org/ KOffice], games or Java development, your main choice is [mailto:kde-devel@kde.org kde-devel] [mailto:kde-devel-request@kde.org?subject=subscribe (subscribe)].
:* For questions relating to Konqueror development, your main choice is [mailto:kfm-devel@kde.org kfm-devel] [mailto:kfm-devel@kde.org?subject=subscribe (subscribe)]
:* For questions relating to KOffice development, your main choice is [mailto:koffice-devel@kde.org koffice-devel] [mailto:koffice-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to games development, your main choice is [mailto:kde-games-devel@kde.org kde-games-devel] [mailto:kde-games-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to [http://qt.nokia.com/ Qt development], please use the fine [http://lists.trolltech.com/qt-interest/ Qt mailing list].
</blockquote>


A full list of KDE mailing lists is available [http://www.kde.org/mailinglists/ here] and [http://mail.kde.org/mailman/listinfo here].


[[Category:FAQs]]
</translate>

Contribute

2012-05-21T15:35:58Z

Mamarok: /* Getting Involved in Bug Hunting and Application Quality */ fixing link

<languages />
<translate>

{{Template:I18n/Language Navigation Bar|Contribute}}
This page intends to give an overview of the different aspects of KDE development in particular for programming related issues. ''The KDE project welcomes anyone willing to help''.


{{Note|There are a lot of ways to get involved in KDE development, which can be summed up in several categories:
:''Documentation, Translation, Development, Usability, Accessibility, Artwork, Promotion
''Not a coder? See KDE's pages on [http://kde.org/community/getinvolved/ how to get involved] to see other ways you can help. Also see: [[Contribute/Bugsquad|Bugsquad]]!''
}}

== News and Mail Sources == 


The general direction of the KDE project is determined by those who do the work - there is no single high level plan for what KDE will look like in the future.


If you want to find out what is currently happening, then there are a number of sources you might like to consider:
; [http://www.kde.org/mailinglists/ Mailing Lists]
: Probably the best way to find out what's going on in KDE development. Archives are available [http://lists.kde.org here]


; [http://commitfilter.kde.org/ CommitFilter]
: Receive notification of commits to the KDE source code repositories in areas that interest you.


; [http://commit-digest.org/ KDE Commit-Digest]
: Weekly summary of commits to projects in the KDE source code repositories.


; [http://dot.kde.org/ The Dot]
: The KDE news site.

== Reporting Bugs == 


The easiest way to contribute to KDE is to [http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs report any bugs] you find in KDE using the [https://bugs.kde.org/ KDE Bug Tracking System] (also known as '''Bugzilla''').


If the application you are using crashes then the '''Dr Konqi''' utility will appear and guide you through the process of reporting the crash. Learn more by reading [[Development/Tutorials/Debugging/How_to_create_useful_crash_reports|how to create useful crash reports]].

== Getting Started with Coding == 


Getting started at coding for KDE is a matter of finding something to fix, and fixing it. You may want to consult the module overview to help find what you are looking for; once you have fixed something, you will want to send in a patch. If you do that a few times, you may want to apply for a KDE Contributor account so you can improve things directly.


* [[Contribute/List of KDE Modules|Module overview]]
* [[Contribute/Send Patches|Sending patches]]
* [[Contribute/Get a Contributor Account|Applying for a KDE Contributor Account]]
* [[Contribute/First Steps with your KDE SVN Account|First steps with your new Contributor account]]

=== C++ === 


KDE is mostly written in C++. If you are not familiar with C++, you should do at least some work on it. There are a number of good books on C++ - an excellent source is [http://mindview.net/Books/TICPP/ThinkingInCPP2e.html Bruce Eckel's "Thinking in C++"], which is available both as a free download and as a printed document. It isn't essential to understand everything before you start in KDE, but you do need to understand basic syntax and operations.

=== Qt === 


To become proficient with KDE coding, you should understand the Qt toolkit. If you are not familiar with Qt, you should work through the tutorials included with [http://doc.qt.nokia.com/latest Qt Reference Documentation].


If you need a gentler introduction to Qt, or would just like an alternative view, then you may wish to look at the [http://qt4.digitalfanatics.org/tiqt/ The Independent Qt Tutorial] (Currently offline due to book contract).


If you prefer to learn Qt by reading a traditional book, take a look at the [http://qt.nokia.com/developer/books/ Books about Qt page]. More suggestions on becoming familiar with Qt4 are available [http://doc.qt.nokia.com/latest/how-to-learn-qt.html How to Learn Qt page].

=== KDE === 


A range of information on KDE techniques is available in the [[Development/Tutorials|tutorial section]]. Note that some of these tutorials still target KDE3, though they should be at least partly applicable.


You will also find useful information on KDE coding in the [[Development/FAQs|FAQs]] section. This information may also be somewhat dated for KDE4, however much of it is broadly applicable, even outside KDE.


You can also read [[Development/Further Information#Books|KDE coding books]].


Last, but by no means least, KDE comes with extensive class (Application Programmer Interface) documentation. This is available in the
[[Development/Tutorials/API Documentation|KDE API Reference Manuals]] section, which also contains a number of useful links on how to write or update the class documentation. You can also generate these on your own machine, or refer to a more up-to-date online version at [http://api.kde.org/ API Reference].


A more detailed description of the steps above is available in our [http://quality.kde.org/develop/howto/howtohack.php Programming Guide].

==== Context Help: Whatsthis ====

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: [http://bddf.ca/~aseigo/whatsthis_tutorial/ WhatsThis Tutorial], by Aaron J. Seigo.

== Getting Involved in Bug Hunting and Application Quality == 


There is a large number of applications within KDE, and not all of them have a maintainer dedicated to managing bugs and generally helping out with all the issues associated with turning some working code into a polished application.


If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the [http://community.kde.org/Getinvolved/Testing Quality Team website] for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called [http://community.kde.org/KDE/Junior_Jobs Junior Jobs] to encourage new contributions.


Of course, you can become involved in bug hunting without being part of the KDE Quality Team - just create yourself an account on the KDE [http://bugs.kde.org bug tracking system], and start searching / sorting through the bugs. Again, you don't have to have programming skills - it helps the programmers enormously just to have a procedure that allows a bug to be consistently reproduced.


The [[Contribute/Bugsquad|Bugsquad]] tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the KDE community if you cannot program.

== User Interface ==

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it.

The [http://mail.kde.org/mailman/listinfo/kde-usability KDE Usability Mailing List] is very active and a good place for discussing your ideas, and their homepage is at http://techbase.kde.org/Projects/Usability. If you are already an usability expert, please check [http://www.openusability.org/ OpenUsability.org], a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Some documents guiding documents include the [http://developer.kde.org/documentation/standards/kde/style/basics/index.html KDE User Interface Guidelines (design standards)] and [http://developer.kde.org/documentation/design/ui/index.html KDE User Interface Guidelines (design principles)].

Some projects for analysis of user interfaces may include: checking that shortcut keys are coherent across KDE applications, making sure that dialogs are directly relevant to the interaction that the user would expect, and finding users of KDE software to see how they perform common workflows.

==Getting Answers to Your Questions== 


If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:
<blockquote>
:* '''Read the Developer FAQ'''. Many common developer questions have been answered in the [[Development/FAQs|KDE Developer FAQ]]
:* '''Search/browse KDE websites'''. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the [http://techbase.kde.org KDE TechBase website]. And if possible, help edit it for clarity, and use the talk page if something is unclear.
:* '''Search mailing lists'''. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists either at [http://lists.kde.org/ lists.kde.org]. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
:* '''Search engines'''. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also [http://groups.google.com/ search] the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.


:* '''Read the source code'''. http://websvn.kde.org and https://projects.kde.org/ are available to help browse code. Read some commit logs and diffs for the code you might want to work with, It adds perspective.
:* '''Ask on KDE mailing lists'''. If you still do not have an answer, try asking your question on one of the KDE mailing lists listed above.
:* For questions relating to core development or third-party KDE development, unless you are particularly interested in [http://konqueror.kde.org/ Konqueror], [http://www.koffice.org/ KOffice], games or Java development, your main choice is [mailto:kde-devel@kde.org kde-devel] [mailto:kde-devel-request@kde.org?subject=subscribe (subscribe)].
:* For questions relating to Konqueror development, your main choice is [mailto:kfm-devel@kde.org kfm-devel] [mailto:kfm-devel@kde.org?subject=subscribe (subscribe)]
:* For questions relating to KOffice development, your main choice is [mailto:koffice-devel@kde.org koffice-devel] [mailto:koffice-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to games development, your main choice is [mailto:kde-games-devel@kde.org kde-games-devel] [mailto:kde-games-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to [http://qt.nokia.com/ Qt development], please use the fine [http://lists.trolltech.com/qt-interest/ Qt mailing list].
</blockquote>


A full list of KDE mailing lists is available [http://www.kde.org/mailinglists/ here] and [http://mail.kde.org/mailman/listinfo here].


[[Category:FAQs]]
</translate>

Development/Tutorials/Debugging/Phonon

2012-04-27T19:58:58Z

Mamarok: /* Environment Variables */ removed xine debug

= Environment Variables =

In general, there is one easy way to give Phonon devs all the information they need to help fix your problem.

Set these environment variables:
<syntaxhighlight lang="bash">
$ export PHONON_DEBUG=5
$ export PHONON_PULSEAUDIO_DEBUG=5
$ export PHONON_VLC_DEBUG=5
$ export PHONON_GST_DEBUG=5
</syntaxhighlight>

Then run your program. The terminal will fill up with gobs of debugging output.

== Phonon-GStreamer debugging ==

=== Even more verbose output ===

Phonon-gst has some fancier debug options available. In addition to PHONON_GST_DEBUG, there is PHONON_GST_GST_DEBUG. Setting it to 8 or so will cause the gstreamer libraries to produce ''copious'' quantities of debug output. We're talking thousands of lines of what seems to be useless noise. Roughly 1% of it is useful, but the phonon-gst devs can easily decipher it and drill down to the important bits.

=== Pulseaudio ===

Pulseaudio and phonon try their hardest to get along. Sometimes, it doesn't work. Luckily, there is a way to test gstreamer and pulseaudio to see who is at fault.

<syntaxhighlight lang="bash">
$ gst-launch filesrc location=/usr/share/sounds/KDE-Sys-Log-In.ogg ! decodebin2 ! audioresample ! audioconvert ! pulsesink
$ gst-launch filesrc location=/usr/share/sounds/KDE-Sys-Log-In.ogg ! decodebin2 ! audioresample ! audioconvert ! alsasink
</syntaxhighlight>

If they both work flawlessly, blame Phonon-GStreamer.

If the first works but the second doesn't, you might have an exotic sound setup that involves tweaking the alsasink parameters to reflect what pulseaudio does to alsa.

If the second works but the first doesn't, you can blame pulseaudio.

Another way to confirm this is by setting the PHONON_GST_AUDIOSINK environment variable. Setting it to e.g. "pulsesink" uses the pulseaudio sink.

=== Recreating the phonon-gst pipeline ===

Phonon-GStreamer creates predicable pipelines. In general, they look like this:



<pre>
filesrc -> decodebin2 -> queue -> audioresample -> audioconvert -> pulsesink
\
-> ffmpegcolorspace -> queue -> xvimagesink
</pre>

If the input stream isn't coming from a file, it is likely coming in via KIO which pipes it into an abstractmediastream. If pulseaudio isn't used, then replace pulsesink with something of alsasink, osssink, or somesuch.

Recreating the playback stream of some video file can be done as such:
<syntaxhighlight lang="bash">
$ gst-launch filesrc location=/path/to/video ! decdebin2 name=dec ! audioresample ! audioconvert ! pulsesink \
dec. ! ffmpegcolorspace ! xvimagesink
</syntaxhighlight>

DVD playback is a bit different:
<pre>
(subpicture stream)
/--->---\
rsndvdbin -> dvdspu -> ffmpegcolorspace -> queue -> xvimagesink
\-> queue -> audioresample -> audioconvert -> pulsesink
</pre>

This is built with the following:
<syntaxhighlight lang="bash">
$ gst-launch rsndvdbin ! dvdspu ! ffmpegcolorspace ! queue ! xvimagesink \
rsndvdbin0 ! dvdspu0.subpicture \
rsndvdbin0 ! queue ! audioresample ! audioconvert ! pulsesink
</syntaxhighlight>

= Building Phonon from source =

If you want to have a newer Phonon build than 4.4.3 which is currently shipped by most distributions in KDE 4.6, you can build from source (git). Phonon is now located on git.kde.org.

== Get Dependencies ==

Deb-based distros, run <pre>sudo apt-get build-dep phonon</pre>to be sure you have all dependencies installed.
<br />
OpenSuSE:
<pre>sudo zypper si -d phonon</pre>

== Install git ==

In Kubuntu, Debian, etc.:<pre>sudo apt-get install git-core</pre>
In Archlinux:<pre>sudo pacman -Sy git</pre>
In Gentoo:<pre>sudo emerge -av dev-util/git</pre>
In OpenSuSE:<pre>sudo zypper install git</pre>

== Install ccache to speed up compilation ==

Install the package from your distribution and set the size of the cache to 2 GB with the command<pre>ccache -M 2G</pre>
This will take 2Gb of space in your local directory. Enable the use of ccache by adding it to your local .bashrc, described below.

== Define the PATH and local environment ==

Append the following to <tt>$HOME/.bashrc</tt>:
<syntaxhighlight lang="bash">
export PATH=$HOME/kde/bin:$PATH
export PATH=/usr/lib/ccache:$PATH
export LD_LIBRARY_PATH=$HOME/kde/lib:$LD_LIBRARY_PATH
</syntaxhighlight>

Reload your edited .bashrc:
<syntaxhighlight lang="bash">
source $HOME/.bashrc
</syntaxhighlight>
NOTE: if you are not using the bash shell, edit your proper shell config file (<tt>~/.zshrc</tt> or <tt>~/.tcshrc</tt> or whatever it may be).

== Make KDE aware of Phonon’s location ==
<syntaxhighlight lang="bash">
echo 'export KDEDIR=$HOME/kde' >> $HOME/.kde/env/myenv.sh
echo 'export KDEDIRS=$KDEDIR' >> $HOME/.kde/env/myenv.sh
</syntaxhighlight>
Some distributions call the above folder <tt>$HOME/.kde4/</tt>, such as OpenSuSE.

== Install locally==

Install in your $HOME dir):
<syntaxhighlight lang="bash">
mkdir $HOME/kde && cd kde && mkdir src && cd src
git clone git://anongit.kde.org/phonon
cd phonon && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon
sudo make install
</syntaxhighlight>

To update your build, it's even easier:
<syntaxhighlight lang="bash">
cd ~/kde/src/phonon
git pull
cd build && sudo make install
</syntaxhighlight>

== Build locally from a tarball ==

This is 4.4.4 for example:
<syntaxhighlight lang="bash">
cd ~/kde/src/
wget http://download.kde.org/download.php?url=stable/phonon/4.4.4/src/phonon-4.4.4.tar.bz2
tar xf phonon-4.4.4.tar.bz2
cd phonon-4.4.4 && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon-4.4.4
sudo make install
</syntaxhighlight>

Projects/PIM/Akonadi/Testing

2012-04-10T13:27:15Z

Mamarok: added category

[[Category:Testing]]

This page describes the Akonadi test and benchmark facilities.

{{tip|'''Further Reading:''' [[Projects/PIM/Akonadi/Development_Tools|Akonadi Development Tools]].}}

= Akonadi Testrunner =

Igor's GSoC project, found in kdepimlibs/akonadi/tests/testrunner. The Akonadi Testrunner sets up an isolated Akonadi server (which implies a separated D-Bus server) based on an environment configuration file.

== Creating Testrunner Environments ==

A testrunner environment consists of two components: a set of configuration and data files and a XML description file of the environment.

Here is an example listing based on the environment used for the libakonadi unittests:

<syntaxhighlight lang="bash">
unittestenv/
unittestenv/config.xml
unittestenv/xdglocal
unittestenv/kdehome
unittestenv/kdehome/share
unittestenv/kdehome/share/config
unittestenv/kdehome/share/config/akonadi-firstrunrc
unittestenv/kdehome/share/config/akonadi_knut_resource_0rc
unittestenv/kdehome/testdata.xml
unittestenv/xdgconfig
</syntaxhighlight>

The environment description file (''config.xml'')looks like this:

<syntaxhighlight lang="xml">
<config>

<kdehome>kdehome</kdehome>

<confighome>xdgconfig</confighome>

<datahome>xdgdata</datahome>

<agent synchronize="true">akonadi_knut_resource</agent>

<envvar name="AKONADI_DISABLE_AGENT_AUTOSTART">true</envvar>
</config>
</syntaxhighlight>

The first three elements define the relevant paths inside the environment data, relative to the ''config.xml'' file.
The ''<agent>'' element can be used to create instances of the specified agent (multiple such elements are allowed). If the agent is a resource, it can also be synced initially by adding the ''synchronize="true"'' attribute. Tests will not be launched before the syncing has been complete in this case.

Agents set up in this way can be configured by simply providing the corresponding configuration file in $KDEHOME, such as ''akonadi_knut_resource_0rc'' in our example.

Global configuration files can be provided in the same way, ''akonadi-firstrunrc'' as shown below is in particular useful to avoid the Akonadi default setup mechanism interfering with the test:

<syntaxhighlight lang="ini">
[ProcessedDefaults]
defaultaddressbook=done
defaultcalendar=done
</syntaxhighlight>

Same for ''kdedrc'' which allows to disable kbuilsycoca4. That can greatly speed up tests.

<syntaxhighlight lang="ini">
[General]
CheckSycoca=false
CheckFileStamps=false
</syntaxhighlight>

The ''<envvar>'' element allows you to set arbitrary environment variables inside the test environment. One useful example is ''AKONADI_DISABLE_AGENT_AUTOSTART'' which will prevent the Akonadi server from starting autostart agents, which can further speed up the setup process.

== Using the Testrunner ==

=== Interactive Use ===

For manual usage, the testrunner provides an interactive mode in which it sets up the environment and provides a way to "switch" into it.

First, start the testrunner:

<syntaxhighlight lang="bash">
$ akonaditest -c config.xml --testenv /path/to/testenvironment.sh &
</syntaxhighlight>

'''Note''': Although the testenv parameter is not required, it makes life a bit easier when testing manual. If you don't pass it the script will be generated in a temporary dir and is therefore a bit harder to find.

Once the setup is complete, it creates a shell script containing the necessary environment variable changes to switch into the test environment:

<syntaxhighlight lang="bash">
$ source /path/to/testenvironment.sh
</syntaxhighlight>

The environment variables of the current shell are then changed to point to the test environment (eg. KDEHOME, DBUS_*, etc.). Every Akonadi application run in that shell operates on the Akonadi server of the test environment.

To terminate and cleanup the test environment, run:

<syntaxhighlight lang="bash">
$ shutdown-testenvironment
</syntaxhighlight>

Note that your shell afterwards still points to the (now no longer existing) test environment and might not work as expected anymore.

=== Non-Interactive Use ===

''kdepimlibs/akonadi/tests'' uses the Akonadi Testrunner to run unittests in an isolated environment. For automated usage, the testrunner can be used in a non-interactive way:

<syntaxhighlight lang="bash">
$ akonaditest -c config.xml <comand> <params>
</syntaxhighlight>

The testrunner will run ''command params'' within the isolated environment and terminate afterwards.

This can be used from within CMake (example based on ''kdepimlibs/akonadi/tests''):

<syntaxhighlight lang="cmake">
macro(add_akonadi_isolated_test _source)
set(_test ${_source})
get_filename_component(_name ${_source} NAME_WE)
kde4_add_executable(${_name} TEST ${_test})
target_link_libraries(${_name}
akonadi-kde akonadi-kmime ${QT_QTTEST_LIBRARY}
${QT_QTGUI_LIBRARY} ${KDE4_KDECORE_LIBS}
)

# based on kde4_add_unit_test
if (WIN32)
get_target_property( _loc ${_name} LOCATION )
set(_executable ${_loc}.bat)
else (WIN32)
set(_executable ${EXECUTABLE_OUTPUT_PATH}/${_name})
endif (WIN32)
if (UNIX)
set(_executable ${_executable}.shell)
endif (UNIX)

find_program(_testrunner akonaditest)

add_test( libakonadi-${_name}
${_testrunner} -c
${CMAKE_CURRENT_SOURCE_DIR}/unittestenv/config.xml
${_executable}
)
endmacro(add_akonadi_isolated_test)
</syntaxhighlight>

Using QtTest unittests with KDE extensions (''QTEST_KDEMAIN'') together with the testrunner is problematic as they modify some of the environment variables
set by the testrunner. Instead, use the following:

<syntaxhighlight lang="cpp">
#include <qtest_akonadi.h>

QTEST_AKONADIMAIN( MyTest, NoGUI )
</syntaxhighlight>

= KNUT Test Data Resource =

In kdepim/akonadi/resources, fully featured resource that operates on a single XML file. File format is decribed in knut.xsd and follows closely the internal structure of Akonadi. New files can be created in eg. [[Projects/PIM/Akonadi/Development_Tools#Akonadi_Console|Akonadiconsole]] by creating a resource and specifying a non-existing file.

= Akonadi Benchmarker =

In kdepimlibs/akonadi/test, part of Robert's thesis.
It is a set of test that show the time to process many item/collection operations.

{{improve}}

= Unittests =

== Akonadi Server ==

Usable without installation, run with ctest/make test as usual.

== kdepimlbs/akonadi ==

These tests use the Akonadi Testrunner, the test environment is found in ''kdepimlibs/akonadi/tests/unittestenv''.

=== Setup ===

The tests do not yet completely work without having certain components installed, namely:

* Akonadi Server
* KNUT resource

=== Running the tests ===

The tests can be run automatically using ctest/make test as usual. To run a single test manually, it needs to be executed using the Akonadi testrunner:

<syntaxhighlight lang="bash">
$ cd kdepimlibs/akonadi/test
$ akonaditest -c unittest/config.xml $BUILDDIR/test_executable.shell
</syntaxhighlight>

== kdepim/akonadi ==

Are there any?

{{improve}}

= Resource Testing =

Tools to automatically test Akonadi resources are currently in development in ''playground/pim/akonaditest/resourcetester''. There are two basic modes of operation, read tests and write tests. The ''resourcetester'' tool provides convenience methods for common operations needed to perform those tests.

== Read Tests ==

To verify the read code in a resource works correctly we need to read pre-defined test data from the resource and compare that with independently provided reference data.

== Write Tests ==

Once the reading code is verified we can use that to verify the writing code. This is done by writing a change to the resource, re-creating it to ensure the change was persistent and finally comparing the re-read change with the expected result.

{{improve}}

[[Category:PIM]]

Development/Tools

2012-04-05T19:07:20Z

Mamarok: /* Quality Assurance */ updated continuous integration links

{{Template:I18n/Language Navigation Bar|Development/Tools}}
This section contains information about tools for KDE development.

== Core Tools ==
These are the tools that are absolutely required to build and develop KDE software. On Linux, they will typically be provided by your distribution. On other platforms, packages should normally be available, often for download directly from the home page for the tool. Of course, the standard development tools, such as a C/C++ compiler and some sort of text editor, are also required.

; CMake
: [[Development/CMake|CMake]] is KDE's build system of choice. Once you have this, you can use it to configure a software project for building, and that process will tell you of any other requirements you are missing.

; Git
: Most KDE projects are developed in [http://techbase.kde.org/Development/Git Git], and so you will need it to get the source code in the first place. You can find the relevant Git URLs at the [http://projects.kde.org/ KDE projects directory]. It will be helpful to follow the [[Development/Git/Configuration|git configuration instructions]].

; Subversion
: KDE still uses [[Getting Started/Sources/Subversion|Subversion]] for some things, notably translations.

== Debugging and Analysis ==
A list of tools which are used to analyze a program. This includes debuggers and profilers, for instance.

; Valgrind
: [[Development/Tools/Valgrind|Valgrind]] helps to find memory leaks and uninitialized memory blocks. Additional features are a profiler and more. Valgrind is one of the most important development tools!

; The GNU Project Debugger (GDB)
: [http://sources.redhat.com/gdb/ GDB] helps in debugging source code. As GDB evolved over time it is recommended to use version 6.x. Graphical frontends are available (see below). See also the debugging tutorial [[../Tutorials/Debugging/Debugging with GDB|Debugging with GDB]].

; KDbg and DDD
: [http://www.kdbg.org/ KDbg] and [http://www.gnu.org/software/ddd/ DDD] are graphical user interfaces to GDB, which are able to set breakpoints, step through the code etc.

; MS Windows tools (Process Explorer, Console, WinDbg, DebugView...)
: More info on the [[Projects/KDE_on_Windows/Tools|KDE on Windows page]].

== Development Tools ==
; Qt Creator
: With Qt Creator it is easy to write new KDE based programs and to integrate existing ones into an IDE. Further details can be found in the tutorial [[Development/Tutorials/Using_Qt_Creator|Using Qt Creator]].

; KDevelop
: [http://www.kdevelop.org KDevelop] is an IDE for developing KDE and Qt C++ applications. It includes a an integrated debugger, a powerful editor with syntax highlighting, a ''Project wizard'' to create applications from templates, the automake/autoconf gunk, and even the class documentation. Further details can also be found in the [http://kdevelop.org/mediawiki/index.php/Main_Page KDevelop wiki].

; MS Visual Studio® Express IDE (Windows only)
: [http://www.microsoft.com/exPress/ Visual C++® Express] is the free version of the Microsoft Visual Studio compiler from Microsoft, which is officially supported by Nokia. It is a choice for compiling Qt and KDE applications on Windows. [[Projects/KDE_on_Windows/Issues/MSVC|more info...]]

== Internationalization (i18n) Tools ==

; Lokalize
: [http://userbase.kde.org/Lokalize Lokalize] is a computer-aided translation system that focuses on productivity and quality assurance. It has components usual for CAT tools: translation memory, glossary, and also a unique translation merging (synchronization) capability. It is targeted for software translation and also integrates external conversion tools for freelance office document translation.

; Dr. Klash
: This little utility, once activated, can present a report about conflicting shortcuts in menus. Not only is this helpful for translators but also for developers. A little hand editing of {{path|`kde-config --localprefix`/share/config/kdeglobals}} activates this feature:

<syntaxhighlight lang="ini">
[Development]
CheckAccelerators=F12
AutoCheckAccelerators=false
AlwaysShowCheckAccelerators=false
</syntaxhighlight>

: Pressing F12 will show a dialog containing which accelerators in the currently focussed interface conflict and provide suggestions for new accelerators. If no accelerators conflict or Dr. Klash has nothing to suggest, no popup dialog will be displayed.

: With <tt>AutoCheckAccelerators</tt> enabled the dialog will popup automatically if a conflict exists and <tt>AlwaysShowCheckAccelerators</tt> can force the dialog to always popup even if there are no conflicts to report.

; The x-test language
: This helper language serves as a debugging aid for people finding untranslated strings in applications. If you start your application with the "x-test" locale, all translated strings will appear with trailing and leading xx's. First you have to check out these "translations" from l10n-kde4/x-test and install them.

: After you've built l10n-kde4/x-test and installed it, run your application using the "x-test" locale. This can be done by launching it from the command line like this:
<pre>
> KDE_LANG=x-test kspread
</pre>
: This will start KSpread using the "x-test" locale no matter what your current language setting is. Look for strings that do not have the xx's. If xx's are missing from a string, it could be due to missing i18n calls or even missing or incorrectly generated .pot files. Consult the i18n tutorials for further information.

: When checking for untranslated strings, be sure to check all the WhatsThis help and tooltips.

=== Examining .po files ===

You can look at the translated .po files to see if a string is present and has been translated. For example, here's a portion of {{path|l10n/de/messages/kdebase/konqueror.po}}:

<pre>
#: konq_mainwindow.cc:3707 konq_tabs.cc:84
msgid "&New Tab"
msgstr "Neues &Unterfenster"
</pre>

The string to be translated is given on the msgid line. The translated string is on the msgstr line. Notice that the exact same string to translate came from {{path|konq_mainwindow.cc}} and also from {{path|konq_tabs.cc}}. This saves the translators from having to translate the same identical string twice.

You can also use Lokalize to examine {{path|.po}} files. Lokalize is part of the kdesdk module.

{{note|More information on writing and translating documentation can be found on [http://l10n.kde.org/ the l10n project site].}}

== Helper Tools ==

;[[Development/Tools/Using kde-config|Get information about KDE's installation - kde-config]]
: The tool kde-config helps to find out more about a KDE installation.

;[[Development/Tools/Using kfmclient|Driving Konqueror From Scripts - kfmclient]]
: kfmclient is a small tool to communicate with Konqueror.

;[[Development/Tools/Using kconf_update|Updating User Configuration Files - kconf_update]]
: kconf_update is a tool designed to update config files.

;[[Development/Tools/apidox|Generating apidox]]
: tools that help develop and generate API documentation for your code.

;[[Development/Tools/Automoc4|Automoc4]]
: This is a helper tool needed to build KDE4. It automatically generates moc-files.

;[[Development/Tools/svnmerge.py|svnmerge.py]]
: This tool helps keeping track of merges between different SVN branches

== Quality Assurance ==

;Code Review
: KDE uses [http://www.reviewboard.org/ Review Board] for performing code reviews, see the [[Development/Review_Board|KDE Review Board]] page for more details

;Continuous Building - Jenkins
: [http://build.kde.org Jenkins]
: [http://public.kitware.com/dashboard.php?name=kde kdelibs on kitware]

;[http://englishbreakfastnetwork.org/ English Breakfast Network] - Static Analysis
: [http://www.englishbreakfastnetwork.org/krazy/ Krazy ] - Code Analysis, [[Development/Tutorials/Code_Checking|Usage Tutorial]]
: [http://www.englishbreakfastnetwork.org/apidocs/ APIDOX] - API Documentation Statistics
: [http://www.englishbreakfastnetwork.org/sanitizer/ Sanitizer] - DocBook Checker
: [http://www.englishbreakfastnetwork.org/usability/ Usability Checks]

Contribute

2012-04-05T16:47:37Z

Mamarok: /* Getting Involved in Bug Hunting and Application Quality */ added new section "User Interface", moved from Testing

<languages />
<translate>

{{Template:I18n/Language Navigation Bar|Contribute}}
This page intends to give an overview of the different aspects of KDE development in particular for programming related issues. ''The KDE project welcomes anyone willing to help''.


{{Note|There are a lot of ways to get involved in KDE development, which can be summed up in several categories:
:''Documentation, Translation, Development, Usability, Accessibility, Artwork, Promotion
''Not a coder? See KDE's pages on [http://kde.org/community/getinvolved/ how to get involved] to see other ways you can help. Also see: [[Contribute/Bugsquad|Bugsquad]]!''
}}

== News and Mail Sources == 


The general direction of the KDE project is determined by those who do the work - there is no single high level plan for what KDE will look like in the future.


If you want to find out what is currently happening, then there are a number of sources you might like to consider:
; [http://www.kde.org/mailinglists/ Mailing Lists]
: Probably the best way to find out what's going on in KDE development. Archives are available [http://lists.kde.org here]


; [http://commitfilter.kde.org/ CommitFilter]
: Receive notification of commits to the KDE source code repositories in areas that interest you.


; [http://commit-digest.org/ KDE Commit-Digest]
: Weekly summary of commits to projects in the KDE source code repositories.


; [http://dot.kde.org/ The Dot]
: The KDE news site.

== Reporting Bugs == 


The easiest way to contribute to KDE is to [http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs report any bugs] you find in KDE using the [https://bugs.kde.org/ KDE Bug Tracking System] (also known as '''Bugzilla''').


If the application you are using crashes then the '''Dr Konqi''' utility will appear and guide you through the process of reporting the crash. Learn more by reading [[Development/Tutorials/Debugging/How_to_create_useful_crash_reports|how to create useful crash reports]].

== Getting Started with Coding == 


Getting started at coding for KDE is a matter of finding something to fix, and fixing it. You may want to consult the module overview to help find what you are looking for; once you have fixed something, you will want to send in a patch. If you do that a few times, you may want to apply for a KDE Contributor account so you can improve things directly.


* [[Contribute/List of KDE Modules|Module overview]]
* [[Contribute/Send Patches|Sending patches]]
* [[Contribute/Get a Contributor Account|Applying for a KDE Contributor Account]]
* [[Contribute/First Steps with your KDE SVN Account|First steps with your new Contributor account]]

=== C++ === 


KDE is mostly written in C++. If you are not familiar with C++, you should do at least some work on it. There are a number of good books on C++ - an excellent source is [http://mindview.net/Books/TICPP/ThinkingInCPP2e.html Bruce Eckel's "Thinking in C++"], which is available both as a free download and as a printed document. It isn't essential to understand everything before you start in KDE, but you do need to understand basic syntax and operations.

=== Qt === 


To become proficient with KDE coding, you should understand the Qt toolkit. If you are not familiar with Qt, you should work through the tutorials included with [http://doc.qt.nokia.com/latest Qt Reference Documentation].


If you need a gentler introduction to Qt, or would just like an alternative view, then you may wish to look at the [http://qt4.digitalfanatics.org/tiqt/ The Independent Qt Tutorial] (Currently offline due to book contract).


If you prefer to learn Qt by reading a traditional book, take a look at the [http://qt.nokia.com/developer/books/ Books about Qt page]. More suggestions on becoming familiar with Qt4 are available [http://doc.qt.nokia.com/latest/how-to-learn-qt.html How to Learn Qt page].

=== KDE === 


A range of information on KDE techniques is available in the [[Development/Tutorials|tutorial section]]. Note that some of these tutorials still target KDE3, though they should be at least partly applicable.


You will also find useful information on KDE coding in the [[Development/FAQs|FAQs]] section. This information may also be somewhat dated for KDE4, however much of it is broadly applicable, even outside KDE.


You can also read [[Development/Further Information#Books|KDE coding books]].


Last, but by no means least, KDE comes with extensive class (Application Programmer Interface) documentation. This is available in the
[[Development/Tutorials/API Documentation|KDE API Reference Manuals]] section, which also contains a number of useful links on how to write or update the class documentation. You can also generate these on your own machine, or refer to a more up-to-date online version at [http://api.kde.org/ API Reference].


A more detailed description of the steps above is available in our [http://quality.kde.org/develop/howto/howtohack.php Programming Guide].

==== Context Help: Whatsthis ====

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: [http://bddf.ca/~aseigo/whatsthis_tutorial/ WhatsThis Tutorial], by Aaron J. Seigo.

== Getting Involved in Bug Hunting and Application Quality == 


There is a large number of applications within KDE, and not all of them have a maintainer dedicated to managing bugs and generally helping out with all the issues associated with turning some working code into a polished application.


If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the [http://quality.kde.org Quality Team website] for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called [http://community.kde.org/KDE/Junior_Jobs Junior Jobs] to encourage new contributions.


Of course, you can become involved in bug hunting without being part of the KDE Quality Team - just create yourself an account on the KDE [http://bugs.kde.org bug tracking system], and start searching / sorting through the bugs. Again, you don't have to have programming skills - it helps the programmers enormously just to have a procedure that allows a bug to be consistently reproduced.


The [[Contribute/Bugsquad|Bugsquad]] tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the KDE community if you cannot program.

== User Interface ==

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it.

The [http://mail.kde.org/mailman/listinfo/kde-usability KDE Usability Mailing List] is very active and a good place for discussing your ideas, and their homepage is at http://techbase.kde.org/Projects/Usability. If you are already an usability expert, please check [http://www.openusability.org/ OpenUsability.org], a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Some documents guiding documents include the [http://developer.kde.org/documentation/standards/kde/style/basics/index.html KDE User Interface Guidelines (design standards)] and [http://developer.kde.org/documentation/design/ui/index.html KDE User Interface Guidelines (design principles)].

Some projects for analysis of user interfaces may include: checking that shortcut keys are coherent across KDE applications, making sure that dialogs are directly relevant to the interaction that the user would expect, and finding users of KDE software to see how they perform common workflows.

==Getting Answers to Your Questions== 


If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:
<blockquote>
:* '''Read the Developer FAQ'''. Many common developer questions have been answered in the [[Development/FAQs|KDE Developer FAQ]]
:* '''Search/browse KDE websites'''. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the [http://techbase.kde.org KDE TechBase website]. And if possible, help edit it for clarity, and use the talk page if something is unclear.
:* '''Search mailing lists'''. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists either at [http://lists.kde.org/ lists.kde.org]. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
:* '''Search engines'''. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also [http://groups.google.com/ search] the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.


:* '''Read the source code'''. http://websvn.kde.org and https://projects.kde.org/ are available to help browse code. Read some commit logs and diffs for the code you might want to work with, It adds perspective.
:* '''Ask on KDE mailing lists'''. If you still do not have an answer, try asking your question on one of the KDE mailing lists listed above.
:* For questions relating to core development or third-party KDE development, unless you are particularly interested in [http://konqueror.kde.org/ Konqueror], [http://www.koffice.org/ KOffice], games or Java development, your main choice is [mailto:kde-devel@kde.org kde-devel] [mailto:kde-devel-request@kde.org?subject=subscribe (subscribe)].
:* For questions relating to Konqueror development, your main choice is [mailto:kfm-devel@kde.org kfm-devel] [mailto:kfm-devel@kde.org?subject=subscribe (subscribe)]
:* For questions relating to KOffice development, your main choice is [mailto:koffice-devel@kde.org koffice-devel] [mailto:koffice-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to games development, your main choice is [mailto:kde-games-devel@kde.org kde-games-devel] [mailto:kde-games-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to [http://qt.nokia.com/ Qt development], please use the fine [http://lists.trolltech.com/qt-interest/ Qt mailing list].
</blockquote>


A full list of KDE mailing lists is available [http://www.kde.org/mailinglists/ here] and [http://mail.kde.org/mailman/listinfo here].


[[Category:FAQs]]
</translate>

Contribute

2012-04-05T16:45:21Z

Mamarok: /* Context Help: Whatsthis */ correct level

<languages />
<translate>

{{Template:I18n/Language Navigation Bar|Contribute}}
This page intends to give an overview of the different aspects of KDE development in particular for programming related issues. ''The KDE project welcomes anyone willing to help''.


{{Note|There are a lot of ways to get involved in KDE development, which can be summed up in several categories:
:''Documentation, Translation, Development, Usability, Accessibility, Artwork, Promotion
''Not a coder? See KDE's pages on [http://kde.org/community/getinvolved/ how to get involved] to see other ways you can help. Also see: [[Contribute/Bugsquad|Bugsquad]]!''
}}

== News and Mail Sources == 


The general direction of the KDE project is determined by those who do the work - there is no single high level plan for what KDE will look like in the future.


If you want to find out what is currently happening, then there are a number of sources you might like to consider:
; [http://www.kde.org/mailinglists/ Mailing Lists]
: Probably the best way to find out what's going on in KDE development. Archives are available [http://lists.kde.org here]


; [http://commitfilter.kde.org/ CommitFilter]
: Receive notification of commits to the KDE source code repositories in areas that interest you.


; [http://commit-digest.org/ KDE Commit-Digest]
: Weekly summary of commits to projects in the KDE source code repositories.


; [http://dot.kde.org/ The Dot]
: The KDE news site.

== Reporting Bugs == 


The easiest way to contribute to KDE is to [http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs report any bugs] you find in KDE using the [https://bugs.kde.org/ KDE Bug Tracking System] (also known as '''Bugzilla''').


If the application you are using crashes then the '''Dr Konqi''' utility will appear and guide you through the process of reporting the crash. Learn more by reading [[Development/Tutorials/Debugging/How_to_create_useful_crash_reports|how to create useful crash reports]].

== Getting Started with Coding == 


Getting started at coding for KDE is a matter of finding something to fix, and fixing it. You may want to consult the module overview to help find what you are looking for; once you have fixed something, you will want to send in a patch. If you do that a few times, you may want to apply for a KDE Contributor account so you can improve things directly.


* [[Contribute/List of KDE Modules|Module overview]]
* [[Contribute/Send Patches|Sending patches]]
* [[Contribute/Get a Contributor Account|Applying for a KDE Contributor Account]]
* [[Contribute/First Steps with your KDE SVN Account|First steps with your new Contributor account]]

=== C++ === 


KDE is mostly written in C++. If you are not familiar with C++, you should do at least some work on it. There are a number of good books on C++ - an excellent source is [http://mindview.net/Books/TICPP/ThinkingInCPP2e.html Bruce Eckel's "Thinking in C++"], which is available both as a free download and as a printed document. It isn't essential to understand everything before you start in KDE, but you do need to understand basic syntax and operations.

=== Qt === 


To become proficient with KDE coding, you should understand the Qt toolkit. If you are not familiar with Qt, you should work through the tutorials included with [http://doc.qt.nokia.com/latest Qt Reference Documentation].


If you need a gentler introduction to Qt, or would just like an alternative view, then you may wish to look at the [http://qt4.digitalfanatics.org/tiqt/ The Independent Qt Tutorial] (Currently offline due to book contract).


If you prefer to learn Qt by reading a traditional book, take a look at the [http://qt.nokia.com/developer/books/ Books about Qt page]. More suggestions on becoming familiar with Qt4 are available [http://doc.qt.nokia.com/latest/how-to-learn-qt.html How to Learn Qt page].

=== KDE === 


A range of information on KDE techniques is available in the [[Development/Tutorials|tutorial section]]. Note that some of these tutorials still target KDE3, though they should be at least partly applicable.


You will also find useful information on KDE coding in the [[Development/FAQs|FAQs]] section. This information may also be somewhat dated for KDE4, however much of it is broadly applicable, even outside KDE.


You can also read [[Development/Further Information#Books|KDE coding books]].


Last, but by no means least, KDE comes with extensive class (Application Programmer Interface) documentation. This is available in the
[[Development/Tutorials/API Documentation|KDE API Reference Manuals]] section, which also contains a number of useful links on how to write or update the class documentation. You can also generate these on your own machine, or refer to a more up-to-date online version at [http://api.kde.org/ API Reference].


A more detailed description of the steps above is available in our [http://quality.kde.org/develop/howto/howtohack.php Programming Guide].

==== Context Help: Whatsthis ====

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: [http://bddf.ca/~aseigo/whatsthis_tutorial/ WhatsThis Tutorial], by Aaron J. Seigo.

== Getting Involved in Bug Hunting and Application Quality == 


There is a large number of applications within KDE, and not all of them have a maintainer dedicated to managing bugs and generally helping out with all the issues associated with turning some working code into a polished application.


If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the [http://quality.kde.org Quality Team website] for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called [http://community.kde.org/KDE/Junior_Jobs Junior Jobs] to encourage new contributions.


Of course, you can become involved in bug hunting without being part of the KDE Quality Team - just create yourself an account on the KDE [http://bugs.kde.org bug tracking system], and start searching / sorting through the bugs. Again, you don't have to have programming skills - it helps the programmers enormously just to have a procedure that allows a bug to be consistently reproduced.


The [[Contribute/Bugsquad|Bugsquad]] tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the KDE community if you cannot program.

==Getting Answers to Your Questions== 


If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:
<blockquote>
:* '''Read the Developer FAQ'''. Many common developer questions have been answered in the [[Development/FAQs|KDE Developer FAQ]]
:* '''Search/browse KDE websites'''. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the [http://techbase.kde.org KDE TechBase website]. And if possible, help edit it for clarity, and use the talk page if something is unclear.
:* '''Search mailing lists'''. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists either at [http://lists.kde.org/ lists.kde.org]. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
:* '''Search engines'''. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also [http://groups.google.com/ search] the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.


:* '''Read the source code'''. http://websvn.kde.org and https://projects.kde.org/ are available to help browse code. Read some commit logs and diffs for the code you might want to work with, It adds perspective.
:* '''Ask on KDE mailing lists'''. If you still do not have an answer, try asking your question on one of the KDE mailing lists listed above.
:* For questions relating to core development or third-party KDE development, unless you are particularly interested in [http://konqueror.kde.org/ Konqueror], [http://www.koffice.org/ KOffice], games or Java development, your main choice is [mailto:kde-devel@kde.org kde-devel] [mailto:kde-devel-request@kde.org?subject=subscribe (subscribe)].
:* For questions relating to Konqueror development, your main choice is [mailto:kfm-devel@kde.org kfm-devel] [mailto:kfm-devel@kde.org?subject=subscribe (subscribe)]
:* For questions relating to KOffice development, your main choice is [mailto:koffice-devel@kde.org koffice-devel] [mailto:koffice-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to games development, your main choice is [mailto:kde-games-devel@kde.org kde-games-devel] [mailto:kde-games-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to [http://qt.nokia.com/ Qt development], please use the fine [http://lists.trolltech.com/qt-interest/ Qt mailing list].
</blockquote>


A full list of KDE mailing lists is available [http://www.kde.org/mailinglists/ here] and [http://mail.kde.org/mailman/listinfo here].


[[Category:FAQs]]
</translate>

Contribute

2012-04-05T16:44:33Z

Mamarok: moved section here

<languages />
<translate>

{{Template:I18n/Language Navigation Bar|Contribute}}
This page intends to give an overview of the different aspects of KDE development in particular for programming related issues. ''The KDE project welcomes anyone willing to help''.


{{Note|There are a lot of ways to get involved in KDE development, which can be summed up in several categories:
:''Documentation, Translation, Development, Usability, Accessibility, Artwork, Promotion
''Not a coder? See KDE's pages on [http://kde.org/community/getinvolved/ how to get involved] to see other ways you can help. Also see: [[Contribute/Bugsquad|Bugsquad]]!''
}}

== News and Mail Sources == 


The general direction of the KDE project is determined by those who do the work - there is no single high level plan for what KDE will look like in the future.


If you want to find out what is currently happening, then there are a number of sources you might like to consider:
; [http://www.kde.org/mailinglists/ Mailing Lists]
: Probably the best way to find out what's going on in KDE development. Archives are available [http://lists.kde.org here]


; [http://commitfilter.kde.org/ CommitFilter]
: Receive notification of commits to the KDE source code repositories in areas that interest you.


; [http://commit-digest.org/ KDE Commit-Digest]
: Weekly summary of commits to projects in the KDE source code repositories.


; [http://dot.kde.org/ The Dot]
: The KDE news site.

== Reporting Bugs == 


The easiest way to contribute to KDE is to [http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs report any bugs] you find in KDE using the [https://bugs.kde.org/ KDE Bug Tracking System] (also known as '''Bugzilla''').


If the application you are using crashes then the '''Dr Konqi''' utility will appear and guide you through the process of reporting the crash. Learn more by reading [[Development/Tutorials/Debugging/How_to_create_useful_crash_reports|how to create useful crash reports]].

== Getting Started with Coding == 


Getting started at coding for KDE is a matter of finding something to fix, and fixing it. You may want to consult the module overview to help find what you are looking for; once you have fixed something, you will want to send in a patch. If you do that a few times, you may want to apply for a KDE Contributor account so you can improve things directly.


* [[Contribute/List of KDE Modules|Module overview]]
* [[Contribute/Send Patches|Sending patches]]
* [[Contribute/Get a Contributor Account|Applying for a KDE Contributor Account]]
* [[Contribute/First Steps with your KDE SVN Account|First steps with your new Contributor account]]

=== C++ === 


KDE is mostly written in C++. If you are not familiar with C++, you should do at least some work on it. There are a number of good books on C++ - an excellent source is [http://mindview.net/Books/TICPP/ThinkingInCPP2e.html Bruce Eckel's "Thinking in C++"], which is available both as a free download and as a printed document. It isn't essential to understand everything before you start in KDE, but you do need to understand basic syntax and operations.

=== Qt === 


To become proficient with KDE coding, you should understand the Qt toolkit. If you are not familiar with Qt, you should work through the tutorials included with [http://doc.qt.nokia.com/latest Qt Reference Documentation].


If you need a gentler introduction to Qt, or would just like an alternative view, then you may wish to look at the [http://qt4.digitalfanatics.org/tiqt/ The Independent Qt Tutorial] (Currently offline due to book contract).


If you prefer to learn Qt by reading a traditional book, take a look at the [http://qt.nokia.com/developer/books/ Books about Qt page]. More suggestions on becoming familiar with Qt4 are available [http://doc.qt.nokia.com/latest/how-to-learn-qt.html How to Learn Qt page].

=== KDE === 


A range of information on KDE techniques is available in the [[Development/Tutorials|tutorial section]]. Note that some of these tutorials still target KDE3, though they should be at least partly applicable.


You will also find useful information on KDE coding in the [[Development/FAQs|FAQs]] section. This information may also be somewhat dated for KDE4, however much of it is broadly applicable, even outside KDE.


You can also read [[Development/Further Information#Books|KDE coding books]].


Last, but by no means least, KDE comes with extensive class (Application Programmer Interface) documentation. This is available in the
[[Development/Tutorials/API Documentation|KDE API Reference Manuals]] section, which also contains a number of useful links on how to write or update the class documentation. You can also generate these on your own machine, or refer to a more up-to-date online version at [http://api.kde.org/ API Reference].


A more detailed description of the steps above is available in our [http://quality.kde.org/develop/howto/howtohack.php Programming Guide].

=== Context Help: Whatsthis ===

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: [http://bddf.ca/~aseigo/whatsthis_tutorial/ WhatsThis Tutorial], by Aaron J. Seigo.

== Getting Involved in Bug Hunting and Application Quality == 


There is a large number of applications within KDE, and not all of them have a maintainer dedicated to managing bugs and generally helping out with all the issues associated with turning some working code into a polished application.


If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the [http://quality.kde.org Quality Team website] for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called [http://community.kde.org/KDE/Junior_Jobs Junior Jobs] to encourage new contributions.


Of course, you can become involved in bug hunting without being part of the KDE Quality Team - just create yourself an account on the KDE [http://bugs.kde.org bug tracking system], and start searching / sorting through the bugs. Again, you don't have to have programming skills - it helps the programmers enormously just to have a procedure that allows a bug to be consistently reproduced.


The [[Contribute/Bugsquad|Bugsquad]] tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the KDE community if you cannot program.

==Getting Answers to Your Questions== 


If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:
<blockquote>
:* '''Read the Developer FAQ'''. Many common developer questions have been answered in the [[Development/FAQs|KDE Developer FAQ]]
:* '''Search/browse KDE websites'''. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the [http://techbase.kde.org KDE TechBase website]. And if possible, help edit it for clarity, and use the talk page if something is unclear.
:* '''Search mailing lists'''. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists either at [http://lists.kde.org/ lists.kde.org]. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
:* '''Search engines'''. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also [http://groups.google.com/ search] the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.


:* '''Read the source code'''. http://websvn.kde.org and https://projects.kde.org/ are available to help browse code. Read some commit logs and diffs for the code you might want to work with, It adds perspective.
:* '''Ask on KDE mailing lists'''. If you still do not have an answer, try asking your question on one of the KDE mailing lists listed above.
:* For questions relating to core development or third-party KDE development, unless you are particularly interested in [http://konqueror.kde.org/ Konqueror], [http://www.koffice.org/ KOffice], games or Java development, your main choice is [mailto:kde-devel@kde.org kde-devel] [mailto:kde-devel-request@kde.org?subject=subscribe (subscribe)].
:* For questions relating to Konqueror development, your main choice is [mailto:kfm-devel@kde.org kfm-devel] [mailto:kfm-devel@kde.org?subject=subscribe (subscribe)]
:* For questions relating to KOffice development, your main choice is [mailto:koffice-devel@kde.org koffice-devel] [mailto:koffice-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to games development, your main choice is [mailto:kde-games-devel@kde.org kde-games-devel] [mailto:kde-games-devel-request@kde.org?subject=subscribe (subscribe)]
:* For questions relating to [http://qt.nokia.com/ Qt development], please use the fine [http://lists.trolltech.com/qt-interest/ Qt mailing list].
</blockquote>


A full list of KDE mailing lists is available [http://www.kde.org/mailinglists/ here] and [http://mail.kde.org/mailman/listinfo here].


[[Category:FAQs]]
</translate>

Contribute/Bugsquad/Guide To BugTriaging

2011-11-24T15:53:50Z

Mamarok: /* Check the report quality (and ask for missing information) */ added Git for the revisions

Initial version by [[User:DarioAndres|Dario Andres]] (2010-03/2010-04).

Initial corrections by Lydia Pintscher (Nightrose)

===Disclaimer===

This "ultimate" guide is based on my own experience (approximately 2 years) on the KDE bug tracker.

I hope it works for you too :)

=General Considerations=

* '''Be polite''': when you need to request information or feedback be clear and polite, and you will get more information in less time.  Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the others position while describing your own.

* Don't try to do too many things at the same time; otherwise you will end up with a headache.

If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick Introduction to Bugzilla]

You may want to properly setup your bugzilla account as mentioned at [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla#Configure_your_account_.28Important.29 Configure your account]

=About getting permissions to work in the bug tracker=

Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.

If you want to work in the bug tracker you need to prove that you know what you are doing.

Initially you will ask for support on '''#kde-bugs''' (on IRC) and add comments in the bug report (so other people will see and check them, perform the needed actions, and evaluate your work)

{{Note|Adding comments in a bug report is allowed for every user}}

=Getting Started: Find what to work on (Different Approaches)=

You could use different techniques or approaches to triage the reports according to your current mood or the amount of work you want to do for example.

{{Tip|The two following techniques are complementary.}}

==Check all the bug reports of the day==

In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).

You can focus on crash, normal or wish reports individually (recommended) or all of them together.

'''Good:'''
* You get a complete view of all the reports
* You can easily recognize possible duplicates if the report titles are appropriate
* You can choose any report
* You can quickly clean the bugs that were filed recently (keeping them from rotting)
* You can get quick feedback from the reporter

'''Not so Good:'''
* You don't focus on one product
* You may not pay too much attention to every report, as you are triaging different kinds of reports
* You need a lot of attention to handle the different reports (at the ~same~ time)

This technique could be used ''every week'' (or every day)

===Bugzilla Links===
* All the bugs ('''any type''') reported [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=1d&chfieldto=Now&bug_file_loc=&cmdtype=doit today] or the [https://bugs.kde.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&bugidtype=include&chfield=%5BBug+creation%5D&chfieldfrom=7d&chfieldto=Now&bug_file_loc=&cmdtype=doit last week]
* All the '''crashes''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All the '''normal bugs''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]
* All the '''feature requests''' reported [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= today] or the [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=7d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= last week]

==Check bug reports of a single product over a period of time==

Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beggining (like 2000)). You can also choose which kind of reports you want to handle.

This technique is useful to audit old bugs or perform a deep clean (in case that the bugs weren't triaged on a daily basis previously).

'''Good:'''
* You focus only on one product / topic, so you don't need to pay too much attention (pay attention anyways!)

'''Not so Good:'''
* The reports of the other application may rot if they aren't checked
* You may not get feedback if the report is too old or the reporter is not accessible anymore

You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).

This technique could be used ''two times a month''.

===Bugzilla Links===

* Template search for all the reports of any status, since 2008: [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= any kind of report], [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=crash&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= crashes], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= normal bugs], [https://bugs.kde.org/query.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=wishlist&bugidtype=include&chfield=%5BBug%20creation%5D&chfieldfrom=2008-01-01&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_severity&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=crash&value0-0-0=&votes= feature requests]
* Template search for all the open reports, since 2008: [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= any kind of report], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= crashes], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= normal bugs], [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=plasma&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=wishlist&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2008-01-01&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= feature requests]

=Workflow of the bug triaging activity=

Now that you have a list of bug reports, pick one and start working.

[[File:DarioAndres_GuideToBugTriaging_Workflow.png]]

=Handling reports: What to do with a bug report=

There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful peace of information for the developers to check.

{{Note|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask to the developers or related contributors}}

As KDE has too much users, we get a lot of reports about bugs which are already reported (the so named "duplicates"). Before putting any effort in the current report we should check for the main report.

==Identifying duplicates==

There are a lot of ways of identifying duplicate reports depending of the kind of bug.

===General===

* Search for duplicates should be done initially against the same product of the bug report you are triaging:  If you don't find any related issue, you may need to search in a different product.
 
{{Tip|You can search on different products at the same time}}

{{Note|Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be being tracked at a library product (example, a bug in Plasma Desktop may be a bug in kdelibs, and therefore being tracked in the "kdelibs" product)}}

[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies List of related KDE technologies]

* You may want to filter out the results by date: you can select a date range since some years (or months ago) to "Now" (today)

===For "normal" (non-crash) reports===

# Pick some "keywords" from the current report. This keywords need to explain the inner concept of the bug that was reported (they must represent it).
# Perform a full search over the same product (read general note), initially on the "general" component.  Initially, put the keywords in the title, and perform the search (this will only look for the keywords in the title)
# If your search has results on it, check them all, reading the whole description and trying to identify the situation.
# If you don't get any results, you need to go back and: 
#* Change your keywords (tip: select thesaurus, or similar/related concepts); or
#* Use the keywords in the "Comments" field (so the search will look up in the bug description and comments too)

{{Note|When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"}}

{{Note|It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person (but we have time)}}

===For "crash" reports===

# Perform the same operation as with normal bug reports
# Check for reports with duplicate backtraces:   (Read the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#C.2B.2B_Backtraces_.28identifying_crashes_duplicates.29 Backtraces section] below)

Perform a full search over the same product (read general note), initially on the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")

===Processing search results===

* If you don't find any similar report then we should assume the new bug reports is "unique" (and valid). See next section 

* If you find a similar bug report we have too choices:
** If you are completely sure it is the same issue, you have to mark the report as duplicate.   The bug report you initially picked (name it "copy") is going to be marked as duplicate of the original report (name it "main"). If "copy" has additional information that "main" doesn't have, you may want to add it. (Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase) 
** If you aren't completely sure: you need someone else to double check your work. You may want to add a comment in the current report. Then, you should ask in #kde-bugs IRC channel for someone to look at your comment.
Comment template:
This bug looks related to bug XXXXXX
(XXXXXX being the bug ID of "master")

{{Note|You may found related reports that are already marked as duplicate of a third report. Always try to use this third report as the "main" one (resolve the duplicates chain). However, in some cases, the "main" reports refers to a root issue, and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.}}

==Identifying duplicates (crashes) : C++ Backtraces==

===Definition===

A backtrace is a piece of information that describes what was the application doing when it encountered the error and had to close itself. It is a “function stack” leading to the “crashing point”.

In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.

The backtrace is read from top to bottom. The first line shows ''where'' the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issues). The other lines show the “way to the first function”.

===Example===

Application: Plasma Workspace (kdeinit4), signal: Bus error
[KCrash Handler]
#5 0x00007fb563bb8f02 in KPixmapCache::Private::mmapFile (this=0x92df60,
filename=..., info=0x92dfb0, newsize=33656832) at /usr/src/debug/kdelibs-
4.4.1/kdeui/util/kpixmapcache.cpp:491
#6 0x00007fb563be3c34 in KPixmapCache::Private::mmapFiles (this=0x92df60) at
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:419
#7 0x00007fb563be38e3 in KPixmapCache::Private::init (this=0x92df60) at
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1061
#8 0x00007fb563be576d in KPixmapCache::discard (this=0x1203ca0) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1279
#9 0x00007fb563be5e48 in KPixmapCache::deleteCache (name=...) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1255
#10 0x00007fb55afdc97d in Plasma::ThemePrivate::discardCache (this=0x7a7d30)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:224
#11 0x00007fb55afe009b in Plasma::ThemePrivate::setThemeName (this=0x7a7d30,
tempThemeName=<value optimized out>, writeSettings=<value optimized out>)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:380
#12 0x00007fb55afe19fb in Plasma::Theme::settingsChanged (this=0x70af20) at
/usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:341
#13 0x00007fb55afe2918 in Plasma::ThemePrivate::settingsFileChanged
(this=0x7a7d30, file=<value optimized out>) at /usr/src/debug/kdelibs-
4.4.1/plasma/theme.cpp:335
...

===Description of a backtrace line===

#NumberInTheStack MemoryAddress in Namespace::Class:FunctionMember
(argumentThis=pointerValue, argument1=value, argument2=value, ...) at path/to
/source/code/file.cpp:linenumber

* #NumberInTheStack: is the order number in the function stack. The lesser, the nearer to the crash point. The smaller number may not be zero
* MemoryAddress: we don't put attention to this one.. Ignore
* Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could be also a class name if "Class" is an embedded one.
* Class: C++ class name of the function
* FunctionMember: C++ function name
* argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example "this=0x91ec5f8"  other argument use the same form "parameterName=parameterValue"
* (..): arguments supplied to the function. This information may not be available if *debug information* is not present  
* path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function, and the line number. The path is the one found at '''build time'''. This information may not be useful if '''debug information''' is not available (in that case, the name of the library or application binary may be included. Example: ''/home/kde-devel/kde/lib/libsopranoclient.so.1'')

'''Example''':

#13 0xb759d5d7 in Nepomuk::ResourceData::determineUri (this=0x91ec5f8) at
/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp:671

* The function is the number 13 in the stack
* Function's namespace: "Nepomuk"
* Function's class: "ResourceData"
* Function's function: "determineUri"
* The object "Nepomuk::ResourceData" which called to "determineUri" has the pointer "0x91ec5f8"
* The function is described (where it was build) at "/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp". It leads to the next function in the stack at the line number 671

===Identifying the first (useful) backtrace functions===

The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi)

If the application only had one thread, then it is at the top of the unique thread; otherwise you may need to look at all the thread (the KCrash mark may not be always in the Thread number 1)

Once that you located the "crashing thread start", pickup the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below)

This pairs will be used as "keywords" for the duplicate search

{{Note|This is only a general rule. There are some special cases when the first three function at the top may be the same but the crash may be different (specially on complex application/libraries as Konqueror)}}

If the first backtrace functions aren't available (they are not there, or there are "??") then we can't proceed without [[#Check_the_report_quality_.28and_ask_for_missing_information.29|asking for more information]] (a more complete backtrace).

===Avoiding useless function calls===

Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). This kind of functions should not be used for search as they are not representative of the crash itself and it may return lots of results.

'''Classes and functions to ignore in a backtrace''':
* Kernel/GLibC functions (<tt>__kernel_vsyscall</tt>, <tt>raise</tt>, <tt>abort</tt>)
* Functions from core/base libraries (libraries with filenames like <tt>libpthread.so.0</tt>, <tt>libc.so</tt>, <tt>libstdc++.so</tt>, <tt>libglib-2.0.so</tt>; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
* Qt containers classes (<tt>QMap</tt>, <tt>QList</tt>, <tt>QLinkedList</tt>, <tt>QVector</tt>, <tt>QStack</tt>, <tt>QQueue</tt>, <tt>QSet</tt>, <tt>QMap</tt>, <tt>QMultiMap</tt>, <tt>QHash</tt>, <tt>QMultiHash</tt>)
* Qt deep core classes (<tt>QApplication</tt>, <tt>QCoreApplication</tt>, <tt>QBasicAtomicInt</tt>, <tt>QBasicAtomicPointer</tt>, <tt>QAtomicInt</tt>, <tt>QAtomicPointer</tt>, <tt>QMetaObject</tt>, <tt>QPointer</tt>, <tt>QWeakPointer</tt>, <tt>QSharedPointer</tt>, <tt>QScopedPointer</tt>, <tt>QMetaCallEvent</tt>)
* Qt misc functions (<tt>qt_message_output</tt>, <tt>qt_message</tt>, <tt>qGetPtrHelper</tt>, functions starting with <tt>qt_meta_</tt>)

===Special cases (Advanced)===

There are special crashes related to the X11 graphics server. To identify this crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.

The important things to identify those crashes is recognizing the functions *below* the XIOError call (this is, which functions caused the X11 error).

In most of this crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).

==Bugs caused by external issues (UPSTREAM/DOWNSTREAM)==

Check if the bug is caused by an external plugin/add-on or distribution issue

There are several bugs which may be caused by external add-ons. If you are sure this is the case, you should dismiss the report, telling the reporter to file a new bug in a different place.

* Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)

Distributions can also bring some trouble, specially with packaging.

Some problems that may cause bugs are:
* different versions among KDE packages (kdelibs at one version, kdebase at a different one)
* missing plugins (broken packaging) causing crashes or missing features.

Also, distribution can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize this unofficial add-ons.

If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot; other people may identify if it is a KDE application or an external addition.

{{Note|The '''UPSTREAM''' resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11).
The '''DOWNSTREAM''' resolution refers to bug caused by the Distributions (broken packaging, ...) or by external plugins (unofficial Plasma widgets, other extensions, ...)}}

==Check the report quality (and ask for missing information)==

Now that you know that the bug report is unique, and that is not an external issue, you need to check all the needed information is there.

* Check that report is English and that is easily understandable.  
** If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
**   If the explanation is not clear enough, and you think that the bug could be described in a image, you may want to ask for a screenshot [explanation of Bugzilla attachments]

* If the bug is a graphical glitch or issue, you may want to request a screenshot [explanation of Bugzilla attachments]
* If the issue involves any other component (like the graphics card or drivers) you may need to ask for the versions and component's names
* If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug package symbols, reproduce the bug and generate a new backtrace. Template for this request:

If you can reproduce the crash at will (or you experience this regularly),
can you install the "PACKAGENAME" package and post a complete backtrace here?
(you can get more information at http://techbase.kde.org/User:DarioAndres
/Basic_Guide_about_Crash_Reporting ) Thanks

The names of the missing packages depends of the application and the distribution (as package naming scheme changes..). Look at List of debug package names on several Distributions

'''Useful information which could be also missing''':
* Application version
* KDE Platform (and/or Software Compilation) version
* If the bug is about a crash, request the version of the Qt library
* If the reporter is using an development version, request the Git or SVN revision of the KDE platform and application

{{Note|If you don't get feedback after a period of time, you can mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}

==Setting Bugzilla fields (and re-assignation)==

Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):

* '''Version''': if the report has a application version, you probably want to set the version in the Bugzilla field
* '''Priority''': we don't use this field in the KDE bug tracker
* '''Severity''': if the bug is important, critical or it causes data loss if should be set to "major" or "critical". If it is about a crash or a freeze it should be set to "crash". If it is any other kind of bug, it should be set to "normal". If it is a feature request (not a regression) it should be set to "wish".
** If you are not really sure if a report describes a real bug or a feature; or if you cannot diagnose the issue, you need to ask in the support channels or wait for other triagers or developers to check the report.
* '''Platform''': this field is only important if the bug is related to one distribution or specific system. (most of the bug reports are common to most of the platforms). Same with the OS field

===Renaming a report: Updating the summary===

Most of the times, the reporter user initially sets the bug report's title, and therefore, the summary doesn't really represent the bug itself. You may want to update the title to contain enough information to identify the issue properly.

A good title may contain:

* A brief explanation of the root cause (if it was found)
* Some of the symptoms people are experiencing
* Additional comments between round brackets/parentheses

{{Tip|Try to use complete and easily readable english sentences as summary}}

* If the bug is about a crash, you may add the first useful ClassName::FunctionName pairs that identify it. You can put them inside square brackets at the end of the title

* If the report has additional information (like a testcase file, or an attached proposed patch) you may add those references as tags at the start of the summary (inside square brackets)

'''Examples''':

[patch] Plasma clock draws garbage when hovering it if the Ctrl key is pressed

Dolphin hangs when trying to view the properties of a big file

[testcase file] Plasma crashes when adding a special file to the panel
[Class1::Function1, Class1::Function2, Class2::Function3]

Applications that use Plasma themes crash when compositing is switched on/off
due an error in KPixmapCache [KPixmapCache::Private::mmapFile,
KPixmapCache::Private::init, KPixmapCache::discard]

[testcase url] Konqueror shows a graphical artifact in webpage's form when
scrolling

===Reassigning bug reports===

Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know to which application/library did the bug belong to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)

{{Warning|Only perform re-assignations if you are sure the bug is in the wrong product.}}

{{Note|Remember to check the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies KDE related technologies list]}}

# Select the correct Bugzilla product.
# If you are sure the current assignee is the default of the current product, you need to click the checkbox to reset the assignee (so the assignee of the new(and correct) Bugzilla product will get notified)
# Commit the changes
# In the next page, select the correct Component and Version, and save the changes

==Adding related people to the CC list==

Sometimes, the reports describe general issues or are filed against common bugzilla products (like "kde" or "kdelibs"); or, on the other round, are filed against specific products (but the underling bug root cause is at some specific library, not directly related to the current bugzilla product assignee)

In both cases, if we don't need/want to reassign the report (because we aren't really sure about it), we can add the assignee of the other related products, or other developers mail address, to the CC list of the bug report.
That means, this person (or people following a mailing list) will get notified about this bug report, and they might look at it.

To know whom to add to the CC list you can:
* Look at the [https://bugs.kde.org/editproducts.cgi list of bugzilla products and components] and find the current default assignee (this requires special "editcomponents" permissions)
* Look at copyright of the source code related to the bug. (You can always access the code using [http://websvn.kde.org/trunk/KDE/ WebSVN])
* Ask in the IRC support channels which person is related to an specific KDE area (#kde-devel)

Common situation '''examples''':

* A report against "Dolphin" describes a Nepomuk-related error.
** Add the Nepomuk default assignee to the CC list

* A report against "Plasma" describes an error which seems to be more general (at kdelibs level), but you are not really sure if you should reassign it.
** Do not reassign and add "kdelibs-bugs___at___kde___dot___org" to the CC list

* A report against the "kde" bugzilla product describes a Konqueror-related issue (and you aren't sure it is a Konqueror-only issue)
** Do not reassign and add "konq-bugs___at___kde___dot___org" to the CC list

* A report against the "kde" bugzilla product describes a Plasma issue
** Reassign the report to the "plasma" bugzilla product; or
** Add "plasma-bugs___at___kde___dot___org" to the CC list

==Other Situations and Cases==

===One report per issue===

There is a policy in KDE bugtracker which establishes that different issues/bugs should not be mixed up in the same bug report, in order to keep the database clean and easy to read.

If any user adds information which is unrelated to the current bug report, gently tell him/her to write it down on a *different/new report. (The new issue described may be already reported somewhere else. In that case, you need to write a reference to the that bug report ID)

=Trying to reproduce the bugs=

An important step of bug triaging is trying to reproduce the bugs, this means, using the information the reporters added to the bug report to force(recreate, reproduce, repeat) the bug in the application.

This is needed in order to differentiate random/race condition bugs of reproducible ones (which may be reproduced by developers too; and they can fix them)

{{Warning|Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or sightly modified) environment. I recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).}}

You may want to use this reference text to setup your testing environment: [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]

{{Note|It is also important to have an updated KDE SC installation to test bugs.}}

==How to test bug reproducibility==

# Read the *complete* bug report (including all the attached information). Note that some bits of information may look unrelated; but they could be useful (or not)
# Use the information in the first comment (the original bug description) to try to reproduce the bug in the application.
# If you can reproduce the bug, then go to the next step
#* If you can't reproduce the bug, use the next comment in the report (which may add new information) to try to reproduce.
#* If you can't reproduce with all the comments in a separate way, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one) and similar combinations. You often have to use your imagination a bit (hopefully we still have time). Hopefully, you may find a combination that may reproduce the bug all (or most of) the times. Write down the "recipe" (steps to reproduce it), you need to include that data into the report later.
# Now that we have a result, we need to add our information/conclusions to the bug report

{{Tip|When trying to reproduce a bug, and if there are more than one piece of information, at first glance, try to identify a *common situation*. (some data or context that is present in all (or most of) the cases). This kind of data may be the key to find out how to reproduce.}}

==Adding new information (and requesting feedback)==

* In any case, add your KDE SC version and system information. (other kind of configuration data may be useful to: "did you tested it on a clean environment or in your existing configuration ?" "do you have library X installed and updated ?" "is your system 32 or 64 bits ?")

'''If you could reproduce the bug''':

* If you had to combine several steps to make your own "recipe" to reproduce, write it down. This kind of information should be useful for the developers.

* If you had to use custom input data (text, or a file); you may want to attach it to the bug report (of course, if it is not attached already)

A template of a comment for this situation could be:

I can reproduce the bug here using KDE SC x.y.z, Qt a.b.c on Distribution,
Kernel d.e.f on XX bits.
In order to reproduce I have to perform the following actions:
1- Action 1
2- Action 2
3- Action 3
4- Bug Appears
Note that you need to have the X configuration set to Y, and use the Z library
- Can anyone else confirm this ?
Thanks

'''If you could not reproduce the bug''':

* Write down which kind of steps you performed to try to get the bug.

* You may want to ask to all the reporters if your step had missing something, or if they notice any other strange (or not-default) situation or configuration which may be related.

* Also, if the report is a bit old (more than two major KDE SC releases old), you could try to ask the reporters if you can reproduce the bug in the latest stable KDE SC release or trunk (development version). The bug may be fixed already (but no one wrote it down into the bug report)

A template of comment for this situation could be:

I couldn't reproduce the bug here using KDE SC x.y.z, Qt a.b.c
on Distribution, Kernel d.e.f on XX bits.
I tried performing this actions:
1- Action 1
2- Action 2
or
1a- Action 1a
2a- Action 2a
However the bug didn't appear/the application didn't crash
- Are you all using library X and this kind of configuration ?
- Can you still reproduce this bug with an updated KDE SC version ?
Thanks

Hopefully you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as WORKSFORME (or FIXED)

=Getting bug triaging support=

During your work you may need help on how to proceed, you can use this resources to get help:

* The '''#kde-bugs channel''' on IRC (Freenode.net). You can ask to the whole channel.
* The BugSquad mailing list <bugsquad ##at## kde ##dot## org>

=BugWeeks=

We are planing to host bug triaging events (where new "students" can learn the tricks) named "BugWeeks" on a regular basis to help cleaning up the KDE bug tracker database.

The BugWeeks initiative is based on the Klassroom initiative in the KDE Community Forums

You can find more information about this at:
* [http://forum.kde.org/viewtopic.php?f=4&t=84473 BugWeeks announcement]
* [http://forum.kde.org/viewforum.php?f=148 BugWeeks subsection on KDE Community Forums]
* [http://forum.kde.org/viewtopic.php?f=148&t=84713 BugWeek 0 - Plasma Desktop bugs] ([http://forum.kde.org/viewtopic.php?f=148&t=84888 Summary])

=FAQ=
=More Information=

==List of related KDE technologies==

* Every KDE application use kdelibs [Bugzilla product: '''"kdelibs"''']
* Applications using the standard KDE file operations use KIO [Bugzilla product: '''"kio"'''] and probably KFile (for the UI part) [Bugzilla product: '''"kfile"''']
* Oxygen widget style (default) [Bugzilla product: '''"oxygen"''' component '''"style"'''] (I'm adding the component because "Oxygen" also refers to a Plasma and icon themes)
* Multimedia usage: Phonon library [Bugzilla product: '''"Phonon"''']
* PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: '''"kdepim"''', '''"kdepimlibs"''', '''"Akonadi"''', '''"kresources"''']
* Applications using KHTML [Bugzilla product: '''konqueror"''']
* Applications using OpenDesktop services uses Attica [Bugzilla product: '''"attica"''']
* Screen management related operations use the Kephal subsystem [Bugzilla product: '''"kephal"''']
* Games use libkdegames [Bugzilla product: '''"libkdegames"''']
* Scanning related applications probably use the KSane lib [Bugzilla product: '''"libksane"''']
* Multimedia applications reading audio tags use taglib [Bugzilla product: '''"taglib"''']
* Hardware related functions use Solid classes [Bugzilla product: '''"solid"''']
* Power Management functions use PowerDevil [Bugzilla product: '''"solid"''', component: '''"powerdevil-daemon"''']

==Special products and cases==

* "systemsettings" contain bug reports of the Shell application SystemSettings and kcmshell4, and reports of the configuration modules "kcm_*"
** Try to identificate if the report is about the shell applications (and set the component to "general", "treeview" or "kcmshell") or about some of the configuration modules (and set the component to "kcm_*name*")

* Konqueror can use different engines, like KHTML or WebKit
** If the report is about a webkit-only issue, reassign to product "kdelibs", component "kdewebkit"

{{Tip|When updating the bugzilla product or component, do not forget to reset to the default assignee}}

==Useful Links==

* [http://techbase.kde.org/Contribute/Bugsquad BugSquad page on Techbase]
* [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick introduction to Bugzilla]
* [https://darioandreskde.wordpress.com/ Dario_Andres blog about bug triaging]
* [https://bugs.kde.org/page.cgi?id=fields.html A Bug's Life Cycle]
* [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]
* [http://techbase.kde.org/Contribute/Bugsquad/How_to_create_useful_crash_reports How to create useful crash reports]
* [http://techbase.kde.org/User:DarioAndres/Basic_Guide_about_Crash_Reporting Basic guide about crash reports]
* [http://aseigo.blogspot.com/2009/01/bugskdeorg.html aseigo's suggestions for bugs.kde.org]

==Debug package names for several distributions==

For every KDE application it is recommended to install the debug information for "kdelibs" and "qt4"

{| class="wikitable" style="border:1px solid #AAA; padding:2px"
|-
! Package
! Ubuntu/Debian
! OpenSuse
! Fedora
! Mandriva
|-
| ''kdelibs''
| kdelibs5-dbg
| kdelibs4-debuginfo
| kdelibs-debuginfo
| kdelibs4-debug
|-
| ''qt''
| libqt4-dbg
| libqt4-debuginfo
| qt-debuginfo
| qt4-debug
|-
| ''kdebase (KDE base applications)''
| kdebase-dbg, kdebase-runtime-dbg, kdebase-workspace-dbg
| kdebase4-debuginfo, kdebase4-runtime-debuginfo, kdebase4-workspace-debuginfo
| kdebase-debuginfo, kdebase-runtime-debuginfo, kdebase-workspace-debuginfo
| kdebase4-debug, kdebase4-runtime-debug, kdebase4-workspace-debug
|-
| ''General example for every KDE "MODULE"''
| kdeMODULE-dbg
| kdeMODULE4-debuginfo
| kdeMODULE-debuginfo
| kdeMODULE4-debug
|-
| ''Phonon (multimedia subsystem)''
| phonon-dbg
| libphonon4-debuginfo / phonon4-debuginfo
| phonon-debuginfo
| phonon-debug
|}

For a detailed list of distributions naming scheme examples you can look at [http://techbase.kde.org/index.php?title=User:DarioAndres/CreateUsefulReports#How_to_obtain_debug_package_for_several_distributions How to obtain debug packages for every distribution].

==Glossary==

* Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet, or to a set of steps.

Contribute/Bugsquad/Guide

2011-10-19T20:17:50Z

Mamarok: /* External links */ Correct broken link to a more recent HowTo

== Introduction ==
Around 80 new bugs and wishlist items are filed in [http://bugs.kde.org/ KDE's bug tracking system] every day, and, while application and library maintainers try to look at all of the ones reported for their application, their job is a lot easier if someone else has already gone through and removed the duplicates, asked the reporter for any additional information that's useful, and noted which bugs can be reproduced.

The really nice thing about bug triage is that it comes in very small, bite-sized chunks: each bug report takes a few minutes to look through, so you can spend ten minutes a day on bug triage, and be able to do something useful - something that isn't so practical with some other ways of helping KDE.

The first thing to do is decide which bugs to concentrate on: do you want to look just the bugs for one or two applications, or take an overview of all bugs that are reported? If you're a long term KDE user, and are a little bit familiar with the internals, then taking an overview might be for you: you'll be able to see when bugs are filed against the wrong KDE component, and suggest what other parts of KDE could be relevant to the bug. If you're not familiar with the internals of KDE, you can still do bug triage! Just pick an application you use a lot, or particularly like, and concentrate on the bugs that are reported for that application.

Let's say you decide to concentrate on bugs in one particular app. You can use the [http://bugs.kde.org/query.cgi query page] to display all the open bugs for that application, or just the bugs that have been opened in the last few days. Take a look at each bug, with the aim of determining whether or not the behavior that the reporter described is really a bug, and if so, making it easier for the developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to start fixing the bug?

===Some things to do===

First, '''try to reproduce the behavior''' that the reporter has
described. Add a comment to say whether you could reproduce the bug,
noting your KDE version and distribution. If you don't understand the
description, ask for clarification - if you can't understand what the
reporter means, the developer probably won't be able to either.

''If you can reproduce the behavior, think of ways to <b>narrow down
the cause</b>'': Imagine that an app crashes when you save a document. What
about selecting Save from the File menu? What about pressing Ctrl+S?
Does it happen for any document, or just certain documents (perhaps
certain file formats)? What about local vs remote files? This is where
you get to use your imagination a little bit, since every bug report is
different.

Try to find out whether the bug is related to a problem with
''config files'': trying to reproduce the bug with a newly created user
(and asking the reporter to do the same) is a good way to test
this.

Those are some common, simple things that I can think of. As you get
more experienced, you'll find other tips n' tricks that are useful,
especially if you choose to concentrate on just one application.

==20-second summary==
===Bug triage===

'''Why is it useful?''' It makes bug hunting and fixing easier for
developers, so more bugs get fixed.

'''Why choose bug triage instead of ...?''' It doesn't take much time
to look over a bug, so it comes in nice small chunks

'''What skills do I need to do it?''' Not much, just a bit of
patience and sometimes some perseverance.
===Useful links===
*[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging Guide to Bug Triaging]

Projects/Mobile/Pre Devdays Sprint Munich 2010

2010-09-20T16:56:03Z

Mamarok: /* Attendees */

== The Sprint ==

'''Location:''' The Nokia offices in Munich

'''Time:''' 8th to 10th of October (for the sprint), followed by 11th to 13th (for Developer Days) - note that we will be getting hostel space from mid day on the 8th and until mid day on the 14th.

'''Topic:''' OVI in KDE and KDE in OVI

Nokia has offered sprint space for 12 people at their Munich office, and access to Qt Developer Days Munich 2010 for the participants in that sprint.

=== Attendees ===

To '''sign up''', please email [mailto:admin@leinir.dk Dan/Leinir] with your full name, your irc nick (if you've got one), and your travel cost estimate. Please supply this estimate in euros. Also please include a short introduction to yourself if you don't know me personally - i must confess to not know everybody ;) --[[User:Leinir|Leinir]] 15:58, 19 September 2010 (UTC)

NOTE: We are now FULL UP for the sprint. Please consider still joining the training :)

* Dan Leinir Turthra Jensen (leinir)
* Arjen Hiemstra (ahiemstra)
* Jonathan Schmidt-Dominé (The_User)
* Dinesh (irc nick here!)
* Krzysztof Głowiński (govi/govik)
* Chani Armitage (Chani)
* Sivan Greenberg (sivang)
* Mark Kretschmann (markey)
* Myriam Schweingruber (Mamarok)
* Rune Jensen (dimse)
* Shantanu Tushar (Shaan7)
* Sascha Peilicke (saschpe)
* Frank Karlitschek (karli)

* Arriving late on the 9th: Pradeepto Bhattacharya (pradeepto)

=== Discussion points ===

Please enter points you have which you would like to take up at the sprint here:

* KDE applications in OVI Store
* OVI Maps in Marble
* OVI Contacts in Akonadi
* KDE applications in MeeGo
* ownCloud in MeeGo and OVI (OVI Files was shut down, ownCloud to the rescue?)

== Training ==
In addition to Developer Days itself, they have offered a good deal more tickets to community members (50 in total for Munich!) who wish to attend the training sessions:

* Qt Essentials
* Qt Quick
* Qt Mobile Development for Nokia Devices

=== Attendees ===
Signup for this is separate to the sprint itself, and we cannot offer accommodation to those attending only the training. But, this is a really big deal still! [http://qt.nokia.com/qtdevdays2010/training The website] has the information you need to decide.

So, '''sign up''' the same way as for the sprint - send [mailto:admin@leinir.dk Dan/Leinir] an email with your name and irc nick, and which module you would like to take part in.

* Dan Leinir Turthra Jensen (leinir) - Qt Quick
* Sivan Greenberg (sivang) - Qt Quick
* Arjen Hiemstra (ahiemstra) - Qt Quick
* Krzysztof Głowiński (govi/govik) - Qt Essentials
* Achim Bohnet (allee/alleehol) - Qt Quick
* Pradeepto Bhattacharya (pradeepto) - Qt Quick
* Mark Kretschmann (markey) - Qt Quick
* Myriam Schweingruber (Mamarok) - Qt Essentials

Getting Started/Sources/Amarok Git Tutorial

2010-06-25T15:37:28Z

Mamarok: /* Patch Contributions */ fixed typo

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://git.kde.org/amarok/amarok

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributions ==

This is still a work in progress, as we work on getting ReviewBoard set up. In the meantime, hold on to any patches, or email them to amarok-devel@kde.org -- just be sure to follow the thread to ensure that it doesn't get lost :-)

If you want to use a local clone for working on bug fixes or features, do the following:

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git://git.kde.org/amarok/amarok

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

=== Account Setup ===

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

=== Setup Amarok Clone ===

Once you have a KDE development SSH account, a basic local clone for development work that allows push access can be created by running:

git clone git@git.kde.org:amarok/amarok

This will place a clone in the "amarok" subdirectory of the current folder.

If for some reason port 22 will not work for you (such as if you behind a firewall allowing only ports 80 and 443 through) you can use port 443 on git.kde.org by specifying the port in ~/.ssh/config:

Host git.kde.org
Port 443

You can also create your own server-side clone of the Amarok repository and store your changes there. Others can then pull from your repository or add your repository as a remote.

Please note that personal clones are using KDE infrastructure and meant for KDE-relevant work, and as such you cannot change the access policy that allows everyone to read these clones (but you can change who can write to them, as explained below). Please do not create clones to e.g. make changes to customize code for your company. If you want to do this, host your clone on Gitorious.org or GitHub.com instead.

To create a personal clone, run the following command, substituting your KDE username and a reponame of your choice, *without* a trailing ".git":

ssh git@git.kde.org clone amarok/amarok amarok/users/[username]/[reponame]

After that, you will have a fully functioning repository of your own at git://git.kde.org/amarok/users/[username]/[reponame] or git@git.kde.org:amarok/users/[username]/[reponame] for read-only and push URLs, respectively.

You can delete this repository at any time by running the "destroy" command:

ssh git@git.kde.org destroy amarok/users/[username]/[reponame]

==== Rights Management ====

When your clone is created, it is setup to allow all KDE developers push access to it. This is in keeping with KDE's everyone-can-write-anywhere philosophy. You are strongly encouraged to keep this default.

However, we understand that at times you may want to ensure that the work you are doing is not modified by anyone else until you are finished, or reach a milestone, or some such thing.

As such, you can adjust who can write to your cloned repository.

To see the current permissions, use the "getperms" command:

ssh git@git.kde.org getperms amarok/users/mitchell/testrepo
RW = @all

@all is a special groupname that indicates all KDE developers. It is the only special name allowed in the permissions.

To modify them, create a file named anything you like -- I'll use "myperms". In "myperms" enter those that should have RW access by their KDE user account name. The RW statements are cumulative, or can specify multiple user accounts on one line:

RW = hein bcooskley
RW = toma

At the end of this, the total push permissions will be comprised of *you* (the creator of the clone, in my case "mitchell"), hein, bcooskley *and* toma. Note that *you* are the only one that can push and delete new branches and tags; the other contributors only have push access. In other words, you are your own release manager for your clone.

Now, use the "setperms" command to set the permissions, passing in the file you created:

ssh git@git.kde.org setperms amarok/users/mitchell/testrepo < myperms
New perms are:
RW = hein bcooksley
RW = toma

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://git.kde.org/amarok/users/mitchell/pudaction.git
git remote update
git branch -a
git branch jeff-pud jeff/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Getting Started/Sources/Amarok Git Tutorial

2010-06-19T01:42:36Z

Mamarok: /* Patch Contributors */ added marokes for update and a few changes

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://git.kde.org/amarok/amarok.git

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributors ==

You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.

'''NEEDS REVISION'''*Make sure you have created your SSH account on git.kde.org and are logged in. Go to the project you want to clone (e.g. Amarok - http://gi.kde.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).

'''NEEDS UPDATE'''*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
*Clone the push url to start working on your clone:

git clone git@gitorious.org:~yourname/amarok/yourname-clone.git

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*Publish it on gitorious:

git push origin my_feature_branch

*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right.

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git@gitorious.org:amarok/amarok.git

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

=== account setup ===

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

=== Setup Amarok Clone ===

The easiest thing to do is just use that:

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

If you already have an existing checkout form Gitorious times, simply edit the .git/config file and change "gitorious.org" to "git.kde.org" for the main repository (not any personal clones you may have in remotes).

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
git remote update
git branch -a
git branch jeff-pud pud-action/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

= Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Getting Started/Sources/Amarok Git Tutorial

2010-06-19T01:40:08Z

Mamarok: /* Follow and test the latest development code */ adapted to the latest repo

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://git.kde.org/amarok/amarok.git

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributors ==

You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.

*Make sure you have created your account on Gitorious and are logged in. Go to the project you want to clone (e.g. Amarok - http://gitorious.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).
*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
*Clone the push url to start working on your clone:

git clone git@gitorious.org:~yourname/amarok/yourname-clone.git

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*Publish it on gitorious:

git push origin my_feature_branch

*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right.

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git@gitorious.org:amarok/amarok.git

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

=== account setup ===

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

=== Setup Amarok Clone ===

The easiest thing to do is just use that:

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

If you already have an existing checkout form Gitorious times, simply edit the .git/config file and change "gitorious.org" to "git.kde.org" for the main repository (not any personal clones you may have in remotes).

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
git remote update
git branch -a
git branch jeff-pud pud-action/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

= Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Getting Started/Sources/Amarok Git Tutorial

2010-06-19T01:35:25Z

Mamarok: /* Setup Amarok Clone */ modified with the new git repo data

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://gitorious.org/amarok/amarok.git

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributors ==

You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.

*Make sure you have created your account on Gitorious and are logged in. Go to the project you want to clone (e.g. Amarok - http://gitorious.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).
*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
*Clone the push url to start working on your clone:

git clone git@gitorious.org:~yourname/amarok/yourname-clone.git

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*Publish it on gitorious:

git push origin my_feature_branch

*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right.

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git@gitorious.org:amarok/amarok.git

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

=== account setup ===

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

=== Setup Amarok Clone ===

The easiest thing to do is just use that:

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

If you already have an existing checkout form Gitorious times, simply edit the .git/config file and change "gitorious.org" to "git.kde.org" for the main repository (not any personal clones you may have in remotes).

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
git remote update
git branch -a
git branch jeff-pud pud-action/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

= Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Getting Started/Sources/Amarok Git Tutorial

2010-06-19T01:32:20Z

Mamarok: /* account setup */

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://gitorious.org/amarok/amarok.git

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributors ==

You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.

*Make sure you have created your account on Gitorious and are logged in. Go to the project you want to clone (e.g. Amarok - http://gitorious.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).
*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
*Clone the push url to start working on your clone:

git clone git@gitorious.org:~yourname/amarok/yourname-clone.git

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*Publish it on gitorious:

git push origin my_feature_branch

*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right.

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git@gitorious.org:amarok/amarok.git

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

=== account setup ===

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

=== Setup Amarok Clone ===

Gitorious has one address for cloning, and another for pushing. The pushing address can be used for cloning, so the easy thing to do is just use that.

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
git remote update
git branch -a
git branch jeff-pud pud-action/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

= Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Getting Started/Sources/Amarok Git Tutorial

2010-06-19T01:32:00Z

Mamarok: /* account setup */ modified with the new git repositories

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://gitorious.org/amarok/amarok.git

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributors ==

You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.

*Make sure you have created your account on Gitorious and are logged in. Go to the project you want to clone (e.g. Amarok - http://gitorious.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).
*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
*Clone the push url to start working on your clone:

git clone git@gitorious.org:~yourname/amarok/yourname-clone.git

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*Publish it on gitorious:

git push origin my_feature_branch

*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right.

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git@gitorious.org:amarok/amarok.git

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

== account setup ==

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

=== Setup Amarok Clone ===

Gitorious has one address for cloning, and another for pushing. The pushing address can be used for cloning, so the easy thing to do is just use that.

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
git remote update
git branch -a
git branch jeff-pud pud-action/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

= Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Getting Started/Sources/Amarok Git Tutorial

2010-01-21T22:21:08Z

Mamarok: /* Patch Contributors */ minor clean-up

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>

= Crucial Step 0 =

''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion Found here]''.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

= Getting started with git =

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

== Follow and test the latest development code ==

git clone git://gitorious.org/amarok/amarok.git

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

== Patch Contributors ==

You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.

*Make sure you have created your account on Gitorious and are logged in. Go to the project you want to clone (e.g. Amarok - http://gitorious.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).
*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
*Clone the push url to start working on your clone:

git clone git@gitorious.org:~yourname/amarok/yourname-clone.git

*Create a branch for each new feature of bug fix you want to work on:

git branch my_feature_branch

*Switch to the new branch:

git checkout my_feature_branch

*Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

*Commit it to your local checkout:

git commit -a

*Publish it on gitorious:

git push origin my_feature_branch

*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right.

*You can follow the main development branch easily by adding it as remote branch:

git remote add upstream git@gitorious.org:amarok/amarok.git

*Update by pulling from the remote:

git pull --rebase upstream master

*Remember to use one branch per feature/bug fix!

== Amarok Developers ==

=== gitorious.org account setup ===

*Create an account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and now Amarok.
*On your user page, (that's at http://gitorious.org/~your_nick) click on "Manage SSH keys" and add your SSH key.

People with KDE-SVN accounts also should do the following:

*Again from the user page, click on "Manage aliases" and add any email addresses you've ever used in KDE SVN. This way any commits you've made in the past are tracked back to you. If your gitorious email address is the only one you ever used, then this step isn't needed.
*Request one of the kde-developers admins to add your username to the group (the same rules apply as KDE SVN account requests). This will give you push rights to Amarok. Lydia, Ian and Jeff are all admins.

=== Setup Amarok Clone ===

Gitorious has one address for cloning, and another for pushing. The pushing address can be used for cloning, so the easy thing to do is just use that.

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

=== Basic Development ===

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.

''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.

Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.

''git push'' pushes all the local commits to the central repo.

= Follow remote feature branch =
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
git remote update
git branch -a
git branch jeff-pud pud-action/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

''git checkout'' is how you switch between branches.

= Recommended reading =

*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''

= Todo for this doc =

*creating feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers

2009-11-19T11:36:32Z

Mamarok: /* Phonon bugs that need attention from developers */

===Phonon bugs that need attention from developers===
If anything is in doubt, put it here, and give a description of why you think a developer should look at it.

* {{bug|170971}} probably listing two different and unrelated issues.[[User:Mamarok|Mamarok]]
* {{Bug|180148}} I was able to reproduce until ~1 week ago. Not sure if it's still there. [[User:jacopods|wilder]]
* {{Bug|184584}} Weird: kmix / alsamixer does not affect phonon volume [[User:jacopods|wilder]]
* {{bug|189387}} Sound distortion with high resolution flac files, xine backend.[[User:Mamarok|Mamarok]]
* {{bug|198131}} I am almost sure it is a duplicate, but the user thinks it's not.[[User:Mamarok|Mamarok]]
* {{bug|191837}} kded_phononserver.so. Backtrace is not really good. Maybe already solved?.[[User:Mamarok|Mamarok]]
* {{Bug|198216}} The reporter has attached a patch. [[JontheEchidna]]
* {{Bug|198218}} The reporter has given a detailed technical description of the bug. [[JontheEchidna]]
* {{bug|202027}} Encoding problems in XineStream, potential patch.[[User:Mamarok|Mamarok]]
* {{bug|203115}} Video deinterlacing doesn't work with Xine backend, potential patch.[[User:Mamarok|Mamarok]]
**{{bug|206145}} optical output problems.[[User:Mamarok|Mamarok]]
**{{bug|207932}} might be a crash in Pulseaudio, not in Phonon.[[User:Mamarok|Mamarok]]
* {{Bug|212660}} Vlc is segfaulting. Is phonon passeing the proper data ? [[User:HelioCastro|heliocastro]]

Contribute/Bugsquad/BugDays/PhononDay

2009-11-17T19:42:48Z

Mamarok: /* Division of Labour */

==Introduction==
This bug day will take place on Sunday, November 8th 2009, but feel free to start early. The aim of this bug day is to clear as many Phonon-related bugs as possible. Our target for triage is bugs listed in [http://bugs.kde.org bugs.kde.org] under the product Phonon.

'''The goal of this bug-day is to check for: simple step-by-step instructions, reproducibility, and most of all, come up with test-cases for reproducing the bugs. This will enable the Phonon developers to deal with bugs more easily, and so have more time left to actually fix them.''' When you have added step-by-step instructions for the reproduction of a bug, please list it in the appropriate section below, so that a second triager can see if they can get your instructions/test-case to work correctly. [http://techbase.kde.org/index.php?title=Contribute/Bugsquad This page] has useful information on how to not mis-mark bugs. In particular, "duplicates are hard". and Phonon currently has a lot of duplicate reports. The other tricky thing is that you will need to test with various applications like Amarok or Dragonplayer, since many KDE applications use Phonon for sound. Please '''make sure''' to double check them with someone else, preferably one of the developers before marking/closing.'''We especially don't want to create more work for developers!'''

Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated. (You can even join now!)

You should be working with KDE 4 (either 4.3.2 or newer is best or SVN trunk) for testing these bugs. To test bugs noticed with Amarok, we strongly suggest aou have either Amarok 2.2.0 or 2.2-git

{{Warning|Always make a note on the bug of what the status is in the version you are testing with (be explicit as to what version of 4 you are using, mentioning whether it is a source build and which distro the packages come from).}}

===Unclear===
If something has no clear instructions on how to reproduce it, or has little useful information, add a comment asking the reporter for more detail. Then list it in the [[#Bugs_awaiting_feedback|bugs awaiting feedback]] section. Be polite, we want to be nice to our bug reporters!

===Is it a big bug?===
Prioritizing is good. If a major application doesn't work, this should be taken care of.

===Version field===
Keep an eye on what the "Version:" fields say in Bugzilla. If it says "unspecified", change the version field to match what the report says, i.e. to match version the bug was first reported in. <b>Do not change the version number if it is currently set as a number!</b> (ex. from 4.0 to 4.2)

===Double Check!===
'''Please list bugs here to get a second opinion before making the change in bugzilla. This also gives a record of what we've done for the developers to check.'''

===Keep this page updated!===
After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself on the CC field in bugzilla to be informed about updates. When a bug is closed on bugzilla, it should be updated on this page.

You can do this with the tag <s>...</s>

===Update bugzilla===
Add your comments even on bugzilla for a more complete feedback by users and developers.

==Details==

Please select a period of bugs from the [[#Division_of_Labour|Division of Labour]] section below and mark your name next to it and mark it with your irc nickname to show that you are working on it. When you have completed all the bugs in that section, please mark it as complete.

For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below. '''If you wish to close or mark as duplicate a bug, please list it here even if you have the bugzilla permissions to do so, in order to get a second opinion from another triager. This will help to reduce the number of incorrect actions taken on bugs.'''

==Sign-in==
Tell developers what you are testing with. (If you expect to upgrade between now and BugDay, put what version you are using now next to the bugs/comments that you put on this page.)

Please give distro/version or SVN branch/trunk with revision below:

{|
|-
!IRC Nickname !! KDE version used for testing
|-
|[[User:Mamarok|Mamarok]] || Kubuntu 9.10 with KDE 4.3.3, Amarok 2.2-git ||
|-
|[[User:Blauzahl|Blauzahl]] || ||
|-
|[[JontheEchidna]] || Kubuntu 10.04 with KDE 4.3.3, Amarok 2.2.0 ||
|-
|[[wilder]] || KDE 4.3.svn, Amarok 2.2-git, phonon svn trunk||
|-
|[[User:HelioCastro|HelioCastro]] || KDE 4 svn trunk, phonon svn trunk ||
|-
|[[User:Dtritscher|dtritscher]] || Kubuntu 9.10 with KDE 4.3.3, Amarok 2.2-git-neon ||
|}

{{Tip|Please be sure to sign every bug or comment you add to this page with your irc nickname. You can use the wiki markup <nowiki>~~~</nowiki> to insert your wiki username automatically (but only do this if it is the same as your IRC nickname, otherwise write your IRC nickname in by hand).}}

==Division of Labour==
Please choose a month that is not already taken and then query bugs.kde.org for all bugs in that month. Please mark you irc nickname in the table below to show which month's bugs you are working on to avoid duplication of effort.

The bugzilla query to use for this triage day can be [https://bugs.kde.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDSINFO&bug_status=VERIFIED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_severity&field-1-1-0=bug_status&field-1-2-0=product&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=Phonon&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=critical,grave,major,crash,normal,minor&value-1-1-0=UNCONFIRMED,NEW,ASSIGNED,REOPENED,NEEDSINFO,VERIFIED&value-1-2-0=Phonon&value0-0-0=&votes=&order=bugs.bug_id&query_based_on= found here].

{|
|-
!Month/Time period !! No of bugs !! IRC Nickname !! Status !! Query
|-
| -> 12-2008 || 7 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-01-01&chfieldto=2008-12-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|02-2009 || 7 || wilder || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-01-01&chfieldto=2009-02-28&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|03/04-2009 || 18 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-03-01&chfieldto=2009-04-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|05/06-2009 || 21 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-05-01&chfieldto=2009-06-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|07-2009 || 17 || JontheEchidna || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-07-01&chfieldto=2009-07-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|08-2009 || 15 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-08-01&chfieldto=2009-08-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|09-2009 || 24 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-09-01&chfieldto=2009-09-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|10-2009/1 || 17 || Mamarok || triaging || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-10-01&chfieldto=2009-10-15&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|10-2009/2 || 18 || || || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-10-16&chfieldto=2009-10-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|11-2009 || 26 || HelioCastro || triaging || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-11-01&chfieldto=2009-11-07&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|}
(Total bugs 180)

== Completed Bugs ==
Below lists the various sections for completed bugs. This aids everyone in double checking each other's work. In addition this allows those of us that don't have bugzilla permissions to list bugs so that the folks with the permissions can follow up.

Please note that this is an experimental layout designed to reduce the number of edit conflicts on this page. Each section is its own subpage. The best way to work with this is to enable section editing by going to "My preferences" > "editing" > "Enable section editing via [edit] links". When you click edit you will automatically edit the subpage.

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing Version Field changed}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs that are heisenbugs}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs tobe marked as RESOLVED}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as DUPLICATE}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as INVALID}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing users with particular setups}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs not related to today}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs that you cant do}}

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-17T19:41:37Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|174835}} Streams not playing in OS X.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
* {{bug|194902}} No dmix output with xine-backend.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|192378}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
** {{bug|195249}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|208772}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196320}} master bug: thread_mutex_lock.c in xine_close. Already a lot of dupes to it, so I choose this one..[[User:Mamarok|Mamarok]]
** {{bug|206713}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|205595}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212176}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212242}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]
* {{bug|205440}} Amarok skipps songs randomly, all backends.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs tobe marked as RESOLVED

2009-11-17T12:21:34Z

Mamarok: /* Bugs that are RESOLVED */

===Bugs that are RESOLVED===
If the bug doesn't exist anymore, it goes here. WORKSFORME!

* {{Bug|168143}} Obsolete version (KDE 4.1), feedback was asked months ago, no response. Most likely solved already.[[User:Mamarok|Mamarok]]
* {{bug|173163}} Should have been closed some time ago already.[[User:Mamarok|Mamarok]]
* {{bug|177723}} Report from KDE 4.1.x, Closed for lack of feedback (asked in August 2009).[[User:Mamarok|Mamarok]]
* {{Bug|180148}} Windows media stream works. Fixed in trunk.[[User:HelioCastro|heliocastro]]
* {{Bug|182420}} HAL is required to start before kde for mostly anything to work [[User:jacopods|wilder]]
* {{Bug|183506}} Works for me and the user as well. wilder
* {{Bug|183761}} XIO error, solved in the gstreamer codec.[[User:Mamarok|Mamarok]]
** {{bug|198258}} closed as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|186999}} Duplicate of {{bug|172550}}.[[User:Mamarok|Mamarok]]
* {{bug|184732}} Fixed in r1028879.[[User:Mamarok|Mamarok]]
* {{bug|189027}} Works for me with Dragonplayer, no Konqueror crash.[[User:Mamarok|Mamarok]]
* {{bug|191373}} Duplicate of {{bug|182847}}.[[User:Mamarok|Mamarok]]
* {{bug|195486}} Duplicate of {{bug|191366}}.[[User:Mamarok|Mamarok]]
* {{Bug|197905}} Xine lib handling issue. Fixed in trunk. [[User:HelioCastro|heliocastro]]
* {{bug|199708}} Works for me in two installs. [[User:HelioCastro|heliocastro]]
* {{Bug|202345}} Code is available in phonon trunk. Works in two different distros. [[User:HelioCastro|heliocastro]]
* {{Bug|202982}} Phonon Xine lib handling. Fixed in trunk.[[User:HelioCastro|heliocastro]]
* {{bug|205936}} Closed as invalid, lack of feedback.[[User:Mamarok|Mamarok]]
**{{bug|206087}} missing codecs.[[User:Mamarok|Mamarok]]
* {{Bug|206486}} Distro related. Upstream and 4.3.x works. [[User:HelioCastro|heliocastro]]
* {{bug|213664}} Duplicate of {{bug|195249}}.[[User:Mamarok|Mamarok]]
* {{bug|204112}} Can reproduce with Phonon 4.3.1, but upgrading to trunk makes things all better.
**{{bug|208587}} not reproducible by the reporter, should have been closed already.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-17T12:17:18Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|156215}} marked WAITINGFORINFO, might be solved in trunk.[[User:Mamarok|Mamarok]]
* {{bug|158515}} marked WAITINGFORINFO, can't reproduce this.[[User:Mamarok|Mamarok]]
* {{bug|164104}} marked WAITINGFORINFO, previous question needs answered
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* <s>{{bug|197927}}marked WAITINGFORINFO, unknown backend.</s> sent to invalid, feature request.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|201270}} marked WAITINGFORINFO, gstreamer backend, might have missing codecs.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
**{{bug|208222}} missing icon, needs feedback from Nuno.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers

2009-11-17T12:14:24Z

Mamarok: /* Phonon bugs that need attention from developers */

===Phonon bugs that need attention from developers===
If anything is in doubt, put it here, and give a description of why you think a developer should look at it.

* {{Bug|180148}} I was able to reproduce until ~1 week ago. Not sure if it's still there. [[User:jacopods|wilder]]
* {{Bug|184584}} Weird: kmix / alsamixer does not affect phonon volume [[User:jacopods|wilder]]
* {{bug|189387}} Sound distortion with high resolution flac files, xine backend.[[User:Mamarok|Mamarok]]
* {{bug|198131}} I am almost sure it is a duplicate, but the user thinks it's not.[[User:Mamarok|Mamarok]]
* {{bug|191837}} kded_phononserver.so. Backtrace is not really good. Maybe already solved?.[[User:Mamarok|Mamarok]]
* {{Bug|198216}} The reporter has attached a patch. [[JontheEchidna]]
* {{Bug|198218}} The reporter has given a detailed technical description of the bug. [[JontheEchidna]]
* {{bug|202027}} Encoding problems in XineStream, potential patch.[[User:Mamarok|Mamarok]]
* {{bug|203115}} Video deinterlacing doesn't work with Xine backend, potential patch.[[User:Mamarok|Mamarok]]
**{{bug|206145}} optical output problems.[[User:Mamarok|Mamarok]]
**{{bug|207932}} might be a crash in Pulseaudio, not in Phonon.[[User:Mamarok|Mamarok]]
* {{Bug|212660}} Vlc is segfaulting. Is phonon passeing the proper data ? [[User:HelioCastro|heliocastro]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs that are heisenbugs

2009-11-17T12:09:17Z

Mamarok: /* Valid Bugs that are non-deterministic: "Heisenbugs" */

===Valid Bugs that are non-deterministic: "Heisenbugs"===
If sometimes it happens, and sometimes it doesn't, or if it looks like it works for some people, but not for all, or is a bit random, it goes here. Don't worry too much about sorting this category bug from the "step-by-step/deterministic" bugs, but in general, the first category should be easier for a developer to go and fix.

* {{bug|195938}} Xine backend stuttering sound with Pulseaudio.[[User:Mamarok|Mamarok]]
** {{bug|206314}} is a potential duplicate: sound skipping with Pulseaudio.[[User:Mamarok|Mamarok]]
* {{bug|200606}} Plug&Play of external soundcards doesn't work in some cases.[[User:Mamarok|Mamarok]]
* {{bug|204958}} Cannot reproduce this here, but the reporter can.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers

2009-11-17T12:05:18Z

Mamarok: /* Phonon bugs that need attention from developers */

===Phonon bugs that need attention from developers===
If anything is in doubt, put it here, and give a description of why you think a developer should look at it.

* {{Bug|180148}} I was able to reproduce until ~1 week ago. Not sure if it's still there. [[User:jacopods|wilder]]
* {{Bug|184584}} Weird: kmix / alsamixer does not affect phonon volume [[User:jacopods|wilder]]
* {{bug|189387}} Sound distortion with high resolution flac files, xine backend.[[User:Mamarok|Mamarok]]
* {{bug|198131}} I am almost sure it is a duplicate, but the user thinks it's not.[[User:Mamarok|Mamarok]]
* {{bug|191837}} kded_phononserver.so. Backtrace is not really good. Maybe already solved?.[[User:Mamarok|Mamarok]]
* {{Bug|198216}} The reporter has attached a patch. [[JontheEchidna]]
* {{Bug|198218}} The reporter has given a detailed technical description of the bug. [[JontheEchidna]]
* {{bug|202027}} Encoding problems in XineStream, potential patch.[[User:Mamarok|Mamarok]]
* {{bug|203115}} Video deinterlacing doesn't work with Xine backend, potential patch.[[User:Mamarok|Mamarok]]
**{{bug|206145}} optical output problems.[[User:Mamarok|Mamarok]]
* {{Bug|212660}} Vlc is segfaulting. Is phonon passeing the proper data ? [[User:HelioCastro|heliocastro]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs tobe marked as RESOLVED

2009-11-17T12:03:32Z

Mamarok: /* Bugs that are RESOLVED */

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-17T11:58:56Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|174835}} Streams not playing in OS X.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
* {{bug|194902}} No dmix output with xine-backend.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|192378}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
**{{bug|195249}} marked as duplicate.[[User:Mamarok|Mamarok]]
**{{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196320}} master bug: thread_mutex_lock.c in xine_close. Already a lot of dupes to it, so I choose this one..[[User:Mamarok|Mamarok]]
** {{bug|206713}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|205595}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212176}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212242}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]
* {{bug|205440}} Amarok skipps songs randomly, all backends.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs that are heisenbugs

2009-11-17T11:49:43Z

Mamarok: /* Valid Bugs that are non-deterministic: "Heisenbugs" */

===Valid Bugs that are non-deterministic: "Heisenbugs"===
If sometimes it happens, and sometimes it doesn't, or if it looks like it works for some people, but not for all, or is a bit random, it goes here. Don't worry too much about sorting this category bug from the "step-by-step/deterministic" bugs, but in general, the first category should be easier for a developer to go and fix.

* {{bug|195938}} Xine backend stuttering sound with Pulseaudio.[[User:Mamarok|Mamarok]]
* {{bug|200606}} Plug&Play of external soundcards doesn't work in some cases.[[User:Mamarok|Mamarok]]
* {{bug|204958}} Cannot reproduce this here, but the reporter can.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs tobe marked as RESOLVED

2009-11-17T11:48:22Z

Mamarok: /* Bugs that are RESOLVED */

===Bugs that are RESOLVED===
If the bug doesn't exist anymore, it goes here. WORKSFORME!

* {{Bug|168143}} Obsolete version (KDE 4.1), feedback was asked months ago, no response. Most likely solved already.[[User:Mamarok|Mamarok]]
* {{bug|173163}} Should have been closed some time ago already.[[User:Mamarok|Mamarok]]
* {{bug|177723}} Report from KDE 4.1.x, Closed for lack of feedback (asked in August 2009).[[User:Mamarok|Mamarok]]
* {{Bug|180148}} Windows media stream works. Fixed in trunk.[[User:HelioCastro|heliocastro]]
* {{Bug|182420}} HAL is required to start before kde for mostly anything to work [[User:jacopods|wilder]]
* {{Bug|183506}} Works for me and the user as well. wilder
* {{Bug|183761}} XIO error, solved in the gstreamer codec.[[User:Mamarok|Mamarok]]
** {{bug|198258}} closed as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|186999}} Duplicate of {{bug|172550}}.[[User:Mamarok|Mamarok]]
* {{bug|184732}} Fixed in r1028879.[[User:Mamarok|Mamarok]]
* {{bug|189027}} Works for me with Dragonplayer, no Konqueror crash.[[User:Mamarok|Mamarok]]
* {{bug|191373}} Duplicate of {{bug|182847}}.[[User:Mamarok|Mamarok]]
* {{bug|195486}} Duplicate of {{bug|191366}}.[[User:Mamarok|Mamarok]]
* {{Bug|197905}} Xine lib handling issue. Fixed in trunk. [[User:HelioCastro|heliocastro]]
* {{bug|199708}} Works for me in two installs. [[User:HelioCastro|heliocastro]]
* {{Bug|202345}} Code is available in phonon trunk. Works in two different distros. [[User:HelioCastro|heliocastro]]
* {{Bug|202982}} Phonon Xine lib handling. Fixed in trunk.[[User:HelioCastro|heliocastro]]
* {{bug|205936}} Closed as invalid, lack of feedback.[[User:Mamarok|Mamarok]]
* {{Bug|206486}} Distro related. Upstream and 4.3.x works. [[User:HelioCastro|heliocastro]]
* {{bug|213664}} Duplicate of {{bug|195249}}.[[User:Mamarok|Mamarok]]
* {{bug|204112}} Can reproduce with Phonon 4.3.1, but upgrading to trunk makes things all better.

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-17T11:41:44Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|174835}} Streams not playing in OS X.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
* {{bug|194902}} No dmix output with xine-backend.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|195249}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
**{{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196320}} master bug: thread_mutex_lock.c in xine_close. Already a lot of dupes to it, so I choose this one..[[User:Mamarok|Mamarok]]
** {{bug|206713}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|205595}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212176}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212242}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]
* {{bug|205440}} Amarok skipps songs randomly, all backends.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-17T11:36:54Z

Mamarok: /* Bugs Awaiting Feedback */

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-17T11:32:45Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|174835}} Streams not playing in OS X.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
* {{bug|194902}} No dmix output with xine-backend.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|195249}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
**{{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]
* {{bug|196320}} master bug: thread_mutex_lock.c in xine_close. Already a lot of dupes to it, so I choose this one..[[User:Mamarok|Mamarok]]
** {{bug|206713}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|205595}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212176}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212242}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|}} marked as duplicate.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-17T11:29:58Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|174835}} Streams not playing in OS X.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|195249}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
**{{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]
* {{bug|196320}} master bug: thread_mutex_lock.c in xine_close. Already a lot of dupes to it, so I choose this one..[[User:Mamarok|Mamarok]]
** {{bug|206713}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|205595}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212176}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212242}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|}} marked as duplicate.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-17T11:27:56Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|156215}} marked WAITINGFORINFO, might be solved in trunk.[[User:Mamarok|Mamarok]]
* {{bug|158515}} marked WAITINGFORINFO, can't reproduce this.[[User:Mamarok|Mamarok]]
* {{bug|164104}} marked WAITINGFORINFO, previous question needs answered
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* <s>{{bug|197927}}marked WAITINGFORINFO, unknown backend.</s> sent to invalid, feature request.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-17T11:24:27Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|156215}} marked WAITINGFORINFO, might be solved in trunk.[[User:Mamarok|Mamarok]]
* {{bug|158515}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* <s>{{bug|197927}}marked WAITINGFORINFO, unknown backend.</s> sent to invalid, feature request.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as DUPLICATE

2009-11-11T16:23:16Z

Mamarok: /* Duplicate Bugs */

===Duplicate Bugs===
Put suspected duplicates here.

* {{bug|200692}} Looks like {{bug|202982}} (Phonon::Xine::XineStream::event) [[JontheEchidna]]
** could be a duplicate of {{bug|181327}}
* {{bug|191366}} duplicate of {{bug|181327}} ? [[User:Mamarok|Mamarok]]
* {{bug|204011}} duplicate of {{bug|193179}} ? [[User:Mamarok|Mamarok]]
* {{bug|207579}} duplicate of {{bug|206713}} (fedora master report) ? [[User:Blauzahl|Blauzahl]]
** is the master report a phonon thing? the bt looks like kio stuff. [[User:Blauzahl|Blauzahl]]
** Unlikely, 206713 is a duplicate of {{bug|196320}} which is a different crash. Unless we find an earlier one I guess 207579 is a standalone.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-11T09:15:20Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|158515}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* <s>{{bug|197927}}marked WAITINGFORINFO, unknown backend.</s> sent to invalid, feature request.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-11T09:14:45Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|195249}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
**{{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]
* {{bug|196320}} master bug: thread_mutex_lock.c in xine_close. Already a lot of dupes to it, so I choose this one..[[User:Mamarok|Mamarok]]
** {{bug|206713}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|205595}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212176}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|212242}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|}} marked as duplicate.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-11T09:10:34Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|158515}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* <s> {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)</s> duplicate of {{bug|196320}}.[[User:Mamarok|Mamarok]]
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* <s>{{bug|197927}}marked WAITINGFORINFO, unknown backend.</s> sent to invalid, feature request.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers

2009-11-10T18:11:26Z

Mamarok: /* Phonon bugs that need attention from developers */

===Phonon bugs that need attention from developers===
If anything is in doubt, put it here, and give a description of why you think a developer should look at it.

* {{Bug|180148}} I was able to reproduce until ~1 week ago. Not sure if it's still there. [[User:jacopods|wilder]]
* {{Bug|184584}} Weird: kmix / alsamixer does not affect phonon volume [[User:jacopods|wilder]]
* {{bug|189387}} Sound distortion with high resolution flac files, xine backend.[[User:Mamarok|Mamarok]]
* {{bug|198131}} I am almost sure it is a duplicate, but the user thinks it's not.[[User:Mamarok|Mamarok]]
* {{bug|191837}} kded_phononserver.so. Backtrace is not really good. Maybe already solved?.[[User:Mamarok|Mamarok]]
* {{Bug|198216}} The reporter has attached a patch. [[JontheEchidna]]
* {{Bug|198218}} The reporter has given a detailed technical description of the bug. [[JontheEchidna]]
* {{bug|202027}} Encoding problems in XineStream, potential patch.[[User:Mamarok|Mamarok]]
* {{bug|203115}} Video deinterlacing doesn't work with Xine backend, potential patch.[[User:Mamarok|Mamarok]]
* {{Bug|212660}} Vlc is segfaulting. Is phonon passeing the proper data ? [[User:HelioCastro|heliocastro]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-10T09:49:12Z

Mamarok: /* Valid bugs with step-by-step instructions */

===Valid bugs with step-by-step instructions===
If it is a deterministic bug, put it here. Make sure it has instructions. You should be able to verify it. (Write that you did on bugzilla and include your version information.)

* {{Bug|169380}} Very accurate report with testcase. This is for Vir [[User:jacopods|wilder]]
* {{bug|172394}} End of flac files sound clipped.[[User:Mamarok|Mamarok]]
** {{bug|178792}} marked as duplicate.[[User:Mamarok|Mamarok]]
** {{bug|197584}} might be a duplicate of it, too.[[User:Mamarok|Mamarok]]
* {{bug|172550}} Gstreamer backend stop-startover master bug.[[User:Mamarok|Mamarok]]
* {{bug|180214}} XineStream::creatStream master bug.[[User:Mamarok|Mamarok]]
** {{bug|183597}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|181327}} (XineStream::closeBlocking).[[User:Mamarok|Mamarok]]
* {{bug|187557}} Gstreamer::GstHelper.[[User:Mamarok|Mamarok]]
* {{bug|187661}} "Removed Sound Device" dialog not remembered.[[User:Mamarok|Mamarok]]
* {{bug|188444}} Gstreamer master bug: Playback device falling back to default.[[User:Mamarok|Mamarok]]
** {{bug|203879}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|190707}} Good analysis of the problem, looks like an easy fix at first sight.[[User:Mamarok|Mamarok]]
* {{bug|193179}} asound assert.[[User:Mamarok|Mamarok]]
** {{bug|203076}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|195249}} Backend changing crash master bug.[[User:Mamarok|Mamarok]]
**{{bug|213925}} marked as duplicate.[[User:Mamarok|Mamarok]]
* {{bug|196518}} Good description.[[User:Mamarok|Mamarok]]
* {{bug|199327}} MetaDataChanged() not emitted, Xine backend.[[User:Mamarok|Mamarok]]
* {{bug|201481}} Phonon::Gstreamer::MediaObject crash, Master bug for gstreamer crashes. [[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-09T15:45:53Z

Mamarok: /* Valid bugs with step-by-step instructions */

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-09T15:16:37Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|158515}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* <s>{{bug|197927}}marked WAITINGFORINFO, unknown backend.</s> sent to invalid, feature request.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as INVALID

2009-11-09T15:15:06Z

Mamarok: /* INVALID bugs */

===INVALID bugs===
A bug is INVALID if it describes desired behavior, or something that isn't a bug.

* {{bug|179288}} related to Shoutcast which changed their API conditions making it impossible for FOSS projects to use. Also, Shoutcast streams were totally unreliable, changing URL without notice.[[User:Mamarok|Mamarok]]
* {{bug|171955}} asks for Dolby surround, is a wish.[[User:Mamarok|Mamarok]]
* {{bug|189033}} Is a wish. Already assigned and worked on.[[User:Mamarok|Mamarok]]
* {{bug|197927}} Remote media not seakable with the xine backend. Feature request.[[User:Mamarok|Mamarok]]
* {{bug|204114}} Invalid bug. The issue is xine lib related. Can be confirmed using any direct xine output application. [[User:HelioCastro|heliocastro]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions

2009-11-09T10:17:16Z

Mamarok: /* Valid bugs with step-by-step instructions */

Contribute/Bugsquad/BugDays/PhononDay

2009-11-08T22:13:06Z

Mamarok: /* Division of Labour */

==Introduction==
This bug day will take place on Sunday, November 8th 2009, but feel free to start early. The aim of this bug day is to clear as many Phonon-related bugs as possible. Our target for triage is bugs listed in [http://bugs.kde.org bugs.kde.org] under the product Phonon.

'''The goal of this bug-day is to check for: simple step-by-step instructions, reproducibility, and most of all, come up with test-cases for reproducing the bugs. This will enable the Phonon developers to deal with bugs more easily, and so have more time left to actually fix them.''' When you have added step-by-step instructions for the reproduction of a bug, please list it in the appropriate section below, so that a second triager can see if they can get your instructions/test-case to work correctly. [http://techbase.kde.org/index.php?title=Contribute/Bugsquad This page] has useful information on how to not mis-mark bugs. In particular, "duplicates are hard". and Phonon currently has a lot of duplicate reports. The other tricky thing is that you will need to test with various applications like Amarok or Dragonplayer, since many KDE applications use Phonon for sound. Please '''make sure''' to double check them with someone else, preferably one of the developers before marking/closing.'''We especially don't want to create more work for developers!'''

Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated. (You can even join now!)

You should be working with KDE 4 (either 4.3.2 or newer is best or SVN trunk) for testing these bugs. To test bugs noticed with Amarok, we strongly suggest aou have either Amarok 2.2.0 or 2.2-git

{{Warning|Always make a note on the bug of what the status is in the version you are testing with (be explicit as to what version of 4 you are using, mentioning whether it is a source build and which distro the packages come from).}}

===Unclear===
If something has no clear instructions on how to reproduce it, or has little useful information, add a comment asking the reporter for more detail. Then list it in the [[#Bugs_awaiting_feedback|bugs awaiting feedback]] section. Be polite, we want to be nice to our bug reporters!

===Is it a big bug?===
Prioritizing is good. If a major application doesn't work, this should be taken care of.

===Version field===
Keep an eye on what the "Version:" fields say in Bugzilla. If it says "unspecified", change the version field to match what the report says, i.e. to match version the bug was first reported in. <b>Do not change the version number if it is currently set as a number!</b> (ex. from 4.0 to 4.2)

===Double Check!===
'''Please list bugs here to get a second opinion before making the change in bugzilla. This also gives a record of what we've done for the developers to check.'''

===Keep this page updated!===
After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself on the CC field in bugzilla to be informed about updates. When a bug is closed on bugzilla, it should be updated on this page.

You can do this with the tag <s>...</s>

===Update bugzilla===
Add your comments even on bugzilla for a more complete feedback by users and developers.

==Details==

Please select a period of bugs from the [[#Division_of_Labour|Division of Labour]] section below and mark your name next to it and mark it with your irc nickname to show that you are working on it. When you have completed all the bugs in that section, please mark it as complete.

For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below. '''If you wish to close or mark as duplicate a bug, please list it here even if you have the bugzilla permissions to do so, in order to get a second opinion from another triager. This will help to reduce the number of incorrect actions taken on bugs.'''

==Sign-in==
Tell developers what you are testing with. (If you expect to upgrade between now and BugDay, put what version you are using now next to the bugs/comments that you put on this page.)

Please give distro/version or SVN branch/trunk with revision below:

{|
|-
!IRC Nickname !! KDE version used for testing
|-
|[[User:Mamarok|Mamarok]] || Kubuntu 9.10 with KDE 4.3.3, Amarok 2.2-git ||
|-
|[[User:Blauzahl|Blauzahl]] || ||
|-
|[[JontheEchidna]] || Kubuntu 10.04 with KDE 4.3.3, Amarok 2.2.0 ||
|-
|[[wilder]] || KDE 4.3.svn, Amarok 2.2-git, phonon svn trunk||
|-
|[[User:HelioCastro|HelioCastro]] || KDE 4 svn trunk, phonon svn trunk ||
|-
|[[User:Dtritscher|dtritscher]] || Kubuntu 9.10 with KDE 4.3.3, Amarok 2.2-git-neon ||
|}

{{Tip|Please be sure to sign every bug or comment you add to this page with your irc nickname. You can use the wiki markup <nowiki>~~~</nowiki> to insert your wiki username automatically (but only do this if it is the same as your IRC nickname, otherwise write your IRC nickname in by hand).}}

==Division of Labour==
Please choose a month that is not already taken and then query bugs.kde.org for all bugs in that month. Please mark you irc nickname in the table below to show which month's bugs you are working on to avoid duplication of effort.

The bugzilla query to use for this triage day can be [https://bugs.kde.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDSINFO&bug_status=VERIFIED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_severity&field-1-1-0=bug_status&field-1-2-0=product&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=Phonon&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=critical,grave,major,crash,normal,minor&value-1-1-0=UNCONFIRMED,NEW,ASSIGNED,REOPENED,NEEDSINFO,VERIFIED&value-1-2-0=Phonon&value0-0-0=&votes=&order=bugs.bug_id&query_based_on= found here].

{|
|-
!Month/Time period !! No of bugs !! IRC Nickname !! Status !! Query
|-
| -> 12-2008 || 7 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-01-01&chfieldto=2008-12-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|02-2009 || 7 || wilder || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-01-01&chfieldto=2009-02-28&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|03/04-2009 || 18 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-03-01&chfieldto=2009-04-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|05/06-2009 || 21 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-05-01&chfieldto=2009-06-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|07-2009 || 17 || JontheEchidna || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-07-01&chfieldto=2009-07-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|08-2009 || 15 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-08-01&chfieldto=2009-08-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|09-2009 || 24 || Mamarok || triaging || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-09-01&chfieldto=2009-09-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|10-2009/1 || 17 || || || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-10-01&chfieldto=2009-10-15&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|10-2009/2 || 18 || || || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-10-16&chfieldto=2009-10-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|11-2009 || 26 || HelioCastro || triaging || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-11-01&chfieldto=2009-11-07&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|}
(Total bugs 180)

== Completed Bugs ==
Below lists the various sections for completed bugs. This aids everyone in double checking each other's work. In addition this allows those of us that don't have bugzilla permissions to list bugs so that the folks with the permissions can follow up.

Please note that this is an experimental layout designed to reduce the number of edit conflicts on this page. Each section is its own subpage. The best way to work with this is to enable section editing by going to "My preferences" > "editing" > "Enable section editing via [edit] links". When you click edit you will automatically edit the subpage.

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing Version Field changed}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs that are heisenbugs}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs tobe marked as RESOLVED}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as DUPLICATE}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as INVALID}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing users with particular setups}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs not related to today}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs that you cant do}}

Contribute/Bugsquad/BugDays/PhononDay

2009-11-08T22:11:03Z

Mamarok: /* Division of Labour */

==Introduction==
This bug day will take place on Sunday, November 8th 2009, but feel free to start early. The aim of this bug day is to clear as many Phonon-related bugs as possible. Our target for triage is bugs listed in [http://bugs.kde.org bugs.kde.org] under the product Phonon.

'''The goal of this bug-day is to check for: simple step-by-step instructions, reproducibility, and most of all, come up with test-cases for reproducing the bugs. This will enable the Phonon developers to deal with bugs more easily, and so have more time left to actually fix them.''' When you have added step-by-step instructions for the reproduction of a bug, please list it in the appropriate section below, so that a second triager can see if they can get your instructions/test-case to work correctly. [http://techbase.kde.org/index.php?title=Contribute/Bugsquad This page] has useful information on how to not mis-mark bugs. In particular, "duplicates are hard". and Phonon currently has a lot of duplicate reports. The other tricky thing is that you will need to test with various applications like Amarok or Dragonplayer, since many KDE applications use Phonon for sound. Please '''make sure''' to double check them with someone else, preferably one of the developers before marking/closing.'''We especially don't want to create more work for developers!'''

Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated. (You can even join now!)

You should be working with KDE 4 (either 4.3.2 or newer is best or SVN trunk) for testing these bugs. To test bugs noticed with Amarok, we strongly suggest aou have either Amarok 2.2.0 or 2.2-git

{{Warning|Always make a note on the bug of what the status is in the version you are testing with (be explicit as to what version of 4 you are using, mentioning whether it is a source build and which distro the packages come from).}}

===Unclear===
If something has no clear instructions on how to reproduce it, or has little useful information, add a comment asking the reporter for more detail. Then list it in the [[#Bugs_awaiting_feedback|bugs awaiting feedback]] section. Be polite, we want to be nice to our bug reporters!

===Is it a big bug?===
Prioritizing is good. If a major application doesn't work, this should be taken care of.

===Version field===
Keep an eye on what the "Version:" fields say in Bugzilla. If it says "unspecified", change the version field to match what the report says, i.e. to match version the bug was first reported in. <b>Do not change the version number if it is currently set as a number!</b> (ex. from 4.0 to 4.2)

===Double Check!===
'''Please list bugs here to get a second opinion before making the change in bugzilla. This also gives a record of what we've done for the developers to check.'''

===Keep this page updated!===
After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself on the CC field in bugzilla to be informed about updates. When a bug is closed on bugzilla, it should be updated on this page.

You can do this with the tag <s>...</s>

===Update bugzilla===
Add your comments even on bugzilla for a more complete feedback by users and developers.

==Details==

Please select a period of bugs from the [[#Division_of_Labour|Division of Labour]] section below and mark your name next to it and mark it with your irc nickname to show that you are working on it. When you have completed all the bugs in that section, please mark it as complete.

For each bug, try and reproduce it as described in the report. Then list it in the appropriate section below. '''If you wish to close or mark as duplicate a bug, please list it here even if you have the bugzilla permissions to do so, in order to get a second opinion from another triager. This will help to reduce the number of incorrect actions taken on bugs.'''

==Sign-in==
Tell developers what you are testing with. (If you expect to upgrade between now and BugDay, put what version you are using now next to the bugs/comments that you put on this page.)

Please give distro/version or SVN branch/trunk with revision below:

{|
|-
!IRC Nickname !! KDE version used for testing
|-
|[[User:Mamarok|Mamarok]] || Kubuntu 9.10 with KDE 4.3.3, Amarok 2.2-git ||
|-
|[[User:Blauzahl|Blauzahl]] || ||
|-
|[[JontheEchidna]] || Kubuntu 10.04 with KDE 4.3.3, Amarok 2.2.0 ||
|-
|[[wilder]] || KDE 4.3.svn, Amarok 2.2-git, phonon svn trunk||
|-
|[[User:HelioCastro|HelioCastro]] || KDE 4 svn trunk, phonon svn trunk ||
|-
|[[User:Dtritscher|dtritscher]] || Kubuntu 9.10 with KDE 4.3.3, Amarok 2.2-git-neon ||
|}

{{Tip|Please be sure to sign every bug or comment you add to this page with your irc nickname. You can use the wiki markup <nowiki>~~~</nowiki> to insert your wiki username automatically (but only do this if it is the same as your IRC nickname, otherwise write your IRC nickname in by hand).}}

==Division of Labour==
Please choose a month that is not already taken and then query bugs.kde.org for all bugs in that month. Please mark you irc nickname in the table below to show which month's bugs you are working on to avoid duplication of effort.

The bugzilla query to use for this triage day can be [https://bugs.kde.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDSINFO&bug_status=VERIFIED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_severity&field-1-1-0=bug_status&field-1-2-0=product&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=Phonon&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=critical,grave,major,crash,normal,minor&value-1-1-0=UNCONFIRMED,NEW,ASSIGNED,REOPENED,NEEDSINFO,VERIFIED&value-1-2-0=Phonon&value0-0-0=&votes=&order=bugs.bug_id&query_based_on= found here].

{|
|-
!Month/Time period !! No of bugs !! IRC Nickname !! Status !! Query
|-
| -> 12-2008 || 7 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2006-01-01&chfieldto=2008-12-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|02-2009 || 7 || wilder || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-01-01&chfieldto=2009-02-28&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|03/04-2009 || 18 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-03-01&chfieldto=2009-04-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|05/06-2009 || 21 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-05-01&chfieldto=2009-06-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|07-2009 || 17 || JontheEchidna || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-07-01&chfieldto=2009-07-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|08-2009 || 15 || Mamarok || done || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-08-01&chfieldto=2009-08-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|09-2009 || 24 || Mamarok || triaging || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-09-01&chfieldto=2009-09-30&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|10-2009/1 || 17 || || || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-10-01&chfieldto=2009-10-15&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|10-2009/2 || 18 || || || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-10-16&chfieldto=2009-10-31&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|-
|11-2009 || 26 || HelioCastro || triaging || [https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Phonon&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailreporter1=1&emailcc1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2009-11-01&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]
|}
(Total bugs 180)

== Completed Bugs ==
Below lists the various sections for completed bugs. This aids everyone in double checking each other's work. In addition this allows those of us that don't have bugzilla permissions to list bugs so that the folks with the permissions can follow up.

Please note that this is an experimental layout designed to reduce the number of edit conflicts on this page. Each section is its own subpage. The best way to work with this is to enable section editing by going to "My preferences" > "editing" > "Enable section editing via [edit] links". When you click edit you will automatically edit the subpage.

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing Version Field changed}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs with step-by-step Instructions}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs that are heisenbugs}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs tobe marked as RESOLVED}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as DUPLICATE}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as INVALID}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs needing users with particular setups}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs not related to today}}

{{:Contribute/Bugsquad/BugDays/PhononDay/Bugs that you cant do}}

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-08T22:10:08Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|158515}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* {{bug|197927}}marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|205138}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs that are heisenbugs

2009-11-08T22:06:45Z

Mamarok: /* Valid Bugs that are non-deterministic: "Heisenbugs" */

===Valid Bugs that are non-deterministic: "Heisenbugs"===
If sometimes it happens, and sometimes it doesn't, or if it looks like it works for some people, but not for all, or is a bit random, it goes here. Don't worry too much about sorting this category bug from the "step-by-step/deterministic" bugs, but in general, the first category should be easier for a developer to go and fix.

* {{bug|195938}} Xine backend stuttering sound with Pulseaudio.[[User:Mamarok|Mamarok]]
* {{bug|204958}} Cannot reproduce this here, but the reporter can.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs needing attention from Konqueror developers

2009-11-08T22:00:18Z

Mamarok: /* Phonon bugs that need attention from developers */

===Phonon bugs that need attention from developers===
If anything is in doubt, put it here, and give a description of why you think a developer should look at it.

* {{Bug|180148}} I was able to reproduce until ~1 week ago. Not sure if it's still there. [[User:jacopods|wilder]]
* {{Bug|184584}} Weird: kmix / alsamixer does not affect phonon volume [[User:jacopods|wilder]]
* {{bug|189387}} Sound distortion with high resolution flac files, xine backend.[[User:Mamarok|Mamarok]]
* {{bug|191837}} kded_phononserver.so. Backtrace is not really good. Maybe already solved?.[[User:Mamarok|Mamarok]]
* {{Bug|198216}} The reporter has attached a patch. [[JontheEchidna]]
* {{Bug|198218}} The reporter has given a detailed technical description of the bug. [[JontheEchidna]]
* {{bug|202027}} Encoding problems in XineStream, potential patch.[[User:Mamarok|Mamarok]]
* {{bug|203115}} Video deinterlacing doesn't work with Xine backend, potential patch.[[User:Mamarok|Mamarok]]
* {{Bug|212660}} Vlc is segfaulting. Is phonon passeing the proper data ? [[User:HelioCastro|heliocastro]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs awaiting feedback

2009-11-08T21:57:56Z

Mamarok: /* Bugs Awaiting Feedback */

===Bugs Awaiting Feedback===
If you are waiting for feedback from a reporter, put your bug here.

* {{bug|133120}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|158515}} marked WAITINGFORINFO, previous question needs answered [[JontheEchidna]]
* {{bug|165511}} marked WAITINGFORINFO, old KDE 4.2.2.[[User:Mamarok|Mamarok]]
* {{bug|169926}} marked WAITINGFORINFO, XineStream (Ampache)problem, old report with previous version [[User:Mamarok|Mamarok]]
* {{bug|169768}} marked WAITINGFORINFO, flac not playing on MS Windows, pointed to the codecs to install.[[User:Mamarok|Mamarok]]
* {{bug|171828}} marked WAITINGFORINFO, unknown backend, old report.[[User:Mamarok|Mamarok]]
* {{bug|178692}} marked WAITINGFORINFO, he uses an old libxine 1.15.[[User:Mamarok|Mamarok]]
* {{bug|185638}} marked BACKTRACE, a crash on startup with digikam, gstreamer related.[[User:Mamarok|Mamarok]]
* {{bug|185897}} marked WAITINGFORINFO, SoundBlaster Live 5.1 'not working'.[[User:Mamarok|Mamarok]]
* {{bug|186667}} marked WAITINGFORINFO, old report with KDE 4.2.2.[[User:Mamarok|Mamarok]] 13:10, 8 November 2009 (UTC)
* {{bug|187399}} marked WAITINGFORINFO, old report with KDE 4.2.0.[[User:Mamarok|Mamarok]]
* {{bug|187688}} marked WAITINGFORINFO, device info needed.[[User:Mamarok|Mamarok]]
* {{bug|187883}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|189576}} marked WAITINGFORINFO, old report with KDE 4.1.[[User:Mamarok|Mamarok]]
* {{bug|195290}} marked WAITINGFORINFO, old report from KDE 4.2.0, very fuzzy description.[[User:Mamarok|Mamarok]]
* {{bug|195595}} marked WAITINGFORINFO, strange sound distortion with Xine backend in mp3.[[User:Mamarok|Mamarok]]
* {{bug|197927}}marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|198090}} marked BACKTRACE, Amarok crash on exit.[[User:Mamarok|Mamarok]]
* {{bug|198131}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]
* {{bug|203838}} marked WAITINGFORINFO, unknown backend.[[User:Mamarok|Mamarok]]
* {{bug|204127}} marked WAITINGFORINFO, unknown backend, could be a duplicate of {{bug|188444}}.[[User:Mamarok|Mamarok]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs that you cant do

2009-11-08T21:55:23Z

Mamarok: /* gstreamer backend */

===Bugs you can't do===

If there are bugs you can't test with your settings, fill those in here. Since this is most likely due to one of the backends not working for you, we group those by backends here:

* {{bug|162677}} no idea what application this was about, not sure if this should not be changed to ''wish [[User:Mamarok|Mamarok]]
* {{bug|199523}} Can't reproduce since sane (:P) binary distros at least require you to have the Null Phonon backend installed [[JontheEchidna]]

====gstreamer backend====

*{{bug|204112}} gstreamer backend. Dragonplayer doesn't list .avi files as supported, but is able to play those.[[User:Mamarok|Mamarok]]

====xine backend====

* {{bug|168873}} crash on apples hd quicktime gallery. apple changed the webpage with ua-based links. so there is currently no way to test it. [[User:Dtritscher|dtritscher]]

====vlc backend====
* {{bug|201767}} I don't have the vlc backend :( [[JontheEchidna]]
* {{bug|201687}} Ditto [[JontheEchidna]]
* {{bug|201685}} Ditto [[JontheEchidna]]

Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as DUPLICATE

2009-11-08T21:51:38Z

Mamarok: /* Duplicate Bugs */

Contribute/Bugsquad/BugDays/PhononDay/Bugs to be marked as DUPLICATE

2009-11-08T21:50:30Z

Mamarok: /* Duplicate Bugs */