Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • stork stork
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 320
    • Issues 320
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 22
    • Merge requests 22
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • storkstork
  • Wiki
  • Processes
  • gitlab howto

gitlab howto · Changes

Page history
spell checks, corrected URLs authored Apr 01, 2021 by Andrei Pavel's avatar Andrei Pavel
Hide whitespace changes
Inline Side-by-side
Processes/gitlab-howto.md
View page @ 37ad1a2d
......@@ -26,7 +26,7 @@ cd stork
# Working on an issue
- Once you start working on an issue, assign the issue to yourself. You should also assign Doing label. There are two ways of doing that. First, you can add the label manually when browsing an issue. Alternatively, you can go to https://gitlab.isc.org/isc-projects/stork/boards and drag and drop your issue to appropriate stage.
- Once you start working on an issue, assign the issue to yourself. You should also assign Doing label. There are two ways of doing that. First, you can add the label manually when browsing an issue. Alternatively, you can go to https://gitlab.isc.org/isc-projects/stork/boards and drag and drop your issue to appropriate stage.
- Open the issue page, e.g. https://gitlab.isc.org/isc-projects/stork/issues/3 and click create a MR. A good trick is to click on the triangle button to get the extended create MR menu. In particular, you can use a shorter branch name. The branch name MUST start with the issue number.
......@@ -76,7 +76,7 @@ Commit logs should be descriptive. They are addressed at developers, so code fam
Since we sometimes get code from places outside of our control (MRs on gitlab, PRs on github), we cannot assume the [#Issue number] information will always be available.
We don't do commit squashes in general. Sometimes the reviewer pushes fixes or we get commits from contributors (it's essential to get those preserved. Users being able to point to their code and brag about it is one of the reasons they submit patches).
We don't do commit squashes in general. Sometimes the reviewer pushes fixes or we get commits from contributors (it's essential to get those preserved. Users being able to point to their code and brag about it is one of the reasons they submit patches).
If you really like to, you can squash your own commits. Nobody in the Kea team did that.
......@@ -117,7 +117,7 @@ This is just a proposal. Tomek's idea was to use dark colors for important thing
# Reopens
The usual issue life cycle is as follows: opened by a reporter, a dev looks at the problem and comes up with some code or doc changes, which are later reviewed. If reporter is part of ISC team, he/she is often also a reviewer, but these two roles in principles are different. Once reviewer and dev agree that the code is ready, the change is merged and ticket is closed. However, this process has one flaw: it doesn't take into consideration whether the proposed fix actually addressed the problem raised by the original reporter.
The usual issue life cycle is as follows: opened by a reporter, a dev looks at the problem and comes up with some code or doc changes, which are later reviewed. If reporter is part of ISC team, he/she is often also a reviewer, but these two roles in principles are different. Once reviewer and dev agree that the code is ready, the change is merged and ticket is closed. However, this process has one flaw: it doesn't take into consideration whether the proposed fix actually addressed the problem raised by the original reporter.
The alternative - to ask for confirmation that the original problem is addressed - has many flaws. The reporter may not be skilled enough to know how to pull a branch from git, may be unwilling or unable to compile it or more likely be simply unresponsive. This would leave us with many tickets stuck in almost-done state. So we chose to use the approach of merging and closing, with reopen as an escape clause. If the reporter didn't confirm that the fix working, it's good to add something like "We think this should fix the original problem. If it doesn't work or you disagree with the solution, please reopen". This covers 99% of the cases. The text below discusses the remaining 1%.
......@@ -131,4 +131,3 @@ There's the scenario: Someone reports a problem, we look at it, come up with a s
There may be other reasons. In all cases the major point is that the original problem remains unsolved and there is more to be done here. What should be done in such cases? **You can only close a ticket once**. If there's a reopen, a third person needs to get involved and independently confirm that the solution is valid and complete. This is kind of natural extension of the process we have for review where if dev and reviewer cannot reach an agreement, they ask for a third opinion. Feel free to ask the third person depending on the situation - a dev that's expert in the area, maybe someone from QA or get a manager involved.
In any case, closing a ticket that was reopened can easily be considered as rude behavior and can damage the public image of the whole project. If there's really nothing reasonable to be done in the short term, perhaps moving to %Outstanding is a good alternative to closing?
Clone repository
  • Demo
  • Hook To Do List
  • Ideas
  • Install Prometheus Grafana
  • Install
  • Known issues
  • Processes
    • coding guidelines
    • development environment
    • gitlab howto
  • Releases
    • Release notes 0.1
    • Release notes 0.10
    • Release notes 0.11
    • Release notes 0.12
    • Release notes 0.13
View All Pages