http://wiki.rosalab.com/en/api.php?action=feedcontributions&user=Pavel.shved&feedformat=atomRosalab Wiki - User contributions [en]2024-03-28T22:02:48ZUser contributionsMediaWiki 1.26.4http://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=933Bugs/Workflow2012-09-14T11:12:40Z<p>Pavel.shved: /* How to find bugs that should be triaged? */ fix link to make it discard unresolved bugs</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
== FAQ ==<br />
<br />
{{info|''This section is '''informational''' ''.<br/>It is to help to understand key concepts to the persons involved, and to remind them of steps they are to perform as a part of the subsequent policy.}}<br />
<br />
==== What is that triage thing? ====<br />
<br />
Triage is basically asking user questions and "baking" bug so it looks yummy-yummy enough for developers to eat it. See more in [[#Bug Triage]].<br />
<br />
==== How to find bugs that should be triaged? ====<br />
<br />
# Check the list of [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&list_id=4298&o1=notsubstring&resolution=---&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bug bugs awaiting triage].<br />
# Subscribe to the [[ROSA Mailing Lists#triage-desktop|triage-desktop mailing list]]<br />
<br />
Your job, as a member of the Triage Team is to keep this list empty.<br />
<br />
==== How to notify everyone that the triage has been started? ====<br />
<br />
Put a question mark in the need_info flag. Optionally, put the reporter's email to show that you're needing info from him or her. This means that you have asked the reporter a question, and are waiting for their answer.<br />
<br />
==== I asked user a question, but why is the bug still in the list of bugs awaiting triage? ====<br />
<br />
You forgot to put a question mark to the need_info flag.<br />
<br />
==== How to send the bug to develoeprs? ====<br />
<br />
Change the bug's component from "-Enter Bugs Here-" to the proper one. See [[#Bug Categories]].<br />
<br />
==== Will I receive the messages after the triage has been finished? ====<br />
<br />
If you were personally involved in triage, then yes. You are automatically added to CC list, and unless you remove yourself, you'll receive messages. If you just received this via triage-desktop@ mailing list, then no.<br />
<br />
==== I am a developer, what should I do to not participate in triage? ====<br />
<br />
Don't do anything. In particular, do not subscribe to triage-desktop@ mailing list. Subscribing to bugs@ will make you receive messages about triaged bugs only.<br />
<br />
==== How to send bug back to triage? ====<br />
<br />
Change its component to "-Enter Bugs Here-".<br />
<br />
==== Somebody filed the bug directly to Main Pakcages without triage, should I send the bug back? ====<br />
<br />
First, check if the bug really needs triage. Maybe it was filed by a developer or tester of ROSA Desktop, who knows what information is necessary. Maybe it has already been triaged in helpdesk. If the bug really needs triage, change its component to "-Enter Bugs Here-".<br />
<br />
==== How to triage private bugs? ====<br />
<br />
They're triaged like all other bugs. However, the messages are sent to private-bugs@ mailing list rather than to the desktop-triage@. You will see them in the list of bugs awaiting triage, however, if you have enough permissions, with a lock sign nearby.<br />
<br />
<br />
== Policy ==<br />
<br />
{{info|''The rest of this document is a '''pending policy'''.<br/>The Technical Committee agreed that we should start to work as follows, but the policy is subject to small changes in the near future.}}<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product in [[ROSA Bugzilla]]. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** no status: we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* send bug back to triage by ensuring its component is "Enter Bugs Here."<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=932Using ROSA Bugzilla2012-09-14T11:12:26Z<p>Pavel.shved: /* Triaging */</p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop%20Bugs&list_id=4217 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=%5bBug%20creation%5d&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&list_id=4298&o1=notsubstring&resolution=---&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&list_id=4300&v3=5d&o1=notsubstring&resolution=---&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&list_id=4306&o1=substring&resolution=---&query_based_on=should_be_closed_as_old&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=90d&known_name=should_be_closed_as_old old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Developers ====<br />
<br />
* '''[http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4277&o1=nowordssubstr&resolution=---&o2=greaterthaneq&query_format=advanced&f2=bug_severity&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&v1=wontfix%20known%20unknown&component=Main%20Packages&v2=normal&product=Desktop%20Bugs Only Severe, Non-Upstream, Triaged bugs in Main repo]'''. See [[Bugs/Severity]].<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4275&o1=nowordssubstr&resolution=---&query_format=advanced&v1=wontfix%20known%20unknown&product=Desktop%20Bugs only non-upstream bugs in ROSA Desktop]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4273&o1=anywordssubstr&resolution=---&query_format=advanced&v1=wontfix%20known%20unknown&product=Desktop%20Bugs upstream bugs in ROSA Desktop]<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=931Using ROSA Bugzilla2012-09-14T11:09:30Z<p>Pavel.shved: /* Triaging */</p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop%20Bugs&list_id=4217 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=%5bBug%20creation%5d&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&list_id=4298&o1=notsubstring&resolution=---&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&list_id=4300&v3=5d&o1=notsubstring&resolution=---&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=90d&list_id=4214 old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Developers ====<br />
<br />
* '''[http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4277&o1=nowordssubstr&resolution=---&o2=greaterthaneq&query_format=advanced&f2=bug_severity&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&v1=wontfix%20known%20unknown&component=Main%20Packages&v2=normal&product=Desktop%20Bugs Only Severe, Non-Upstream, Triaged bugs in Main repo]'''. See [[Bugs/Severity]].<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4275&o1=nowordssubstr&resolution=---&query_format=advanced&v1=wontfix%20known%20unknown&product=Desktop%20Bugs only non-upstream bugs in ROSA Desktop]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4273&o1=anywordssubstr&resolution=---&query_format=advanced&v1=wontfix%20known%20unknown&product=Desktop%20Bugs upstream bugs in ROSA Desktop]<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=930Using ROSA Bugzilla2012-09-14T10:06:39Z<p>Pavel.shved: </p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop%20Bugs&list_id=4217 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=%5bBug%20creation%5d&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&v3=5d&o1=notsubstring&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs&list_id=4211 bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=90d&list_id=4214 old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Developers ====<br />
<br />
* '''[http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4277&o1=nowordssubstr&resolution=---&o2=greaterthaneq&query_format=advanced&f2=bug_severity&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&v1=wontfix%20known%20unknown&component=Main%20Packages&v2=normal&product=Desktop%20Bugs Only Severe, Non-Upstream, Triaged bugs in Main repo]'''. See [[Bugs/Severity]].<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4275&o1=nowordssubstr&resolution=---&query_format=advanced&v1=wontfix%20known%20unknown&product=Desktop%20Bugs only non-upstream bugs in ROSA Desktop]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=cf_upstream&list_id=4273&o1=anywordssubstr&resolution=---&query_format=advanced&v1=wontfix%20known%20unknown&product=Desktop%20Bugs upstream bugs in ROSA Desktop]<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Severity&diff=929Bugs/Severity2012-09-14T10:04:44Z<p>Pavel.shved: </p>
<hr />
<div>The following describes bug severity that should be set during the initial resolution of a bug during the [[Bugs/Workflow]].<br />
<br />
The bug severity may be changed at any time. Within this policy, the severity is left to maintainer's discretion, and the [[ROSA Technical Committee]] has a right to overrule. The severity is set to:<br />
<br />
; blocker<br />
: The error breaks the whole system or a large group of packages, makes the system non-bootable, non-updateable, causes severe user data corruption or loss.<br />
; critical<br />
: The error makes an important user package reproducibly fail to run on majority of user systems, causes user data corruption in regard of this and/or related packages, or the package fails to build from sources against the current build environment.<br />
; major<br />
: Package is not usable for most users, fails to fulfill its original purpose under most configurations, and/or contains a severe usability problem.<br />
; normal<br />
: A usual error that doesn't fall into the categories above or below.<br />
; minor<br />
: A small mistake that doesn't influence the package functionality in general, easily workaroundable issues. An error that appears on very unusual configurations<br />
; trivial<br />
: A typo in documentation or manpage or similarly trivial error.<br />
; enhancement<br />
: New functionality requests, including failures to meet user's expectations from the interface component or package functionality.<br />
<br />
Note that requests for packaging new versions fall under the specific category, ''"Package Request"'', and severity is not relevant there, and should be kept "Normal".<br />
<br />
<br />
{{message|This Policy is inspired by [http://www.altlinux.org/Bug_Severity_Policy ALT Linux Bug Severity Policy].}}<br />
<br />
[[Category:ROSA Policies]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Severity&diff=928Bugs/Severity2012-09-14T10:04:34Z<p>Pavel.shved: </p>
<hr />
<div>The following describes bug severity that should be set during the initial resolution of a bug during the [[Bugs/Workflow]].<br />
<br />
The bug severity may be changed at any time. Within this policy, the severity is left to maintainer's discretion, and the [[ROSA Technical Committee]] has a right to overrule. The severity is set to:<br />
<br />
; blocker<br />
: The error breaks the whole system or a large group of packages, makes the system non-bootable, non-updateable, causes severe user data corruption or loss.<br />
; critical<br />
: The error makes an important user package reproducibly fail to run on majority of user systems, causes user data corruption in regard of this and/or related packages, or the package fails to build from sources against the current build environment.<br />
; major<br />
: Package is not usable for most users, fails to fulfill its original purpose under most configurations, and/or contains a severe usability problem.<br />
; normal<br />
: A usual error that doesn't fall into the categories above or below.<br />
; minor<br />
: A small mistake that doesn't influence the package functionality in general, easily workaroundable issues. An error that appears on very unusual configurations<br />
; trivial<br />
: A typo in documentation or manpage or similarly trivial error.<br />
; enhancement<br />
: New functionality requests, including failures to meet user's expectations from the interface component or package functionality.<br />
<br />
Note that requests for packaging new versions fall under the specific category, ''"Package Request"'', and severity is not relevant there, and should be kept "Normal".<br />
<br />
<br />
{{message|This Policy is inspired by [http://www.altlinux.org/Bug_Severity_Policy ALT Linux Bug Severity Policy].}}<br />
<br />
[[Category:ROSA Policy]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=927Bugs/Workflow2012-09-14T09:48:20Z<p>Pavel.shved: /* Initial Resolution */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
== FAQ ==<br />
<br />
{{info|''This section is '''informational''' ''.<br/>It is to help to understand key concepts to the persons involved, and to remind them of steps they are to perform as a part of the subsequent policy.}}<br />
<br />
==== What is that triage thing? ====<br />
<br />
Triage is basically asking user questions and "baking" bug so it looks yummy-yummy enough for developers to eat it. See more in [[#Bug Triage]].<br />
<br />
==== How to find bugs that should be triaged? ====<br />
<br />
# Check the list of [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage].<br />
# Subscribe to the [[ROSA Mailing Lists#triage-desktop|triage-desktop mailing list]]<br />
<br />
Your job, as a member of the Triage Team is to keep this list empty.<br />
<br />
==== How to notify everyone that the triage has been started? ====<br />
<br />
Put a question mark in the need_info flag. Optionally, put the reporter's email to show that you're needing info from him or her. This means that you have asked the reporter a question, and are waiting for their answer.<br />
<br />
==== I asked user a question, but why is the bug still in the list of bugs awaiting triage? ====<br />
<br />
You forgot to put a question mark to the need_info flag.<br />
<br />
==== How to send the bug to develoeprs? ====<br />
<br />
Change the bug's component from "-Enter Bugs Here-" to the proper one. See [[#Bug Categories]].<br />
<br />
==== Will I receive the messages after the triage has been finished? ====<br />
<br />
If you were personally involved in triage, then yes. You are automatically added to CC list, and unless you remove yourself, you'll receive messages. If you just received this via triage-desktop@ mailing list, then no.<br />
<br />
==== I am a developer, what should I do to not participate in triage? ====<br />
<br />
Don't do anything. In particular, do not subscribe to triage-desktop@ mailing list. Subscribing to bugs@ will make you receive messages about triaged bugs only.<br />
<br />
==== How to send bug back to triage? ====<br />
<br />
Change its component to "-Enter Bugs Here-".<br />
<br />
==== Somebody filed the bug directly to Main Pakcages without triage, should I send the bug back? ====<br />
<br />
First, check if the bug really needs triage. Maybe it was filed by a developer or tester of ROSA Desktop, who knows what information is necessary. Maybe it has already been triaged in helpdesk. If the bug really needs triage, change its component to "-Enter Bugs Here-".<br />
<br />
==== How to triage private bugs? ====<br />
<br />
They're triaged like all other bugs. However, the messages are sent to private-bugs@ mailing list rather than to the desktop-triage@. You will see them in the list of bugs awaiting triage, however, if you have enough permissions, with a lock sign nearby.<br />
<br />
<br />
== Policy ==<br />
<br />
{{info|''The rest of this document is a '''pending policy'''.<br/>The Technical Committee agreed that we should start to work as follows, but the policy is subject to small changes in the near future.}}<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product in [[ROSA Bugzilla]]. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** no status: we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* send bug back to triage by ensuring its component is "Enter Bugs Here."<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=ROSA_Bugzilla&diff=926ROSA Bugzilla2012-09-14T09:45:25Z<p>Pavel.shved: Redirected page to Using ROSA Bugzilla</p>
<hr />
<div>#REDIRECT [[Using ROSA Bugzilla]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=925Bugs/Workflow2012-09-14T09:45:00Z<p>Pavel.shved: /* Scope */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
== FAQ ==<br />
<br />
{{info|''This section is '''informational''' ''.<br/>It is to help to understand key concepts to the persons involved, and to remind them of steps they are to perform as a part of the subsequent policy.}}<br />
<br />
==== What is that triage thing? ====<br />
<br />
Triage is basically asking user questions and "baking" bug so it looks yummy-yummy enough for developers to eat it. See more in [[#Bug Triage]].<br />
<br />
==== How to find bugs that should be triaged? ====<br />
<br />
# Check the list of [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage].<br />
# Subscribe to the [[ROSA Mailing Lists#triage-desktop|triage-desktop mailing list]]<br />
<br />
Your job, as a member of the Triage Team is to keep this list empty.<br />
<br />
==== How to notify everyone that the triage has been started? ====<br />
<br />
Put a question mark in the need_info flag. Optionally, put the reporter's email to show that you're needing info from him or her. This means that you have asked the reporter a question, and are waiting for their answer.<br />
<br />
==== I asked user a question, but why is the bug still in the list of bugs awaiting triage? ====<br />
<br />
You forgot to put a question mark to the need_info flag.<br />
<br />
==== How to send the bug to develoeprs? ====<br />
<br />
Change the bug's component from "-Enter Bugs Here-" to the proper one. See [[#Bug Categories]].<br />
<br />
==== Will I receive the messages after the triage has been finished? ====<br />
<br />
If you were personally involved in triage, then yes. You are automatically added to CC list, and unless you remove yourself, you'll receive messages. If you just received this via triage-desktop@ mailing list, then no.<br />
<br />
==== I am a developer, what should I do to not participate in triage? ====<br />
<br />
Don't do anything. In particular, do not subscribe to triage-desktop@ mailing list. Subscribing to bugs@ will make you receive messages about triaged bugs only.<br />
<br />
==== How to send bug back to triage? ====<br />
<br />
Change its component to "-Enter Bugs Here-".<br />
<br />
==== Somebody filed the bug directly to Main Pakcages without triage, should I send the bug back? ====<br />
<br />
First, check if the bug really needs triage. Maybe it was filed by a developer or tester of ROSA Desktop, who knows what information is necessary. Maybe it has already been triaged in helpdesk. If the bug really needs triage, change its component to "-Enter Bugs Here-".<br />
<br />
==== How to triage private bugs? ====<br />
<br />
They're triaged like all other bugs. However, the messages are sent to private-bugs@ mailing list rather than to the desktop-triage@. You will see them in the list of bugs awaiting triage, however, if you have enough permissions, with a lock sign nearby.<br />
<br />
<br />
== Policy ==<br />
<br />
{{info|''The rest of this document is a '''pending policy'''.<br/>The Technical Committee agreed that we should start to work as follows, but the policy is subject to small changes in the near future.}}<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product in [[ROSA Bugzilla]]. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* send bug back to triage by ensuring its component is "Enter Bugs Here."<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=924Bugs/Workflow2012-09-14T09:37:13Z<p>Pavel.shved: add FAQ</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
== FAQ ==<br />
<br />
{{info|''This section is '''informational''' ''.<br/>It is to help to understand key concepts to the persons involved, and to remind them of steps they are to perform as a part of the subsequent policy.}}<br />
<br />
==== What is that triage thing? ====<br />
<br />
Triage is basically asking user questions and "baking" bug so it looks yummy-yummy enough for developers to eat it. See more in [[#Bug Triage]].<br />
<br />
==== How to find bugs that should be triaged? ====<br />
<br />
# Check the list of [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage].<br />
# Subscribe to the [[ROSA Mailing Lists#triage-desktop|triage-desktop mailing list]]<br />
<br />
Your job, as a member of the Triage Team is to keep this list empty.<br />
<br />
==== How to notify everyone that the triage has been started? ====<br />
<br />
Put a question mark in the need_info flag. Optionally, put the reporter's email to show that you're needing info from him or her. This means that you have asked the reporter a question, and are waiting for their answer.<br />
<br />
==== I asked user a question, but why is the bug still in the list of bugs awaiting triage? ====<br />
<br />
You forgot to put a question mark to the need_info flag.<br />
<br />
==== How to send the bug to develoeprs? ====<br />
<br />
Change the bug's component from "-Enter Bugs Here-" to the proper one. See [[#Bug Categories]].<br />
<br />
==== Will I receive the messages after the triage has been finished? ====<br />
<br />
If you were personally involved in triage, then yes. You are automatically added to CC list, and unless you remove yourself, you'll receive messages. If you just received this via triage-desktop@ mailing list, then no.<br />
<br />
==== I am a developer, what should I do to not participate in triage? ====<br />
<br />
Don't do anything. In particular, do not subscribe to triage-desktop@ mailing list. Subscribing to bugs@ will make you receive messages about triaged bugs only.<br />
<br />
==== How to send bug back to triage? ====<br />
<br />
Change its component to "-Enter Bugs Here-".<br />
<br />
==== Somebody filed the bug directly to Main Pakcages without triage, should I send the bug back? ====<br />
<br />
First, check if the bug really needs triage. Maybe it was filed by a developer or tester of ROSA Desktop, who knows what information is necessary. Maybe it has already been triaged in helpdesk. If the bug really needs triage, change its component to "-Enter Bugs Here-".<br />
<br />
==== How to triage private bugs? ====<br />
<br />
They're triaged like all other bugs. However, the messages are sent to private-bugs@ mailing list rather than to the desktop-triage@. You will see them in the list of bugs awaiting triage, however, if you have enough permissions, with a lock sign nearby.<br />
<br />
<br />
== Policy ==<br />
<br />
{{info|''The rest of this document is a '''pending policy'''.<br/>The Technical Committee agreed that we should start to work as follows, but the policy is subject to small changes in the near future.}}<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* send bug back to triage by ensuring its component is "Enter Bugs Here."<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=ROSA_Mailing_Lists&diff=922ROSA Mailing Lists2012-09-13T16:28:33Z<p>Pavel.shved: add info about triage list</p>
<hr />
<div>Rosa Mailing Lists are listed here. All lists have '@lists.rosalab.ru' suffix.<br />
<br />
=== Mailing Lists. ===<br />
<br />
==== rosa-devel ==== <br />
<br />
A primary mailing list for developers of ROSA Desktop Linux distribution. Developers, maintainers, and other contributors discuss the development of ROSA Desktop.<br />
<br />
The messages posted to rosa-devel mailing list as new threads--and only these messages--are considered as announces that span all the contributors of ROSA Desktop. If a discussion took place somewhere else, e.g. in IRC, in Skype, or in other mailing lists then it is considered as a local one that doesn't reach the broad audience, and it is assumed that not every ROSA developer had the opportunity to participate.<br />
<br />
* Membership: premoderated (Denis Koryavov is in charge); all enthusiasts are welcome, all maintainers are subscribed automaticaly.<br />
* Publicity: all messages are considered public;<br />
* Language: English is a primary language. [http://translate.google.com/ Google translate] is there to assist you.<br />
* Access for non-members:<br />
** posting: no<br />
** archives: no<br />
* [http://lists.rosalab.ru/mailman/listinfo/rosa-devel Subscribe], [mailto:rosa-devel@lists.rosalab.ru send a mail]<ref name="rosamsk"/>.<br />
<br />
==== release-board ====<br />
<br />
Private discussions of technical questions and ROSA team internal issues and . A primary point of contact with the [[ROSA Technical Committee]]. Please, do not discuss anything that doesn't need to be private in this list.<br />
<br />
* Membership: invite-only, Vladimir Rubanov is in charge.<br />
* Publicity: all messages are considered '''private'''.<br />
* Language: currently, mostly Russian, and sometimes English.<br />
* Access for non-members:<br />
** posting: yes, premoderated;<br />
** archives: no;<br />
* [http://lists.rosalab.ru/mailman/listinfo/release-board Subscribe], [mailto:release-board@lists.rosalab.ru send an e-mail]<ref name="rosamsk"/><br />
<br />
==== triage-desktop ====<br />
<br />
A feed with all public bugs pending triage from [[ROSA Bugzilla]], and changes made to them until the triage is completed:<br />
<br />
* Membership: self-subscribe;<br />
* Publicity: all messages are public;<br />
* Posting: Nobody can post;<br />
* [http://lists.rosalab.ru/mailman/listinfo/triage-desktop Subscribe]<ref name="rosamsk"/><br />
<br />
==== bugs ====<br />
<br />
A feed with all public bugs from [[ROSA Bugzilla]] and changes made to them, after they've been triaged<br />
<br />
* Membership: self-subscribe;<br />
* Publicity: all messages are public;<br />
* Posting: Nobody can post;<br />
* [http://lists.rosalab.ru/mailman/listinfo/bugs Subscribe]<ref name="rosamsk"/><br />
<br />
==== private-bugs ====<br />
<br />
A feed with all private bugs from [[ROSA Bugzilla]] and changes made to them; includes both those pending triage and already triaged.<br />
<br />
* Membersip: subscription is premoderated, only selected ROSA employees may subscribe.<br />
* Publicity: all messages are considered '''secret''', and should not be revealed;<br />
* Posting: Nobody can post.<br />
* [http://lists.rosalab.ru/mailman/listinfo/private-bugs Subscribe]<ref name="rosamsk">If you reside in Moscow ROSA office, and have trouble connecting to mailing list servers, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here]</ref>.<br />
<br />
=== Mailing list policy ===<br />
<br />
All users of mailing lists must read and comply with the [[Mailing List policy]].<br />
<br />
=== If you need a new list ===<br />
<br />
Contact [mailto:pavel.shved@rosalab.ru Pavel Shved]. If the list becomes important and useful, it will be documented on this page.<br />
<br />
=== Notes ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Infrastructure]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=921Using ROSA Bugzilla2012-09-13T16:17:27Z<p>Pavel.shved: /* Update request tracking */</p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop%20Bugs&list_id=4217 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=%5bBug%20creation%5d&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&v3=5d&o1=notsubstring&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs&list_id=4211 bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=90d&list_id=4214 old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=920Using ROSA Bugzilla2012-09-13T16:16:55Z<p>Pavel.shved: /* Triaging */</p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop Bugs&list_id=4193 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=%5bBug%20creation%5d&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&v3=5d&o1=notsubstring&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs&list_id=4211 bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=90d&list_id=4214 old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=919Using ROSA Bugzilla2012-09-13T16:16:32Z<p>Pavel.shved: /* Feature and task tracking */</p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop Bugs&list_id=4193 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=%5bBug%20creation%5d&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&v3=5d&o1=notsubstring&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs&list_id=4211 bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter Bugs Here-&v2=90d&list_id=4214 old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Using_ROSA_Bugzilla&diff=918Using ROSA Bugzilla2012-09-13T16:15:11Z<p>Pavel.shved: /* Useful links */</p>
<hr />
<div>ROSA Bugzilla is located at http://bugs.rosalinux.ru/. The main purpose of this site is to serve as a central point of contact with distribution maintainers and developers about the problems in the ROSA Desktop distributions.<br />
<br />
To file bugs there, you should "register" at Bugzilla itself, ABF credentials won't work.<br />
<br />
=== What issues are tracked in ROSA Bugzilla? ===<br />
<br />
[http://bugs.rosalinux.ru/ ROSA Bugzilla] is used to track all "downstream" issues with ROSA Desktop, and some problems with ROSA Bugzilla infrastructure. Here's the list of issues you should file to the Bugzilla:<br />
<br />
# Bugs in already released ROSA Desktop distributions;<br />
# Bugs in packages and distributions that have not yet been released.<br />
# Issues with ROSA collaboration infrastructure, such as forums, wiki and ROSA Bugzilla itself.<br />
<br />
=== How to report a bug ===<br />
<br />
The ROSA Bugzilla, though it has some specific tweaks, is just a usual bugzilla. The interface is most likely familliar to you: if you saw one issue tracker then you've seen them all.<br />
<br />
To report a new bug, or to comment on an existing one, you should obtain an account first by registering at the bugzilla itself. ABF credentials do not work. ROSA corporate mail credentials do not work. Your can't register via your Facebook or Twitter account either. We tried to keep it simple.<br />
<br />
After that, just click "New", select a product you wish to report bug (most likely, it will be "ROSA Linux")<ref>The hints and design of the "New bug" page was inspired by [http://qa.mandriva.com/ Mandriva Bugzilla], and some texts were borrowed from there.</ref>. Specify the category you want to report the bug against; if unsure, select "Main Packages". When you report a bug, you should specify a package you have problems with; the bug filing form contains instructions on how to obtain this information. This information is used to determine the person responsible for fixing the bug<ref>This is not yet implemented, but is coming very soon, by the end of May 2012.</ref>. Fill all the fields in the form, following the instructions listed nearby.<br />
<br />
If you think your bug is sensitive, read [[#Security and business-sensitive issues|this section]].<br />
<br />
=== Accompanying mailing lists ===<br />
<br />
There are two mailing list useful to make the interaction with the bug tracker easier<br />
<br />
* bugs@lists.rosalab.ru — notifications about all new bugs that aren't marked as "sensitive" (see [[#Security and business-sensitive issues|here]]) and about changes made to them are sent to this list. You may subscribe at your own automatically [http://lists.rosalab.ru/mailman/listinfo/bugs here];<br />
* private-bugs@lists.rosalab.ru — notifications about [[#Security and business-sensitive issues|sensitive bugs]] are sent here. Only a ROSA employee may subscribe, via [http://lists.rosalab.ru/mailman/listinfo/private-bugs this form].<br />
<br />
=== How to propose a feature ===<br />
<br />
To propose a feature, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Features open a new Bugzilla ticket in "Features" product]. The feature will be reviewed by developers as soon as possible, and it will be decided if it's worth allocating resources at, or if the feature fits the overall concept of ROSA Desktop. Make sure you have [http://bugs.rosalinux.ru/query.cgi?format=specific&product=Features searched for similar features] (or reviewed the [http://bugs.rosalinux.ru/buglist.cgi?list_id=2646&query_format=advanced&product=Features list of all features]) because your proposal might have already been reviewed.<br />
<br />
If the feature is so sensitive to ROSA business that it should be kept secret from the broad audience, select "ROSA employees" group restriction at the bottom of the bug.<br />
<br />
See [[#Useful links]] for the list of feature-related queries.<br />
<br />
=== Useful links ===<br />
<br />
Bugzilla has an advanced bug search and filter mechanism, though it's not easy to use. I gathered some useful search queries here:<br />
<br />
==== Update request tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&list_id=4190&v1=qa_verified%3F&o1=substring&product=Desktop%20Bugs requests pending QA approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=secteam_verified%3F&o1=substring&product=Desktop%20Bugs&list_id=4192 Update requests pending secteam approval]<br />
* [buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=published%3F&o1=substring&product=Desktop Bugs&list_id=4193 Update requests pending Repo-man approval]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&query_based_on=qa_pending_week&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=qa_verified%3F&component=Localization&component=Main%20Packages&v2=7d&product=Desktop%20Bugs&known_name=qa_pending_week&list_id=4194 Update requests that have been pending QA approval for more than a week]<br />
<br />
==== Feature and task tracking ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&product=Desktop%20Features&list_id=4196 All unconfirmed features]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?list_id=4202&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&query_based_on=recent_features&chfieldto=Now&chfield=[Bug%20creation]&query_format=advanced&chfieldfrom=15d&bug_status=UNCONFIRMED&product=Desktop%20Features&known_name=recent_features all ''recently'' proposed features];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Features&list_id=4204 all accepted features for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=target_milestone&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=short_desc%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cchangeddate&v1=2012%20Desktop&o1=substring&product=Desktop%20Bugs&product=Desktop%20Features&list_id=4205 all accepted features ''and'' important bugfixes for ''2012 Desktop'' release];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&product=Desktop%20Features&list_id=4206 all features (regardless of their status];<br />
<br />
==== Triaging ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?f1=flagtypes.name&o1=notsubstring&query_format=advanced&v1=need_info&component=-Enter%20Bugs%20Here-&product=Desktop%20Bugs&list_id=4209 bugs awaiting triage];<br />
* [http://bugs.rosalinux.ru/buglist.cgi?n2=1&f1=flagtypes.name&o3=changedbefore&v3=5d&o1=notsubstring&o2=changedafter&query_format=advanced&f3=creation_ts&f2=flagtypes.name&v1=need_info%3F&component=-Enter%20Bugs%20Here-&v2=5d&product=Desktop%20Bugs&list_id=4211 bugs that have been awaiting triage for more than 5 days] (triagers are to clear this list, see [[Bugs/Workflow]]);<br />
* [buglist.cgi?n2=1&f1=flagtypes.name&o1=substring&o2=changedafter&query_format=advanced&f2=flagtypes.name&v1=need_info%3F&component=-Enter Bugs Here-&v2=90d&list_id=4214 old bugs that have been waiting for user's response for 90 days] (should be closed; see [[Bugs/Workflow]])<br />
<br />
==== Misc ====<br />
<br />
* [http://bugs.rosalinux.ru/buglist.cgi?resolution=---&query_format=advanced&component=Package%20Requests&list_id=4207 requests for new packages]<br />
* [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&v1=yes&o1=equals&product=Desktop%20Bugs&list_id=4208 list all ISO-related bugs]<br />
<br />
=== Security and business-sensitive issues ===<br />
<br />
If your issue is sensitive because<br />
<br />
# you are reporting a security bug;<br />
# you are a ROSA employee, contractor, or customer, and want to raise a business-sensitive issue;<br />
<br />
you should click '''"ROSA Employees" checkbox''' at the bottom of the bug file form. This will make the bug visible to you and ROSA employees only.<ref>In case you're worried about this, "QA contact" field will automatically be reset to a private mailing list in this case".</ref><br />
<br />
Warning! '''If you forget to set this checkbox, the bug comment will automatically be disseminated through a public mailing list, and you can't cancel it later'''. Please, be careful with this.<br />
<br />
If you need greater security, contact admins; see [[#What to do if there's a problem with the Bugzilla]].<br />
<br />
=== How to edit a comment ===<br />
<br />
There is no way to edit a comment in Bugzilla once it has been published. Post a new one instead.<br />
<br />
Bugzilla comments are used to track the whole history of the work made on a bug. Editing a comment might also affect the responses to it, and whether [[Requesting an Update|an update]] was approved/rejected. That's why we would turn off the ability to edit comments even if it was present in the stock Bugzilla.<br />
<br />
=== ROSA-sepcific features ===<br />
<br />
[[File:rosa-bz-features-urc.png|thumb|"Request for Update" checkbox]][http://bugs.rosalinux.ru/ ROSA Bugzilla] has a number of tweaks that aid us in the development process of ROSA linux distribution. Here's a list of them.<br />
<br />
==== Update Request checkbox ====<br />
<br />
[[File:rosa-bz-features-furrc.png|thumb|Filtered comment stream]]The process of updating a released ROSA Linux distribution is built on top of Bugzilla. You can read more in [[Requesting an Update]] policy. An interface of bugzilla was extended with a "Request for Update" checkbox. The value of this checkbox denotes whether this bug is also an update request. The checkbox also helps you to fulfill the requirements of the [[Requesting an Update]] policy by disabling itself if your comment doesn't have enough information.<br />
<br />
When you set this checkbox, the QA (or some other party your update had issues with, Security team, for instance) is notified about the change, and will process your update in a timely manner. By changing the checkbox state ''and'' committing your change you may notify QA if the package is ready (if you set the checkbox), or cancel the request (if you unset the checkbox).<br />
<br />
==== Filtering Update Request-related comments ====<br />
<br />
To aid QA teams in reading the bug comments efficiently, we added a filter that expands only update-related comments. These are comments that contain the keyword "advisory" '''or''' a link to ABF build list. To use the filter, you must have Javascript enabled in your browser.<br />
<br />
[[File:Rosa-bz-features-hlur.png|thumb|Highlighted update request comments]]<br />
==== Highlighting Update Request comments ====<br />
<br />
Comments that may be related to update requests are highlighted with a greener color, so they can be identified easier in a (possibly) long comment stream. See the screenshot for an example.<br />
<br />
Please, note that '''this only works with the default "Dusk" theme'''!<br />
<br />
==== Common transitions for ROSA teams ====<br />
<br />
Some transitions in the process of [[Requesting an Update|update verification]] are too common to make the team members make many clicks during common operations. Some buttons were added that use Javascript to switch flags and statuses after a QA, secteam or repo-man have worked on the package.<br />
<br />
Note that '''these buttons do not save changes, they just switch the status. To save the changes you should click "Save Changes" and write a comment!'''<br />
<br />
Only buttons relevant to a specific team are displayed. The screenshot to the right is just an illustration that gathers them all in a single screen.<br />
<br />
[[File:Rosa-bz-features-commonclicks.png|thumb|Some of these buttons are shown to the teams to aid them in the update process]]<br />
<br />
==== "ISO-related" checkbox ====<br />
<br />
ROSA Desktop products have "ISO-related" checkbox. The flag should be used by release-managers to mark bugs they will look through when assembling an ISO. As soon as the bug is fixed in ISO, this flag may be removed.<br />
<br />
Here is a [http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=cf_iso&list_id=3322&v1=yes&o1=equals&product=Features&product=ROSA%20Linux query to list all bugs with this checkbox set].<br />
<br />
=== What to do if there's a problem with the Bugzilla ===<br />
<br />
If you have successfully obtained an account, and want to report a broken link, or a problem with Bugzilla functionality, or want to ask for specific permissions, please, [http://bugs.rosalinux.ru/enter_bug.cgi?product=Websites&component=Bugzilla open a bug] in "Bugzilla" component of "Websites" product.<br />
<br />
==== Administrators ====<br />
You may also directly contact bugzilla admins, but we prefer that all requests are directed to the bugzilla itself as described above.<br />
<br />
Bugzilla administration: [mailto:pavel.shved@rosalab.ru Pavel Shved]<br />
<br />
Networking issues: [mailto:vladimir.mironov@rosalab.ru Vladimir Mironov]<br />
<br />
=== For ROSA Employees ===<br />
<br />
If you have problems with accessing bugzilla<ref>for instance, you get a "Server not found" error.</ref>, or wonder what e-mail and password to use, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here].<br />
<br />
=== Notes ===<br />
<br />
<references/></div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Wiki_Squad&diff=916Talk:Wiki Squad2012-09-13T15:18:35Z<p>Pavel.shved: liccense, naming</p>
<hr />
<div><br />
<br />
Hello, world!<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 14:12, 13 September 2012 (MSK)<br />
----<br />
Ok, let's give it a try.<br><br />
* 1. My last message in [[Talk:Sandbox]] testing talk page is about wiki license.<br><br />
License for wiki is missing.<br><br />
Like: "Text is available under the Creative Commons Attribution-ShareAlike License" (e.g. wikipedia.org)<br />
* 2. According to [[Official Naming]] I modified all not proper naming in Italian pages.<br> <br />
I think the same should be done in English pages, and in Russian version if not yet.<br />
<br />
[[User:Rugyada|rugyada]] 17:45, 13 September 2012 (MSK)<br />
<br />
# Where do we add the license?<br />
# I guess we can try to, but it would be good enough to remove "offenders" such as "2012.1" and "LTS" from names and pages. For the English wiki it seems to have already been done, see [http://wiki.rosalab.ru/en/index.php?title=Special%3ASearch&profile=advanced&search=2012.1&fulltext=Search&ns0=1&redirs=1&profile=advanced this], for instance.<br />
[[User:Pavel.shved|Pavel.shved]] 19:18, 13 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Wiki_Squad&diff=914Talk:Wiki Squad2012-09-13T10:12:57Z<p>Pavel.shved: Created page with " Hello, world! ~~~~"</p>
<hr />
<div><br />
<br />
Hello, world!<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 14:12, 13 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Wiki_Squad&diff=913Wiki Squad2012-09-13T10:10:54Z<p>Pavel.shved: create wiki squad</p>
<hr />
<div>This is Wiki Squad, a collective of writers and admins of this wiki. At the [[Talk:Wiki Squad]], we exchange our plans, and discuss the prospects of improving your ROSA wiki experience. At this page, we write some guidelines for ourselves that will help us in administrative work.<br />
<br />
To get notification about new talk messages, just confirm your e-mail address at your [[Special:Preferences]], and ''watch'' this page.<br />
<br />
The page was started during the [http://bugs.rosalinux.ru/show_bug.cgi?id=751 bug #751] discussion.</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Main_Page&diff=912Main Page2012-09-13T10:08:25Z<p>Pavel.shved: add wiki squad - page for discussing wiki and making its policies</p>
<hr />
<div>In develop new version - [[ROSA Desktop 2012|ROSA Desktop 2012]]<br />
<br />
<div style="color: #34A4FA; font-style:normal; font-size: 3em; font-weight: bold; text-align: center;">'''ROSA [[2012]] LTS MARATHON'''</div> <br /><br />
<!-- [[Image:ROSA_logo_n.jpg|left]] --><br />
<br /><br />
{| valign="top" align="left"<br />
| valign="top"|[[Image:Mandriva Desktop-2011-default-view.png|140px]]<br />
| valign="top" align="justify"|&nbsp;&nbsp;[[ROSA_Marathon_2012|ROSA 2012 LTS Marathon]] is a LTS (long time support) release with guaranteed security and software updates for 5 years. Based on Mandriva/ROSA 2011 repositories with lots of improvements and updates. It is recommended for Enterprise, SMB and SOHO which do not need the "bleeding edge" technology, but require stable software and ability to work for a long time without reinstalling the system. This is the first release completely built using the [[ABF]] system.<br />
<br />
<br />
<div style="font-size: 15px;">'''Dear users'''! <br />
<br />
You can take a look at the [[Release_notes_ROSA_Marathon_2012|LTS 2012 Release notes]] <br />
<br />
and [[Errata ROSA Marathon 2012|list of known issues (Errata) in ROSA Marathon 2012]] </div><br />
<br />
<br />
|-<br />
| align="center" colspan="2" |{{Downloads|List of [[ROSA Release|ROSA releases]]}}<br />
|}<br />
<hr><br />
<br />
'''Please pay your attention to the ROSA Desktop 2012 release [[ROSA Desktop 2012 roadmap|roadmap]].'''<br />
<br />
== The free documentation on products ROSA ==<br />
{|<br />
!style="background:#BEE4F9"|For novices users<br />
!style="background:#BEE4F9"|For experienced users<br />
!style="background:#BEE4F9"|For developers<br />
!style="background:#BEE4F9"|See also<br />
|-<br />
|valign="top"|<br />
{|<br />
|valign="top"|<ul><br />
<li>[[ROSA Installation]]<br /><br />
<li>[[How to Install ROSA in VirtualBox]]<br /><br />
<li>[[Upgrade_systems|Upgrading from ROSA 2011 to ROSA 2012 LTS Marathon]]<br/><br />
<li>[[Setting up ROSA]]<br/><br />
<li>[[:Category:HowTo|Howto]]<br/><br />
<li>[[Guidelines for use of the service 2Safe]]<br /><br />
<li>[[ROSA applications]]<br /><br />
<li>[[ROSA HCL|ROSA Hardware Compatibility List]]<br /><br />
</ul><br />
|}<br />
|valign="top"|<br />
{|<br />
|valign="top"|<ul><br />
<li>[[Bug Workflow in ROSA Desktop]]<br/><br />
<li>[http://wiki.rosalab.ru/index.php/Improver "Improver" Testing System]<br/><br />
<li>[[ROSA Sync Client]]<br/><br />
<li>[[Packaging HowTo]]<br />
<li>[[Upgrade systems]]<br />
</ul><br />
|}<br />
|valign="top"|<br />
{|<br />
|valign="top"|<ul><br />
<li>[[ROSA Developer QuickStart]]<br/><br />
<li>[http://wiki.rosalab.ru/images/a/a7/Guideline.pdf Icons Guideline] (in Russian)<br /><br />
<li>[[ROSA Logo]]<br /><br />
<li>[[:Category:Packaging Guidelines|Packaging Guidelines]]<br /><br />
<li>[[:Category:Packaging Policies|Packaging Policies]]<br /><br />
<li>[[:Category:ABF Build Environment|ABF Build Environment]]<br /><br />
</ul><br />
|}<br />
|valign="top"|<br />
{|<br />
|valign="top"|<ul><br />
<li>[http://www.rosalab.com/blogs ROSA Blog]<br />
<li>[http://forum.rosalab.ru/ ROSA Forum] (RU, EN)<br />
<li>[http://www.facebook.com/pages/ROSA-Laboratory/165726413457176 ROSA on Facebook]<br />
<li>[http://twitter.com/#!/rosalaboratory ROSA on Twitter]<br />
<li>[http://www.rosalab.com/about/contacts Contacts]<br />
</ul><br />
|}<br />
|}<br />
<br />
== Technical support and bug reports ==<br />
<br />
<br />
At the moment there are two sites where you can ask for help and to report issues in Russian and English:<br />
<br />
[http://support.rosalab.ru/entry support.rosalab.ru]<br />
<br />
[http://helpdesk.rosalab.ru helpdesk.rosalab.ru]<br />
<br />
'''ATTENTION:''' you may register only at http://support.rosalab.ru/auth/register and from one account it is possible to autentificate on both addresses.<br />
<br />
Submit your bug reports to ROSA Bugzilla at http://bugs.rosalinux.ru/ (see also [[Using ROSA Bugzilla]]) <br />
<br />
You can ask questions and comminucate with other ROSA users on our forum at http://forum.rosalab.ru/en/<br />
<br />
* [[Sandbox]]<br />
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration setting manual];<br />
* [http://www.mediawiki.org/wiki/Manual:FAQ FAQ on the MediaWiki];<br />
* [[Wiki Squad]]<br />
<br />
[[en:Main Page]]<br />
[[ru:Заглавная страница]]<br />
[[it:Pagina principale]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=910Bugs/Workflow2012-09-12T14:25:18Z<p>Pavel.shved: remove notions about "Buttons"</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* send bug back to triage by ensuring its component is "Enter Bugs Here."<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Sandbox&diff=907Talk:Sandbox2012-09-11T16:37:49Z<p>Pavel.shved: /* Test talk */</p>
<hr />
<div>Testing Talk pages<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:16, 11 September 2012 (MSK)<br />
<br />
== Why can't we use Talk pages? ==<br />
<br />
Wherefore art thou, Wiki Talk, since nobody uses you?<br />
<br />
OK, I use it, but what about the others?<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:28, 11 September 2012 (MSK)<br />
<br />
== Test talk ==<br />
<br />
test test test<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:29, 11 September 2012 (MSK)<br />
----<br />
test, test.<br />
<br />
[[User:Rugyada|rugyada]] 20:22, 11 September 2012 (MSK)<br />
<br />
----<br />
<br />
Hm, I got your notification... so it seems that the reason why I didn't get any notification is that it was ''me'' who made them?<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 20:28, 11 September 2012 (MSK)<br />
----<br />
If you edited, you will not receive notification about your changes. But you should receive notification about other users' changes.<br />
<br />
[[User:Rugyada|rugyada]] 20:36, 11 September 2012 (MSK)<br />
----<br />
Damn! I've spent an hour debugging this! If it were not for your edit, I'd spent more. Thanks! =)<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 20:37, 11 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Sandbox&diff=905Talk:Sandbox2012-09-11T16:28:58Z<p>Pavel.shved: /* Test talk */</p>
<hr />
<div>Testing Talk pages<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:16, 11 September 2012 (MSK)<br />
<br />
== Why can't we use Talk pages? ==<br />
<br />
Wherefore art thou, Wiki Talk, since nobody uses you?<br />
<br />
OK, I use it, but what about the others?<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:28, 11 September 2012 (MSK)<br />
<br />
== Test talk ==<br />
<br />
test test test<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:29, 11 September 2012 (MSK)<br />
----<br />
test, test.<br />
<br />
[[User:Rugyada|rugyada]] 20:22, 11 September 2012 (MSK)<br />
<br />
----<br />
<br />
Hm, I got your notification... so it seems that the reason why I didn't get any notification is that it was ''me'' who made them?<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 20:28, 11 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=903Sandbox2012-09-11T13:46:20Z<p>Pavel.shved: rm</p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=902Sandbox2012-09-11T13:45:07Z<p>Pavel.shved: </p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}<br />
<br />
test watch page edit<br />
<br />
why doesn't it send mail to me?<br />
<br />
edid</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=901Sandbox2012-09-11T13:38:09Z<p>Pavel.shved: </p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}<br />
<br />
test watch page edit<br />
<br />
why doesn't it send mail to me?</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=900Sandbox2012-09-11T13:37:09Z<p>Pavel.shved: </p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}<br />
<br />
test watch page edit</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=899Sandbox2012-09-11T13:31:59Z<p>Pavel.shved: </p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=898Sandbox2012-09-11T13:30:20Z<p>Pavel.shved: </p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}<br />
<br />
test edit<br />
<br />
more test edit</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Sandbox&diff=897Sandbox2012-09-11T12:30:59Z<p>Pavel.shved: </p>
<hr />
<div>==Wiki Statistics==<br />
<br />
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"<br />
|-<br />
!style="border-style: solid; border-width: 0 1px 1px 0"| Title<br />
!style="border-style: solid; border-width: 0 0 1px 0"| Number<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki pages<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFPAGES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of wiki articles<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFARTICLES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of uploaded files<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFFILES}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of edits<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFEDITS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| Number of registered users<br />
|style="border-style: solid; border-width: 0"| {{NUMBEROFUSERS}}<br />
|-<br />
|style="border-style: solid; border-width: 0 1px 0 0"| MediaWiki version<br />
|style="border-style: solid; border-width: 0"| {{CURRENTVERSION}}<br />
|}<br />
<br />
<br />
About ROSA Desktop<br />
<br />
----<br />
*short description, advantages (probably an overview)<br />
*differences from Mandriva<br />
*where to download<br />
32bit:<br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso<br />
<br />
64bit: <br />
http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso<br />
<br />
*support<br />
#[[ROSA Desktop Installation]]<br />
#ROSA support policy.<br />
----<br />
[[Main Page|'''Main Page''']]<br />
<br />
'''http://wiki.pingwinsoft.ru'''<br />
{{Languages}}<br />
<br />
== Templates ==<br />
<br />
{| border=1 cellpadding=3 cellspacing=0 <br />
! width="20%" style="background:#efefef;" | Name<br />
! width="30%" style="background:#efefef;" | Usage<br />
! width="50%" style="background:#efefef;" | Will look like<br />
|-<br />
| {{[[:Template:Warning]]}} <br />
| At the bottom of unfinished and too short articles (stubs) for which no appropriate template was found.<br />
<br><pre>{{Warning|Beware of dragons!}} </pre><br />
|{{Warning|Beware of dragons!}} <br />
|}<br />
<br />
<br />
{{Downloads|[[File:Dialog-warning.png|24px]]&nbsp;[http://rr.ru/ROSA.2011.iso Download ROSA.iso]}}<br />
<br />
test edit</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Sandbox&diff=896Talk:Sandbox2012-09-11T12:29:51Z<p>Pavel.shved: /* Test talk */ new section</p>
<hr />
<div>Testing Talk pages<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:16, 11 September 2012 (MSK)<br />
<br />
== Why can't we use Talk pages? ==<br />
<br />
Wherefore art thou, Wiki Talk, since nobody uses you?<br />
<br />
OK, I use it, but what about the others?<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:28, 11 September 2012 (MSK)<br />
<br />
== Test talk ==<br />
<br />
test test test<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:29, 11 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Sandbox&diff=895Talk:Sandbox2012-09-11T12:28:26Z<p>Pavel.shved: /* Why can't we use Talk pages? */</p>
<hr />
<div>Testing Talk pages<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:16, 11 September 2012 (MSK)<br />
<br />
== Why can't we use Talk pages? ==<br />
<br />
Wherefore art thou, Wiki Talk, since nobody uses you?<br />
<br />
OK, I use it, but what about the others?<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:28, 11 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Sandbox&diff=894Talk:Sandbox2012-09-11T12:17:03Z<p>Pavel.shved: /* Why can't we use Talk pages? */ new section</p>
<hr />
<div>Testing Talk pages<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:16, 11 September 2012 (MSK)<br />
<br />
== Why can't we use Talk pages? ==<br />
<br />
Wherefore art thou, Wiki Talk, since nobody uses you?</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Talk:Sandbox&diff=893Talk:Sandbox2012-09-11T12:16:09Z<p>Pavel.shved: Created page with "Testing Talk pages ~~~~"</p>
<hr />
<div>Testing Talk pages<br />
<br />
[[User:Pavel.shved|Pavel.shved]] 16:16, 11 September 2012 (MSK)</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=891Bugs/Workflow2012-09-10T13:20:44Z<p>Pavel.shved: /* Scope */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button<ref name="moretriage">Clicking "Needs More Triage" removes you from the assignee, and reassigns the component to "Enter Bugs Here".</ref>.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager presses "Finish Triage" button<ref name="fintriage">This removes the triager from CC list.</ref>. If the button is not available, then you forgot to change the component, which you should ave done; see above. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* Click "Back to Triage" button. This sends bug back to triage.<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=890Bugs/Workflow2012-09-10T13:19:17Z<p>Pavel.shved: </p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button<ref name="moretriage">Clicking "Needs More Triage" removes you from the assignee, and reassigns the component to "Enter Bugs Here".</ref>.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager presses "Finish Triage" button<ref name="fintriage">This removes the triager from CC list.</ref>. If the button is not available, then you forgot to change the component, which you should ave done; see above. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Reproducing Bugs and Failing to Do so ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* Click "Back to Triage" button. This sends bug back to triage.<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Duplicates ====<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Enter Bugs Here<br />
: a central point of contact for new bugs. You should file your bugs here;<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new untriaged bugs is '''triage-desktop@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list, see [[ROSA Mailing Lists]].<br />
<br />
The bugs in other components, where the triaged bugs reside, will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=ROSA_Mailing_Lists&diff=889ROSA Mailing Lists2012-09-10T13:17:18Z<p>Pavel.shved: </p>
<hr />
<div>Rosa Mailing Lists are listed here. All lists have '@lists.rosalab.ru' suffix.<br />
<br />
=== Mailing Lists. ===<br />
<br />
==== rosa-devel ==== <br />
<br />
A primary mailing list for developers of ROSA Desktop Linux distribution. Developers, maintainers, and other contributors discuss the development of ROSA Desktop.<br />
<br />
The messages posted to rosa-devel mailing list as new threads--and only these messages--are considered as announces that span all the contributors of ROSA Desktop. If a discussion took place somewhere else, e.g. in IRC, in Skype, or in other mailing lists then it is considered as a local one that doesn't reach the broad audience, and it is assumed that not every ROSA developer had the opportunity to participate.<br />
<br />
* Membership: premoderated (Denis Koryavov is in charge); all enthusiasts are welcome, all maintainers are subscribed automaticaly.<br />
* Publicity: all messages are considered public;<br />
* Language: English is a primary language. [http://translate.google.com/ Google translate] is there to assist you.<br />
* Access for non-members:<br />
** posting: no<br />
** archives: no<br />
* [http://lists.rosalab.ru/mailman/listinfo/rosa-devel Subscribe], [mailto:rosa-devel@lists.rosalab.ru send a mail]<ref name="rosamsk"/>.<br />
<br />
==== release-board ====<br />
<br />
Private discussions of technical questions and ROSA team internal issues and . A primary point of contact with the [[ROSA Technical Committee]]. Please, do not discuss anything that doesn't need to be private in this list.<br />
<br />
* Membership: invite-only, Vladimir Rubanov is in charge.<br />
* Publicity: all messages are considered '''private'''.<br />
* Language: currently, mostly Russian, and sometimes English.<br />
* Access for non-members:<br />
** posting: yes, premoderated;<br />
** archives: no;<br />
* [http://lists.rosalab.ru/mailman/listinfo/release-board Subscribe], [mailto:release-board@lists.rosalab.ru send an e-mail]<ref name="rosamsk"/><br />
<br />
==== bugs ====<br />
<br />
A feed with all public bugs from [[ROSA Bugzilla]] and changes made to them,<br />
<br />
* Membership: self-subscribe;<br />
* Publicity: all messages are public;<br />
* Posting: Nobody can post;<br />
* [http://lists.rosalab.ru/mailman/listinfo/bugs Subscribe]<ref name="rosamsk"/><br />
<br />
==== private-bugs ====<br />
<br />
A feed with all private bugs from [[ROSA Bugzilla]] and changes made to them.<br />
<br />
* Membersip: subscription is premoderated, only selected ROSA employees may subscribe.<br />
* Publicity: all messages are considered '''secret''', and should not be revealed;<br />
* Posting: Nobody can post.<br />
* [http://lists.rosalab.ru/mailman/listinfo/private-bugs Subscribe]<ref name="rosamsk">If you reside in Moscow ROSA office, and have trouble connecting to mailing list servers, please, refer [https://corpwiki.rosalinux.ru/index.php/Bugzilla_%D0%B4%D0%BB%D1%8F_ROSA_Linux#.D0.94.D0.BE.D1.81.D1.82.D1.83.D0.BF here]</ref>.<br />
<br />
=== Mailing list policy ===<br />
<br />
All users of mailing lists must read and comply with the [http://wiki.rosalab.ru/ru/index.php/Mailing_List_policy mailing list policy].<br />
<br />
=== If you need a new list ===<br />
<br />
Contact [mailto:pavel.shved@rosalab.ru Pavel Shved]. If the list becomes important and useful, it will be documented on this page.<br />
<br />
=== Notes ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Infrastructure]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=888Bugs/Workflow2012-09-10T13:14:45Z<p>Pavel.shved: /* Initial resolution */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button<ref name="moretriage">Clicking "Needs More Triage" removes you from the assignee, and reassigns the component to "Enter Bugs Here".</ref>.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager presses "Finish Triage" button<ref name="fintriage">This removes the triager from CC list.</ref>. If the button is not available, then you forgot to change the component, which you should ave done; see above. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial Resolution ===<br />
<br />
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just to resolve bugs in them, see [[Repo_Policy#Meaning_of_.22Maintained_by_ROSA.22]];<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is confirmed, triaged, and its upstream status is ''unknown'' or ''our'', the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Other Resolutions ===<br />
<br />
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.<br />
<br />
==== Bug reproduction ====<br />
<br />
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.<br />
<br />
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:<br />
<br />
* write a comment about this. Request more information from user;<br />
* Click "Back to Triage" button. This sends bug back to triage.<br />
<br />
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=886Bugs/Workflow2012-09-10T12:38:54Z<p>Pavel.shved: /* Bug Triage */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button<ref name="moretriage">Clicking "Needs More Triage" removes you from the assignee, and reassigns the component to "Enter Bugs Here".</ref>.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
==== Finishing the Triage ====<br />
<br />
When bug triage is over, the triager presses "Finish Triage" button<ref name="fintriage">This removes the triager from CC list.</ref>. If the button is not available, then you forgot to change the component, which you should ave done; see above. The bug will be handled to developers (see [[#Initial Resolution]]).<br />
<br />
==== Problems detected at Triage ====<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=885Bugs/Workflow2012-09-10T12:15:54Z<p>Pavel.shved: /* Bug Triage */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button<ref name="moretriage">Clicking "Needs More Triage" removes you from the assignee, and reassigns the component to "Enter Bugs Here".</ref>.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive);<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=884Bugs/Workflow2012-09-10T12:04:40Z<p>Pavel.shved: /* Filing a bug */</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
All bugs must be filed to '''"Enter Bugs Here"''' component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people may also enter the bugs to other components, thus skipping the triage:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should click the "Needs More Triage" button<ref name="moretriage">Clicking "Needs More Triage" removes you from the assignee, and reassigns the component to "Enter Bugs Here".</ref>.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive)<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* (optional) assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Official_Naming&diff=882Official Naming2012-09-10T11:51:24Z<p>Pavel.shved: /* Company/Product Naming Guideline */</p>
<hr />
<div>This page contains information on official naming of "ROSA" products and the company itself.<br />
<br />
=== Company/Product Naming Guideline ===<br />
<br />
# If you would like to say about '''company''', you must write ''"ROSA"'' (including the quotation marks).<br />
# If you would like to say about '''products''' or '''services''', you must write ''ROSA'' (no quotation marks).<br />
<br />
=== Product Naming ===<br />
<br />
ROSA distributions are named as follows.<br />
<br />
# ''ROSA Marathon 2012'' (meaning [[ROSA Marathon 2012|this]] release). Note the word ordering; the use of "LTS" instead of/alongside with "Marathon" is discouraged;<br />
# ''ROSA Desktop 2012'' (meaning [[ROSA Desktop 2012|this]] release).<br />
<br />
[[Category:ROSA Policy]]<br />
[[ru:Официальное именование]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Official_Naming&diff=881Official Naming2012-09-10T11:50:49Z<p>Pavel.shved: as per Konstantin's mails</p>
<hr />
<div>This page contains information on official naming of "ROSA" products and the company itself.<br />
<br />
=== Company/Product Naming Guideline ===<br />
<br />
# If you would like to say about '''company''', you must write ''"ROSA"'' (quotation marks included).<br />
# If you would like to say about '''products''' or '''services''', you must write ''ROSA'' (no quotation marks).<br />
<br />
=== Product Naming ===<br />
<br />
ROSA distributions are named as follows.<br />
<br />
# ''ROSA Marathon 2012'' (meaning [[ROSA Marathon 2012|this]] release). Note the word ordering; the use of "LTS" instead of/alongside with "Marathon" is discouraged;<br />
# ''ROSA Desktop 2012'' (meaning [[ROSA Desktop 2012|this]] release).<br />
<br />
[[Category:ROSA Policy]]<br />
[[ru:Официальное именование]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=ROSA_Maintainer_QuickStart&diff=820ROSA Maintainer QuickStart2012-09-07T14:10:02Z<p>Pavel.shved: /* QuickStart Links */ added maintainer list link</p>
<hr />
<div>This page contains quick links for maintainers, developers, and advanced users of ROSA.<br />
<br />
=== QuickStart Links ===<br />
<br />
* [[ROSA Maintainer HowTo|How To Become a ROSA Maintainer]]<br />
* [[ABF_Getting_Started]]<br />
* [[Using ROSA Bugzilla#|Reporting Bugs]]<br />
* [[:Category:ROSA Developer Tools|Tools for ROSA Developers]]<br />
* [[ROSA_Mirroring_Policy|How to become an official ROSA mirror]]<br />
* [https://abf.rosalinux.ru/platforms/144/maintainers List of ROSA maintainers]<br />
<br />
=== Important Policies ===<br />
* [[Repo Policy]]<br />
* [[Submission Policy]]<br />
* [[Update Policy]]<br />
* [[Requesting an Update]]<br />
* [[Adding new package]]<br />
<br />
=== ROSA Infrastructure ===<br />
<br />
* [[ROSA Mailing Lists]]<br />
* [[:Category:ABF_Build_Environment|Build system - ABF guide]]<br />
* [http://bugs.rosalinux.ru/ Bugzilla] and [[Using ROSA Bugzilla|how to use it]]<br />
* [http://wiki.rosalab.ru/en/ Wiki] ([http://wiki.rosalab.ru/en/ English], [http://wiki.rosalab.ru/it/ Italian], [http://wiki.rosalab.ru/ru/ Russian]) and [[Using ROSA wiki|notes on its usage]]<br />
<br />
=== ROSA Development Reference ===<br />
* [[:Category:Packaging Guidelines|Packaging HowTo-s and Guidelines]]<br />
* [[:Category:Packaging_Policies|Packaging Policies]]<br />
* [[ROSA Technical Committee|Governance - ROSA Technical Committee]]<br />
* [[Current Release Schedule]]<br />
* [[Mock-urpm]]<br />
<br />
<br />
[[Category:ROSA Quick Start Docs]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=738Bugs/Workflow2012-09-03T14:10:16Z<p>Pavel.shved: </p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
By default, all bugs enter the Bugzilla in UNCONFIRMED status. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people can enter the bugs as CONFIRMED:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by [[#Whining]]).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive)<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* (optional) assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by [[#Whining]]).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by [[#Whining]])</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Technical Details ===<br />
<br />
==== Mailing Lists ====<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
==== Whining ====<br />
<br />
By '''"ensured by whining"''' we mean that unless the specified action is taken in the specified amount of time, Bugzilla will '''automatically''' send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.<br />
<br />
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Category:ROSA_Policy_Drafts&diff=737Category:ROSA Policy Drafts2012-09-03T14:02:01Z<p>Pavel.shved: Created page with "Drafts of ROSA Desktop policies should be placed to this category."</p>
<hr />
<div>Drafts of ROSA Desktop policies should be placed to this category.</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Severity&diff=736Bugs/Severity2012-09-03T13:59:35Z<p>Pavel.shved: initial version of Bugzilla workflow</p>
<hr />
<div>The following describes bug severity that should be set during the initial resolution of a bug during the [[Bugs/Workflow]].<br />
<br />
The bug severity may be changed at any time. Within this policy, the severity is left to maintainer's discretion, and the [[ROSA Technical Committee]] has a right to overrule. The severity is set to:<br />
<br />
; blocker<br />
: The error breaks the whole system or a large group of packages, makes the system non-bootable, non-updateable, causes severe user data corruption or loss.<br />
; critical<br />
: The error makes an important user package reproducibly fail to run on majority of user systems, causes user data corruption in regard of this and/or related packages, or the package fails to build from sources against the current build environment.<br />
; major<br />
: Package is not usable for most users, fails to fulfill its original purpose under most configurations, and/or contains a severe usability problem.<br />
; normal<br />
: A usual error that doesn't fall into the categories above or below.<br />
; minor<br />
: A small mistake that doesn't influence the package functionality in general, easily workaroundable issues. An error that appears on very unusual configurations<br />
; trivial<br />
: A typo in documentation or manpage or similarly trivial error.<br />
; enhancement<br />
: New functionality requests, including failures to meet user's expectations from the interface component or package functionality.<br />
<br />
Note that requests for packaging new versions fall under the specific category, ''"Package Request"'', and severity is not relevant there, and should be kept "Normal".<br />
<br />
<br />
{{message|This Policy is inspired by [http://www.altlinux.org/Bug_Severity_Policy ALT Linux Bug Severity Policy].}}<br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=735Bugs/Workflow2012-09-03T13:58:42Z<p>Pavel.shved: added refs</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
By default, all bugs enter the Bugzilla in UNCONFIRMED status. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people can enter the bugs as CONFIRMED:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by whining).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive)<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* (optional) assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by whining).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by whining)</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Mailing Lists ===<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
=== References ===<br />
<br />
<references/><br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=734Bugs/Workflow2012-09-03T13:58:03Z<p>Pavel.shved: /* Bug Triage */ on duplicates</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
By default, all bugs enter the Bugzilla in UNCONFIRMED status. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people can enter the bugs as CONFIRMED:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by whining).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive)<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* pay specific attention to whether the bug is a duplicate of another bug. See [[#Diplicates]] for policy for closing duplicates.<br />
* (optional) assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by whining).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by whining)</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Mailing Lists ===<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/AskUser&diff=733Bugs/AskUser2012-09-03T13:56:19Z<p>Pavel.shved: initial draft of Bugzilla Workflow</p>
<hr />
<div>This page lists what information a bug triager should collect from users to accomplish the Triage (see [[Bugs/Workflow]]). Until the whole information is reported by user or by other users with similar problems, the bug triage is not completed.<br />
<br />
=== All Bugs ===<br />
<br />
Architecture:<br />
<br />
uname -a<br />
<br />
Package information:<br />
<br />
rpm -qa | grep package_name<br />
<br />
=== GUI issues ===<br />
<br />
Ask user to attach screenshots.<br />
<br />
=== Hardware Issues ===<br />
<br />
If the issue is with incorrect hardware, ask for:<br />
<br />
lspcidrake<br />
<br />
=== Installation Issues ===<br />
<br />
If the issues is related to problems during the installation or inability to install, ask for:<br />
<br />
# equipment name<br />
# installation medium information (where it was downloaded from, what medium was used, and how it was created)<br />
<br />
=== Localization Issues ===<br />
<br />
Ask user to attach screenshots, and to list the locale they use.<br />
<br />
=== Networking Issues ===<br />
<br />
If it's the networking issue, and is not related to hardware failures, ask for the output of:<br />
<br />
ifconfig -a<br />
<br />
=== Package Installation Issues ===<br />
<br />
If the issue is related to package (de) installation and/or system upgrade, ask for output of:<br />
<br />
urpmq --list-media active<br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shvedhttp://wiki.rosalab.com/en/index.php?title=Bugs/Workflow&diff=732Bugs/Workflow2012-09-03T13:55:41Z<p>Pavel.shved: initial draft of Bugzilla Workflow</p>
<hr />
<div>This is a draft of Bugzilla Workflow. This is not an actual policy.<br />
<br />
=== Scope ===<br />
<br />
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product, and to all components "Desktop Features." Other categories are free and encouraged to adopt this workflow, but this is not mandatory.<br />
<br />
=== Filing a bug ===<br />
<br />
By default, all bugs enter the Bugzilla in UNCONFIRMED status. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.<br />
<br />
Several categories of people can enter the bugs as CONFIRMED:<br />
<br />
* '''ROSA Tech Support First Level''' if the bugs have been triaged in the [http://helpdesk.rosalab.ru/ helpdesk]<br />
* '''maintainers and developers—against their own packges/subsystem'''. If a developer just wants to make a task for themselves, it should be as easy as possible, and should not burden the triager.<br />
* '''Testers—when testing ISO images'''.<br />
<br />
=== Bug Triage ===<br />
<br />
Bug triage should start no later than five days since the bug was filed (ensured by whining).<br />
<br />
By ''Bug Triage'' we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:<br />
<br />
* at least one version affected by the bug (enter the latest one to the Version field, if several are affected);<br />
* steps to reproduce (triager doesn't have to reproduce, but the steps should be convincingly comprehensive)<br />
* information about the user's system and the bug symptoms. The specific commands you should ask the user to run are listed at [[Bugs/AskUser]] page (NOTE: based on Firstlevel workflow)<br />
* the problematic package RPM name (there's a specific field that should be filed), its version and release.<br />
* (optional) assign the correct product and component. See [[#Bug Categories]]. Make the best guess if unsure. If the bug ends up in the wrong category, the developer should reassign it to the proper one.<br />
<br />
When bug triage is over, the triager sets the CONFIRMED status. This is enough to notify the developers that such bug is ready to be prioritized and fixed.<br />
<br />
A triage, however may reveal some problems with the report:<br />
<br />
* The user realized that everything is OK; ensure that the status is RESOLVED INVALID;<br />
* The user found the answer in documentation after discussing it with triager. Close the bug with RESOLVED INVALID.<br />
* The user doesn't respond to the questions necessary for the triage for as much as 3 months ''since the bug was filed''. Close as RESOLVED INVALID (ensured by whining).<br />
<br />
=== Initial resolution ===<br />
<br />
So the bug is marked as CONFIRMED. The CONFIRMED status means ''the bug has been triaged, '''and''' there is no evidence that it can't be reproduced''. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.<br />
<br />
The initial analysis can lead to several results:<br />
<br />
* it is a misconfiguration problem; if it has been covered at wiki, provide a link. In any case, close the bug as RESOLVED INVALID: we do not help to configure the system, just resolve bugs in them;<br />
* if it is an upstream bug, fill the field "Upstream Status" depending on the upstream's opinion on the bug:<br />
** '''our''': we are the upstream, or we are to fix it anyway<ref>for instance, if it's a bug in our fixes to an upstream package</ref> (default state)<br />
** '''unknown''': The bug should be filed to upstream<ref>we may later have the policy of making all "unknown" to upstream bugs be transferred to "known" (ensured by whining)</ref><br />
** '''known''': upstream knows about this bug, and has plans to fix it (put a link to upsteram bug report to URL field)<br />
** '''wontfix''': the upstream doesn't know about this bug, and doesn't want/plan to fix it (put a link to such bug tickets/messages to URL field, or to the comments)<br />
: The upstream status '''has no effect''' on the status of the bug in ROSA Bugzilla. I.e. a bug that upstream doesn't want to fix '''should not be closed''', as we might want to make a workaround, or choose another upstream component for this purpose.<br />
* The bug severity is determined by the criteria described in the [[Bugs/Severity]] policy.<br />
<br />
==== Bug reproduction ====<br />
<br />
The bug ''may be'' challenged by a developer or a tester or anybody to be reproduced. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste. Until the bug reproduction attempt was made, and gained no result, the bug stays in CONFIRMED state.<br />
<br />
==== WONTFIX bugs ====<br />
<br />
Sometimes—though '''very rarely''—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.<br />
<br />
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution '''always''' originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.<br />
<br />
==== Further steps ====<br />
<br />
When the bug is unconfirmed, and its upstream status is ''unknown'' or ''our'', the bug transfers to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.<br />
<br />
=== Fixing and publishing bugs ===<br />
<br />
When a maintainer/developer decides to fix a bug, he or she does the following:<br />
<br />
* sets the status to IN_PROGRESS<br />
* sets the bug assignee to self<br />
* optionally, sets the target milestone to the release the fix should appear in.<br />
<br />
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per [[Submission Policy]].<br />
<br />
If the bug that should be in another Product/Component, change it, as per [[#Bug Categories]].<br />
<br />
=== Duplicates ===<br />
<br />
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with '''more advanced status''' to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).<br />
<br />
=== Documentation ===<br />
<br />
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.<br />
<br />
=== Bug Categories ===<br />
<br />
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):<br />
<br />
; ROSA Desktop/Main Packages<br />
: errors in packages in main, non-free and restricted repositories of ROSA Desktop and ROSA Marathon releases, including those bugs in not released products yet<br />
; ROSA Desktop/Contributed Packages<br />
: errors in packages in contrib repository of ROSA Desktop and ROSA Marathon releases<br />
; ROSA Desktop/Package Requests<br />
: Requests to build new packages for specific software.<br />
; ROSA Desktop/Localization<br />
: localization-specific bugs and tasks in supported (main, non-free, restricted) packages of ROSA Desktop/Marathon<br />
; ROSA Desktop/LXDE Edition<br />
: Bugs ''specific to'' LXDE Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; ROSA Desktop/GNOME Edition<br />
: Bugs ''specific to'' GNOME Edition of ROSA. If a bug is not specific to this edition, it should be moved to Main/Contrib packages by a developer/maintainer.<br />
; Desktop Features/All<br />
: Requests for new functionality in distribution overall that do not fall into Package Requests or bugs at all.<br />
<br />
=== Mailing Lists ===<br />
<br />
The default QA contact and assignee for new UNCONFIRMED bugs is '''triage@lists.rosalab.ru'''. Everybody who wants to participate in bug triaging should subscribe to this list.<br />
<br />
The CONFIRMED bugs will have '''bugs@lists.rosalab.ru''' as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.<br />
<br />
[[Category:ROSA Policy Drafts]]</div>Pavel.shved