|
> I suggest the following for milestones:
Seems fine.
Epics are indeed topic oriented as far as I know. Mostly anything bigger than a few issues, where you need an overview
ticket about purpose, plans, and progress. Never worked with proper Epics though, until now I just used a ticket labeled "[epic] <topic>".
>
I suggest the following for issues:
Not many surprises, 2 points:
- "... it will create a branch named '2-test'." The numeric prefix breaks auto-completion at the command-line, since at the same point you can also use
a commit hash, and there are a zillion commits that start with a 2. If you type "2-", autocompletion works, but we'll soon have more than 10 or 100 issues. As such, I'd prefer the issue number at the end, don't know if that's possible.
- Gitflow will likely do all we want, the one problem I have with it is that it breaks standard git semantics of "master". For no good reason, they renamed "master" to "develop", and renamed "releases" to "master" to confuse everybody. Why?
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, October 19, 2020 13:02
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: [escet-dev] 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
|
