... | ... | @@ -20,7 +20,7 @@ cd kea |
|
|
|
|
|
# Adding an issue
|
|
|
|
|
|
- If you have something new to work on, create an issue in gitlab: go to https://gitlab.isc.org/isc-projects/kea. Make sure it's not assigned to any project, unless you discussed this with the project manager and he is ok with adding it directly to the current milestone. We have a process to triage unassigned tickets weekly and assign them to specific milestone.
|
|
|
- If you have something new to work on, create an issue in gitlab: go to https://gitlab.isc.org/isc-projects/kea. Make sure it's not assigned to any milestone, unless you discussed this with the project manager and he is ok with adding it directly to the current milestone. We have a process to triage unassigned tickets weekly and assign them to specific milestone.
|
|
|
|
|
|
# Working on an issue
|
|
|
|
... | ... | @@ -64,8 +64,6 @@ git rebase --skip # if there are specific commits that you decided to skip, e.g. |
|
|
|
|
|
- Once you push your changes to master, gitlab should close the merge request and the ticket.
|
|
|
|
|
|
- Don't forget to update the commit-id in ChangeLog. Use MR (Merge Request) number, not issue number. The reason for this is that there may be multiple MRs for one issue. Also, in case we import pull requests from github, there may be no issue at all.
|
|
|
|
|
|
**PROCESS CHANGE**: We previously (before Oct 2019) put three things in the Changelog: Gitlab issue number, MR number and sha of the commit-id. This uniquely identified the changes, but was annoying and it was difficult to automate (in principle it could be done, but you'd have to develop a script that would use gitlab API to retrieve the MR #). After discussion with several members of the team, I propose to put only issue #. All other details are available using GL web interface.
|
|
|
|
|
|
# GIT commit logs
|
... | ... | |