Difference between revisions of "Guidelines/Phabricator"

From Apertis
Jump to: navigation, search
(Bugs: add note about architecture and platform tags)
(Add a link to the new bug form)
Line 7: Line 7:
 
These are the recommended guidelines for filing good bug reports in Phabricator. They are specific (but not limited) to testing issues:
 
These are the recommended guidelines for filing good bug reports in Phabricator. They are specific (but not limited) to testing issues:
  
* Please use the new bug form in Phabricator to file bugs issues. There is a form for every Apertis release, and it contains predefined values to produce clear bug reports. This form can be found in the maniphest <code>Create Task</code> menu, as <code>New Bug (VERSION)</code>.  
+
* Please use the [https://phabricator.apertis.org/maniphest/task/edit/form/8/ new bug form] in Phabricator to file bugs issues. There is a form for every Apertis release, and it contains predefined values to produce clear bug reports. This form can be found in the maniphest <code>Create Task</code> menu, as <code>New Bug (VERSION)</code>.  
 
* For test-related bug issues, leave the '''Assignee''' field blank, as the bug will be assigned to an appropriate person by the QA team.
 
* For test-related bug issues, leave the '''Assignee''' field blank, as the bug will be assigned to an appropriate person by the QA team.
 
* Add the bug issue to a test case project using the specific test case tag. Test cases tags start with a <code>test:</code> prefix followed by the specific test case name, for example, the [[QA/Test_Cases/image-bootable|image-bootable]] test case has the tag name <code>test:image-bootable</code>. These tags help to group and keep track of issues by test cases. If there is a test case with no test case tag, please request the Collabora QA team to create one.
 
* Add the bug issue to a test case project using the specific test case tag. Test cases tags start with a <code>test:</code> prefix followed by the specific test case name, for example, the [[QA/Test_Cases/image-bootable|image-bootable]] test case has the tag name <code>test:image-bootable</code>. These tags help to group and keep track of issues by test cases. If there is a test case with no test case tag, please request the Collabora QA team to create one.

Revision as of 14:19, 8 November 2016

Phabricator is the tasks management tool used by the Apertis project. This page contains the guidelines for the Phabricator workflow used in Apertis.

For help on how to use Phabricator, see the Application User Guides.

Bugs

These are the recommended guidelines for filing good bug reports in Phabricator. They are specific (but not limited) to testing issues:

  • Please use the new bug form in Phabricator to file bugs issues. There is a form for every Apertis release, and it contains predefined values to produce clear bug reports. This form can be found in the maniphest Create Task menu, as New Bug (VERSION).
  • For test-related bug issues, leave the Assignee field blank, as the bug will be assigned to an appropriate person by the QA team.
  • Add the bug issue to a test case project using the specific test case tag. Test cases tags start with a test: prefix followed by the specific test case name, for example, the image-bootable test case has the tag name test:image-bootable. These tags help to group and keep track of issues by test cases. If there is a test case with no test case tag, please request the Collabora QA team to create one.
  • If a task require further information, either from RBEI or Collabora, it should be set to Need Info and re-assigned as appropriate.
  • The task is assigned to a private space by default using the Apertis bug form, unless you are completely sure that the task can be made public, please keep it in the default private space.

Please follow these instructions to fill a bug form:

  • Title: Be precise and concise.
  • Assigned To: It can be left unassigned unless someone has offered to fix it already.
  • Status: Set to Unconfirmed until it is verified by a second person.
  • Priority: It can be left as Needs Triage, but crashers reports can be set to High or Highest at once.
  • Description:
    • List all image versions that you have tested against. It is best to paste the full file name of the image as that contains architecture, date and version of the image.
    • Be explicit and clear in the steps that are needed to reproduce the bug. There is no such thing as too much detail in a bug report, and you should include steps which may seem obvious to you. You may want to list the commands that you run and any UI buttons that you press, as well as any settings that you change. If the steps are exactly the same from a test case, you can just add the test case link.
    • Explain the actual result. This can include pasting any error output, if that is the case, please paste the output between <code></code> labels.
    • Describe what it is expected to happen.
    • Attach any backtrace or log output. If you do not attach any, you may be asked for one if it is not possible to reproduce the issue, which can mean longer time to process the bug.
  • Tags: Leave the Apertis (<release>) tag, and add any project and test tags that are relevant. For example, if you are running the webkit-1 test on the web browser, you should add rhayader and test:webkit-1 tags. You should also use platform: and architecture: tags to specify which images you tested for the bug.
  • Subscribers: There will be some subscribers listed by default: DO NOT remove these as those are people who will help triage the bugs or have an interest in finding out about new bug reports.

Enhancements

The default Phabricator form from the menu Create Task -> New Task can be used to file enhancement requests. Please follow these instructions to fill an enhancement form:

  • Title: The title should be specific and reflect that it is a new proposed feature if possible.
  • Assigned To: It can be left unassigned unless you know beforehand who will work in the new feature.
  • Status: Leave Unconfirmed until it is verified by a developer.
  • Priority: It can be left as Needs Triage or set to Enhancement.
  • Description: Explain what the feature should do and why it is important to you or other users. Attach here any relevant documentation or links (if any) that can help to justify such a new enhancement.

What happens next?

After you have filed your enhancement request, it will be reviewed by one or more developers. They may have further questions for you, may close the request as invalid or confirm that it is valid.

Release tracking

You can check the upcoming release deadlines in Phabricator's Countdown: https://phabricator.apertis.org/countdown/

Patch review

  • If you have a proposed fix for a task, submit the diff for review through Phabricator's Differential and associate the patch Revision with the Task ID for the bug.
  • Helper tools such as git-phab and arcanist (arc) are recommended to create and manage Revisions from the command line.
  • Make sure that all the patches are properly formatted and signed off before you push them.
  • Please visit the Contribution process guidelines to know in more detail the steps to contribute code.

Code audits

In the rare case that code which has been pushed to a repository needs further review, the review can be initiated through Phabricator's Audit. In most cases, you should be using Differential for pre-commit reviews rather than Audit.