Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
fusiondirectory
fusiondirectory
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 49
    • Issues 49
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • fusiondirectory
  • fusiondirectoryfusiondirectory
  • Wiki
  • HowToManageLabels

Last edited by bmortier Feb 12, 2020
Page history

HowToManageLabels

New ticket opened

First the label of the dolibarr project should be added to it.

The dolibarr label are made like this :

  • PJYYYY-project number

We have some basic project number that should always be used by default if there is no customer project.

  • FusionDirectory / Automated Testing / FusionDirectory demo : PJ1802-0188

  • Argonaut : PJ1802-0190

  • Packaging Debian / Redhat / Scientific Linux: PJ1802-0189

Second the component where the bug/enhancement is to be made should be specified

  • Example : fusiondirectory-core or plugin-xxx

! It could be several component !

Third if this is a customer under contract the level of support should be added also

  • Example : silver

Ticket as been treated

if some code has been commited and need to be tested

  • The bug label should be removed if it was present, but label like enhancement are kept.

  • The to be tested label should be added

if some more info is needed to act on the report

  • The need info label should be added, don't hesitate to ping the user reporting the bug with @(useranme) to ask him to check it out

If the change need to be cherry-picked in a -fixes version

  • The fixes label is added, when the cherry-pick as been merged we remove the fixes and add the fixes-merged label

if the change need a change in packaging

  • The packaging label is added and a corresponding ticket is open in the corresponding https://gitlab.fusiondirectory.org/debian and https://gitlab.fusiondirectory.org/redhat project.

  • The numbers of packaging tickets are put back into the ticket

The bug is closed

  • Remove the to be tested label, and add one of the changelog label to specify what has been done.

    • Added
    • Changed
    • Deprecated
    • Fixed
    • Removed
    • Security

Those label are used to generate a changelog when we release a new version of the software, and also used when we want to search in which version something has been changed and what the type of change it was

Clone repository
  • CompleteWorkflowTicket
  • Create Official Debian Packages
  • Create Official RPM Packages
  • CreateOfficialDebian Packages
  • FallbackNonDefaultBranch
  • Fixes Branch Packages
  • FusionDirectory13
  • Fusiondirectory14
  • How make an MR from an external gitlab MR
  • HowToManageLabels
  • HowToManageLabelsPackaging
  • HowToTellPackagers
  • MakeAnMRFromGithubPR
  • New The fixes Branch
  • Release Adapting Test
View All Pages