|
> I suggest the following for milestones: [...]
> I suggest the following for issues: [...]
> For commits: [...]
Any thoughts on this?
For issues, I also propose:
- Unassigned
issues can be picked up.
- Assign yourself when you are working on an issue, such
that others won't start working on it as well.
- Unassign yourself if you are no longer working on it,
don't plan to continue, and the issue is not finished.
- Don't unassign yourself after finishing the work, just
close the issue.
Dennis
Van: Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: maandag 19 oktober 2020 13:02
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: GitLab
Hi all,
In another discussion, Albert mentioned:
> [...] should we discuss gitlab configuration?
> Issue tags and milestones at least I think, and probably branch usage/names/conventions?
> [...]
> In general, I think less is more here.
I suggest the following for milestones:
- Create a milestone for every release. I created one for Release 0.1.
- Associate every issue with the release milestone where we fix/address it. This way, we have an overview for the release log for a release. Also, we see what work is still planned
for a release.
We have both epics and milestones. Both seem to group issues. Epics seem to be meant to group by functionality while milestones seem more focussed on what you address/finish/release
together. You could thus have funcionality in an epic that you release partly as part of one milestone and the rest as part of a next milestone. Maybe if we later have releases with multiple topics (groups of functionality) epics may become handy as well.
I suggest the following for issues:
- Create an issue for everything that we work on.
- Keep issues relatively small. This keeps merging easier as we will merge often. Also, it makes reviewing easier, as it will not be too much code.
- Always work in a branch for the issue.
- Let GitLab create the branch for the issue. For an issue with number #2 named 'Test', it will create a branch named '2-test'. So that includes the issue number.
- Adopt GitFlow, see https://datasift.github.io/gitflow/IntroducingGitFlow.html
For commits:
- The first line must be a short single line summary of max 72 characters I think, as is the Git standard.
- Prefix the first line with the issue number, e.g. '#1 commit summary', to link the commit to the issue.
- Adhere to Eclipse requirements, see https://www.eclipse.org/projects/handbook/#resources-commit
These are my first thoughts. Let me know what you think about them and whether you have other ideas.
Dennis
|
