Guidelines/Phabricator

From Apertis
Jump to: navigation, search

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.

Contents

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.

Patch review

  • 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.

Priority

  • Highest - critical business impacting - stops eCore build, stop customer project, major security fix. Put aside any current tasks and *immediately* switch to this task
  • High - business impacting, negatively impacts customer project or an eCore build. Pick up as soon as the current task is completed or blocked
  • Normal - Most stuff, life as usual
  • Low - feature or nice to have bugs that can be delayed until later in the project, tidy up exercises. Pick up if nothing else is scheduled and PM/PL/TL are unreachable
  • Lowest - feature nice to have – lets face it these will not be done for a long time. Keep in consideration, but never pick those up

Task status

Usually, the task status will flow across the following values from top to bottom:

  • Unconfirmed - for a new bug, when it is created, or for a new task, before it is accepted
  • Confirmed - for a new bug, after it has been verified by a second person, or for a new task, after it has been accepted
  • In progress - set by the developer when effective work starts on a task
  • Proposed - set by the developer when something is pushed for review. Add a link to the place where the review is happening (gitlab, github, phab, ...)
  • Submitted - set by the developer when all the work for a task has been accepted by maintainers, and before it is available in an image
  • Upstream - set by the developer if a work is waiting for upstream activity
  • Need info - set by the developer if more info is requested from QA or 3rd party (reproducibility on other platforms, additional logs, ...)
  • Resolved - set by the developer after an image containing the work is published, or when the code is deployed in production

The following tasks status can be considered definitive. But a task may be reopened.

  • Verified - set by QA after they verified the task was properly implemented and is functional
  • Wont fix - set by pm or tech lead if an issue is known or admitted but fixing is not necessary
  • Invalid - set by pm or tech lead if a task purpose does not make sense, or if it was a mistake
  • Closed - set by pm or tech lead, closing a task for any other reason
Personal tools
Namespaces

Variants
Actions
Navigation
Tools