... | ... | @@ -61,7 +61,7 @@ When migrating stuff between repos, DO NOT copy files over. Use cherry-pick inst |
|
|
|
|
|
- Commit your changes, push it on that branch.
|
|
|
|
|
|
- Once you are done, do the following: unassign yourself from the issue and merge request, remove "doing" label, add "review" label. Open the merge request, edit it and click on "remove WIP status".
|
|
|
- Once you are done, do the following: unassign yourself from the issue and MR, remove "doing" label, add "review" label. This indicates the MR is ready for a review.
|
|
|
|
|
|
# Reviewing an issue
|
|
|
|
... | ... | @@ -69,9 +69,11 @@ When migrating stuff between repos, DO NOT copy files over. Use cherry-pick inst |
|
|
|
|
|
- as a developer: look for issues that are assigned to you. Do your best with addressing the comments. Push your improvements to the branch. Once done reassign back to the reviewer. Do not merge until the reviewer says the code is ready.
|
|
|
|
|
|
- as a reviewer: Once all your comments are addressed, put a note that the code is ready to merge, open the MR, edit it and click on "remove WIP status". Removal of the WIP status is a clear indication the code is ready to go.
|
|
|
|
|
|
# Merging code
|
|
|
|
|
|
- Kea project is currently set up in a way that allows only fast-forward merges. This is not the only possible option, it's just something Tomek feels is the right way to go. It keeps the repo history much cleaner. If you complain about tons of merge conflicts, you tried to push a ticket that was too big.
|
|
|
- Kea project is currently set up in a way that allows only fast-forward merges. This is not the only possible option, it looks like the right way to go. It keeps the repo history much cleaner. If you complain about tons of merge conflicts, you tried to push a ticket that was too big.
|
|
|
|
|
|
- Currently we don't have any CI integrated with gitlab. Before merging, please run unit-tests as we did in the trac days.
|
|
|
|
... | ... | |