Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [escet-dev] GitLab
  • From: "Hofkamp, A.T." <A.T.Hofkamp@xxxxxx>
  • Date: Thu, 22 Oct 2020 14:16:35 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=tue.nl; dmarc=pass action=none header.from=tue.nl; dkim=pass header.d=tue.nl; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YYbzNbo+vjx4BKVLyt7XSDCt0qIh5BbmOG4mPWGD4HM=; b=fX/lpUk7tyalw7K0pvVv4+UmUqsIfemamrAcxwNwrUQg64FAdsQ2PMIDcCoY2qEr7a6675f2e7/kqXYd2g+FmpSK60gQNotj+anqfZnO9MeNeiU4Jhm5sLQ1cH9+zrIbmmySjZrDHZB/Wi3ddgP9NPsBGBKnG+0SV2XiwDDlE9HRFtw/jZdRiG9SLvgb/5FY/mOc8zgzpQuYneramab5dwPJNzj62r3qBDwKLGxvEAeq9enZ3rTpHl337/UHG7QdKDBKjfmHZhIpaHdCB0fkVepmUuQevBuGI1lMwSVAsKhODR3Ek9eIcY6vB812bPEM5Qc4kNS5cYvpKE0tx4rJ+A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MHxiAdwxdJqmK/WlcLykq4kDhkqM/S95BZ+fA9YZwDNhnzZgRE8ffwgqIFATWtesNtFWRR5Kof7+PP6drVstpG1hGcMLFXsBX3xvG0bARpY9fjamZCgeTUL/Zok8v1XPfcOa0v3cWu2+Swut/kKiWIY0j5ccjqKvPNQcPgpHSj6TFfeRvTia1bUwHCCTiw6lY2V+EDDlW2RpzMA97xrWkUagflFat3zbPnXgFX1NJweP4K+lHif3ZXoj8H7gQ7GvqhB405s9wLpy/fHVCNAEVpftm3dzxYvkDuk9h9K6RvSHxtCn+4GAz7Ayms2dcAi4KFhJtZgQ2FV25FM5NO6nZQ==
  • Delivered-to: escet-dev@xxxxxxxxxxx
  • List-archive: <https://dev.eclipse.org/mailman/private/escet-dev>
  • List-help: <mailto:escet-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://dev.eclipse.org/mailman/listinfo/escet-dev>, <mailto:escet-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://dev.eclipse.org/mailman/options/escet-dev>, <mailto:escet-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHWpgT6jU6rPm4x7ke4VpYc/JI6ramjPbdLgABx25w=
  • Thread-topic: GitLab
> For issues, I also propose [..]   assign self, etc

Issues and assigning self looks fine to me too.
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Thursday, October 22, 2020 09:33
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: 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