Re: [escet-dev] GitLab

["Hofkamp, A.T." <A.T.Hofkamp@xxxxxx>]

> 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?

Got lost in ESCET group instead of the project (why do different things have the same name??!!), which has an empty set of labels.

Looking at the list above, I am not too impressed by it.

"Bug" and "Enhancement" seem fine.

"Community Contribution" and "Help Wanted" I can live with, although not sure of the use.

"Confirmed" seems like a useful thing at least for bugs, not sure if we'd ever use that for anything else.

There is also the notion "Reproducable" for bugs, not sure if "Confirmed" includes that.

"High Priority" and "important" are equivalent as far as I can see. Either has questionable use I think, when is a bug not important or low priority?

"work in progress" seems a bit fuzzy, are there issues which are not work in progress? The ultimate goal is to have an empty list of issues, I think.

"documentation" seems off, it may come from the idea that documentation is weird or not important or so, which is not how we work. At least to me code and documentation are equally important at least (and perhaps docs are even more important!)

------

So, I would propose to keep Bug and Enhancement. We may also want a FeatureRequest for all the "please implement X" issues.

The only other kind of issues I can think of are "Release" issues and "general discussion/ideas about a topic" things.

The former needs a somewhat more generic name perhaps, for all "work needed which is not a bug or enhancement" since we make an issue for everything (not only release, but also build infra-structure, CI, website/etc, ie "other" 🙂 ). The "general discussions/ideas" can fit in the Epic thing.

"Community Contribution", "Help wanted", and "Confirmed" seem fine, where the latter should probably imply "reproducable"

For "High Priority" or "important" I see no use, possibly also due to the next item.

"work in progress" I propose to drop. Instead make a milestone "future", and attach everything that we deem worthy of doing at some point.

Also, make a milestone for the next release (or even just "next-release" if we don't have a number) for things we want to actually work on.

My guess is that we are well aware of what is important, so having labels for it isn't useful imho.

"documentation" shouldn't be treated as special imho, I propose to drop it. code and docs are equally important, they go hand-in-hand.

We may want to add a few labels for the parts, ie "common", "cif", "chi", "tooldef", "setext". This is not complete, eg build related things are missing. Also, "cif" may be not too useful, as most issues will have that so it can be a default by not labeling it.

---

From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, October 19, 2020 15:58
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: Re: [escet-dev] GitLab

 

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