development_workflow

Page author: @gregkub @cmoineau

General dev workflow

📰 Create an issue

⁉️ Is there something that bothers you and you think needs to be done in the project ? Create an issue about it :

As an external

Open an issue and change Description template to User-Request. Fill the template describing the issue

As a developer

1. Go to the Issue board of the project
2. Check if a similar issue doesn't already exists in the open issues of the board.
3. Create an issue in the right column.
   • OPEN There is no hurry to fill this issue.
   • status::TODO : It needs to be done during current sprint.
   • status::WIP : You need to start directly to work on this issue.

⚠️ In the 2 latter cases also set the milestone to current sprint.

4. Attribute the issue to the designated dev (usually yourself) if you know whose job it is already.
5. Detail the issue created : Specification, code sample test to add, todo list (=child issue/items)

🛠️ Start working on an issue

1. Create a local branch with a specific prefix to its name :
   • fix_... is the branch/the issue is a malfunction to repair.
   • chore_... if the issue is a minor such as updating a dependency or reformatting code.
   • feat_... if the issue is about a new feature or a refactor.
2. Once you have pushed your 1st commit, you can create an associated Merge Request(MR) to your branch. Since the (in MR title add Draft: <MR title> or check the draft checkbox when creating/editing)
3. Mention the issue associated in the merge request description. This will have as consequence that all the MR associated to an issue will be shown on the issue page. This allows to track the evolution of the progress on a given issue.
4. When the MR is ready remove the part Draft : from the title. This allows the reviewers to know when they can review the code.

⁉️ What happens when an MR is no longer in Draft

1. [The branch pulled will be from the target branch of the depedencies, if you haven't merge associated work in dependencies, the pipeline mght fail then.](https://gitlab.eclipse.org/groups/eclipse/aidge/-/wikis/Understand%20the%20CI%20CD%20Pipelines#case-2\]
2. New jobs will be launched at every pipeline, such as building the project with other additionnal compilers. These jobs can be triggered manually otherwise but are required to run on a non draft pipeline.

4. When MRs in your issue are ready for review. Move the issue from the column status::WIP to status::Review Ready.
5. Review process
6. Merge MR
7. When every MR is merged, close issue

❗ Make sure to close every child issue before closing the main issue

Global workflow

• For each release, create a Milestone
• Add list of things to do
• Create related issues and assign dev
• Each week check issue board
• Week before dead line, create changelog
• Release 🚀

Handling of ticket issues

Ticket issues are issues related to a bug.

• The issue must be created with no status tag
• During a weekly these issues are ranked by priority by the dev team
• Some issues will be assigned depending on the passign band of the team, this is symbolized by adding the label ```status::TODO``.
• Check General dev workflow for the next steps !

How to set labels

Label are not set for Merge Request, only for Issues !

• status: these labels help to sort
  • TODO: issue need to be treated
  • WIP: issue has been assigned and break down in to actions, a dev is working on it !
  • Review ready: MR fixing the issue have been done and need to be reviewed
• Discussion: issue with this label are here to propose modification/new features

Incoming ...

Using issue board

Aidge project manage development using the GitLab issue system.

You can find the issue board here: https://gitlab.eclipse.org/groups/eclipse/aidge/-/boards/3169

There are multiple issue boards:

• Development: Show issues sorted by status
• Discussions: Show issues requiring a discussion