We use git to maintain all code for MISP Project. We have divided the project into several components, each of which has its own separate repository. For example:
MISP code is divided into many git repositories for the following reasons:
- This creates natural boundaries between different code blocks, enforcing proper interfaces, and easing independent development to be conducted on various code parts at the same time, without the fear of running into conflicts.
- By maintaining relatively small git repositories, it is easy for new developers to understand the code and contribute new patches, without the need to understand all the other code.
- Code repositories represent also licensing boundaries. So, e.g. because misp-objects and PYMISP are maintained in two different repositories, it is possible to have the latter under a CC0 1.0 Universal license, while keeping the former under a simplified 2-BSD license.
- Version branch: This is the default branch, and it is named to reflect the latest MISP release. At the time of writing, the default branch is `2.4`
- Topic branches: We use topic branches, sometimes called `fix-*` and `feature-*`, respectively aimed at fixing a single bug and implementing a single new feature. Once ready, a topic branch is merged into the appropriate branch (generally the default branch). Until it has been merged, a topic branch's history may be rewritten.
Closed issue may have up to one resolution label, starting with `R:`. See the [list of resolution labels](https://github.com/MISP/MISP/labels?q=R%3A+) and their descriptions. When an issue does not fit into MISP's mission, we reject it by creating a comment explaining why it's being rejected, closing the issue, and the `R: wontfix` label. When an issue is closed as a duplicate, we create a comment that mentions the other, duplicated issue and add the `R: duplicate` label. If the issue is closed without one of the specific resolutions or a comment, then it means, by default, that the issue in question was fixed or the requested enhancement was implemented.
We use the Assignee field in a way that helps us organize our work as a team, focus on what matters most currently, and avoid individual over-commitment and feelings of failure.
- Parent/subtask: Issues with the `T: meta` label indicate parent issues that have subtasks under it. In the child issues, a comment will be added mentioning the parent issue.
- Related issues: Related issues can be listed either in the description or in a comment. Either way, this adds a message in the activity stream of the referenced issue, with a link to the referencing issue.
For details about labels, see [metadata](#how-we-use-github-metadata). If you are very certain to work on the issue, leave a comment expressing your interest or ask to be assigned to it to avoid duplicate work.
All the knowledge useful to the others should be kept on that issue, or at least linked from there.
When committing changes that will resolve an issue once merged, please include #NNNN in the commit message, NNNN being the issue number. Then, GitHub will automatically reference this commit on the corresponding issue, once the branch is pushed to our Git repository. For example:
```
chg: [doc] Fix spelling errors (#3120)
```
### Report progress or failure
It is important to:
- Keep the team informed of how you feel committed to issues assigned to you, and about the timeline you're envisioning.
- Avoid individual over-commitment & feelings of failure.
- Once you would like your branch to be reviewed, and possibly merged, submit it by creating a pull request (PR). In this new PR, use the description field to summarize what problem this PR will fix, in terms of impact on users, and reference the issues this PR will solve, e.g "Closes #xxx, #yyyy".
Follow these conventions when submitting changes to any MISP Project repository:
- Submit one pull request (PR) per fix/feature/change. Don't split one feature into multiple PRs. Similarly, do not join several fixes and features into one pull request.
- Keep the number of commits per PR as small as possible. If for any reason, you need to fix your commit after the pull request, please squash the changes in one single commit (or tell us why not).
If you need input from someone else on an issue or pull request, ask your question in a comment there, mentioning them with their GitHub login name: @nick. If you want to raise the attention of every single member of a team, mention it with the name of the corresponding group: @xyz-team. GitHub will send them an email notification about it.
When you receive such a request, if you cannot provide the requested input immediately, you're responsible for keeping track of this task. For example, by creating a new issue assigned to yourself, or using whatever personal organization tools work for you.
MISP core uses CodeQL and LGTM for some code analysis and security checks. When you submit a PR, consider the results of checks. Also, ensure that your code builds without errors.
For example, you will need "Triage" access to add labels or assign issues. See [GitHub's access permissions documentation](https://docs.github.com/en/github/getting-started-with-github/access-permissions-on-github).