Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [escet-dev] GitLab
> For issues, I also propose: [...]

Note that GitLab also tracks per milestone the unstarted/ongoing/completed issues based on whether someone is assigned and whether the issue is open/closed. See https://gitlab.eclipse.org/eclipse/escet/escet/-/milestones/1.

This seems to mostly match with what I proposed. The only thing is that if you have done work on an issue and unassign yourself, it will be listed as 'unstarted' even though it is 'ongoing'. But that is minor I think, as we'll probably assign ourselves and keep working on it until it is finished for the milestone, never unassigning ourselves. In that sense we can read the columns as 'should be picked up', 'has been picked up' and 'completed', rather than 'unstarted', 'ongoing' and 'completed'.

Dennis

Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: donderdag 22 oktober 2020 09:33
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] GitLab
 
> 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

Back to the top