Re: [escet-dev] GitLab

[Dennis Hendriks <dh_tue@xxxxxxxxxxx>]

Hi all,

Regarding 'issue tags'. We already have a number of predefined 'issue labels' as GitLab calls them. See https://gitlab.eclipse.org/eclipse/escet/escet/-/labels. Do we see the need for other labels?

I propose to start with what we're given. Should we need another label, we can start a separate discussion about that label and add it if we agree it is valuable.

Dennis

---

Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: maandag 19 oktober 2020 13:02
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: [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