|
|
|
**Page author:** @gregkub @cmoineau
|
|
|
|
|
|
|
|
## General dev workflow
|
|
|
|
### :newspaper: Create an issue
|
|
|
|
:interrobang: Is there something that bothers you and you think needs to be done in the project ?
|
|
|
|
Create an issue about it :
|
|
|
|
1. Go to the [Issue board of the project](https://gitlab.eclipse.org/groups/eclipse/aidge/-/boards/3169)
|
|
|
|
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.
|
|
|
|
> :warning: 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)
|
|
|
|
|
|
|
|
### :tools: 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.
|
|
|
|
* `refactor/...` if the issue is about a refactoring.
|
|
|
|
* `feat/...` if the issue is about a new feature.
|
|
|
|
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.
|
|
|
|
3. When the MR is ready remove the part `Draft :` from the title. This allows the reviewers to know when they can review the code.
|
|
|
|
> :interrobang: **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
|
|
|
|
> :exclamation: 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 :rocket:
|
|
|
|
|
|
|
|
## 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 developpement using the GitLab issue system.
|
|
|
|
|
|
|
|
You can find the issue board here: https://gitlab.eclipse.org/groups/eclipse/aidge/-/boards/3169
|
|
|
|
|
|
|
|
There are mulitple issue boards:
|
|
|
|
* Development: Show issues sorted by status
|
|
|
|
* Discussions: Show issues requiring a discussion |
|
|
|
**Page author:** @gregkub @cmoineau
|
|
|
|
|
|
|
|
## General dev workflow
|
|
|
|
|
|
|
|
### :newspaper: Create an issue
|
|
|
|
|
|
|
|
:interrobang: Is there something that bothers you and you think needs to be done in the project ? Create an issue about it :
|
|
|
|
|
|
|
|
1. Go to the [Issue board of the project](https://gitlab.eclipse.org/groups/eclipse/aidge/-/boards/3169)
|
|
|
|
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.
|
|
|
|
|
|
|
|
> :warning: 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)
|
|
|
|
|
|
|
|
### :tools: 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.
|
|
|
|
* `refactor_...` if the issue is about a refactoring.
|
|
|
|
* `feat_...` if the issue is about a new feature.
|
|
|
|
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.
|
|
|
|
|
|
|
|
> :interrobang: **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
|
|
|
|
|
|
|
|
> :exclamation: 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 :rocket:
|
|
|
|
|
|
|
|
## 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 developpement using the GitLab issue system.
|
|
|
|
|
|
|
|
You can find the issue board here: https://gitlab.eclipse.org/groups/eclipse/aidge/-/boards/3169
|
|
|
|
|
|
|
|
There are mulitple issue boards:
|
|
|
|
|
|
|
|
* Development: Show issues sorted by status
|
|
|
|
* Discussions: Show issues requiring a discussion |
|
|
\ No newline at end of file |
