Community Feedback

Issues raised by the GNOME community in response to the GitLab migration proposal. The full thread can be seen on the desktop-devel-list archive.

Priority issues are in bold.

Issue tracking

Although it might be a result of peoples' impressions from GitHub, issue tracking is the area that developers are most concerned about. Issues raised:

• Dependencies between issues, so some issues can block others from being closed

  • There is an open issue for this; until it's fixed, there's sort of a way to do it

• Ability to mark duplicates

  • There is a manual way to do this, and this is actually in the same upstream report as dependencies between issues, here.

• Comments disappear after force push; this is part of our regular workflow of review and fast-forward merge

  • Current issue and old issue

• Tracking tasks that don't belong to a Git repository; we currently use Bugzilla to track account requests, for example'

  • This could be done by creating a repository containing just a readme, but it's not particularly elegant

• Assignment of issues to sub-components within modules (Bugzilla requires that each bug is assigned to a component. This is important for modules that have distinct sub-components like gnome-control-center or gnome-documents.) (BastienNocera)

  • Labels could be used for this; however, you can't require that one of a particular set of labels has to be used and labels are free-form

• What is the equivalent to NEEDINFO? (In Bugzilla, NEEDINFO is used to mark incomplete bugs, or bugs that need more information in order to be fixed. NEEDINFO bugs are automatically filtered out when searching or listing the bugs for a project.) (BastienNocera)

  • We could setup a "needs info" or "missing info" label for all projects; it's not clear whether it is possible to filter out based on labels (it is possible to make some labels high priority though)
  • Using a confirmed label could help with this situation - confirmed is a priority label, so confirmed issues get shown first; you can also filter by it

• Is it possible to have a denser view of the issue list, similar to Bugzilla? (TristanVanBerkom)

  • Probably not, but we could ask

• "Real attachments" - immutable copies of files kept with issues, so they can be referenced later (TristanVanBerkom)

  • You can attach any file to issues.

• Granular control over email notifications (TristanVanBerkom)

  • Go to your profile -> setting -> notifications. If you want really granular, choose "custom".

• How to generate email notifications for the documentation team? (ShaunMcCance)

  • It is possible to subscribe to labels in GitLab. Perhaps an account could be made that is registered to the documentation team mailing list, which is then subscribed to a documentation label?

• How to generate email notifications for the translation teams? Currently there is a generic localization product where translation issues can be reported. This contains components for each language; this allows the members of each translation team to subscribe to bugs for their language. This is far from ideal, since bugs relating to a particular module aren't filed against that module, but against localization.
  • Ideally it would be possible to label any translation issue with a particular language, in order to subscribe the relevant translation team. However, it isn't clear how that could be done. One idea is to have a label per each language, but we would have an explosion of labels, so probably we would need sublabels.

• Mail notifications for issues you've created/commented on (a-la bugzilla)(BastienNocera)

  • You can subscribe to any product, and you are automatically subscribed once you comment/report them.

• Ability to have private/confidential issues (BastienNocera)

  • GitLab allows issues to be confidential

• Ability to generate annual statistics (BastienNocera)

  • An automatic way to generate them is EE only. You have some visual statistics in here but not what we had in Bugzilla. In any case we can poke into the API and build one ourselves for basic statistics.

• Is it possible to require that issues be manually closed for some modules, rather than allowing them to be closed via a commit message?(TristanVanBerkom)

  • It works by regex ala "Closes #blah", so if you don't write "Closes #number" it won't close it.

• Other fields are missing in Gitlab, most notable the version one. It is very useful to be able to tell not only what version the reporter was using, but also what latest version someone was able to reproduce the issue with. (AlexandreFranke)

Code hosting

• GNOME uses linear commit logs without merge commits. Currently the merge button provided by GitLab CE doesn't work this way. We need it to do fast forward, but this is only available in EE.

  • We are hoping that the fast forward feature will be moved to CE. Is this a hard requirement? What happens if the feature isn't moved to CE?
• Fork and merge workflow - is there an alternative? (Jehan)
  • If you have commit access, you can push to master from the command line, just like now. However, the fork and merge workflow is required if you want to propose changes and don't have commit access.

• When closing an issue from a commit message (eg. "closes #123") it would be good to require the full URL for the issue, so it can be accessed from outside of GitLab (FlorianMuellner)

  • Makes sense, we can change the regex used for closing issues, documented here

• cgit allows downloading archives as tar.xz; GitLab doesn't (MilanCrha)

  • tar.xz is used by our releases, so that would be a nice thing to have to be consistent. We can open a bug report about this.

• Viewing the history of a single file is easier in cgit (BastienNocera)

  • I tried to see the difference, but they act the same. What is easier in cgit?

git-bz equivalent / command line considerations

• Ability to merge a pull request from the command line, rather than having to click a button in a web UI

  • This can be done using standard Git commands - checkout the branch, merge it, push it

• git-bz commands it would be good to have equivalents for:

  • git-bz file: Create fork (if not present) + issue + MR for a local patch + rewrite commit message with "Closes: $ISSUE_URL".
  • git-bz attach: Create fork (if not pressent) + MR + rewrite commit message with "Closes: $ISSUE_URL".
  • git-bz apply: Fetch remote + cherry-pick in order the commits in difference with master of the remote. This avoids recompilation as much as possible.
  • Will there be an equivalent for doing interactively applying patches?`

Migration concerns

• Keep Bugzilla URLs working, along with history

• Keep cgit URLs working

• Issue of missing attachments or other information from isssues that have been migrated (JensGeorg)

• Selective issue migration for some modules and not others could create confusion (AndreKlapper)

• Running two issue tracking solutions in parallel would be confusing (AndreKlapper)

Other features

• Will GitLab pages be too radical a change from the existing wiki? (TristanVanBerkom)

  • The pages feature isn't enabled by default. We'll have to decide whether to enable them or not.

Permission management

GNOME needs to be allocate permissions for the following roles:

• User - able to report issues only
• Triager - able to close/manage issues
• Developer - commit access