Tracker issue for tasks on our side for GitLab
Let's have a ToDo of what tasks are needed to progress with GitLab set up in our side. These tasks are ordered by importance and how soon we should figure them out.
-
Shared labels. Discussion being held here. Still needs more discussion and gather feedback. - Figure the best & proper way for our fast forward contribution workflow. There are two issues:
-
When the merge request is outdated, there is no option to rebase in the UI. I sent an email to GitLab about this, and let's see what we can do. We can investigate if we can use bots, like Flatpak does or like this rust article about their infra, but I would prefer the proper way of using GitLab UI itself if possible. -
When there is conflicts and the contributor doesn't answer, you resolve and rebase locally. However there is no way to communicate to GitLab about the new branch. An option semi hidden in GitHub is to allow write access in the reporter branch associated to a merge request. We can ask GitLab about this. Any idea what we could do on our side? -
Figure out the proper way for our clean git history (the review doing push --force). Discussion is between us and GitLab upstream too, handled in issue #8 (closed) and upstream here. You can provide ideas and how we would like to work. -
Figure out what to do with bugs reported in Bugzilla that are reported in GitLab too. We need to start discussion in a new infraestructure issue report and maybe send a ddl email asking for feedback. We need first to write down the options we have. -
We need to start a discussion in a ddl email + infraestructure issue report about if we are comfortable with merges. Also, do we have some written policy? Do we know the reasons this was this way? Do we want to open ourselves into using GitLab recommended and designed workflow? - Improve our migration tool from Bugzilla to GitLab. The best way to develop/fix is to simply take a project from Bugzilla and experiment with the output of the tool in our test instance. Some short TODO:
-
Fix bugs. Really, there are many, and it's the most important part. -
Make sure we point to gitlab-test by default, so noone runs in the production instance by accident. -
Investigate what to do with duplicates -
Investigate what to do with block/depends -
Investigate what to do with subscribers -
Investigate what to do with components -
Investigate what to do with versions -
Investigate what to do with attachments - Help Sir @csoriano with GitLab documentation in general. The most important page is the pilot program wiki and our workflows wiki. A short ToDo:
-
Writing down our workflows, for example how do we show the merge request needs work? (answer is using resolvable discussions) and linking to GitLab docs -
Writting down limitations of the current state of GitLab -
Writting steps to follow to be part of the pilot program -
Write what the pilot program is and its implications - ...
- Help triaging and commenting in issues raised in this infraestructure project. Basically looking at upstream GitLab docs and issues and figure out the options to address the concerns raised here.
-
Create issue template, so reporters have a template when filing bugs. This is useful for example to automatically set the "bug" label if necessary or to provide info in case of crashes. -
Investigate permissions. Is "Developer" permission for all of us enough? Do we need to set "Master" or "Owner" for each project? - CLI tool that set up common workflows like what we had with git-bz. A stablished tool for this is available [here] (https://github.com/seveas/git-spindle) and its documentation for GitLab. However the tool is not as straightforward as git-bz. Also you can take a look at GitLab API in this more raw tool here. What we want from the tool is:
-
Contribute a patch (equivalent of git bz file). This is, create a fork in your namespace if it doesn't exist yet, create a local branch, push that branch, create merge request. -
Test a merge request (git bz apply). This involves setting the remote, pull, checkout. -
Modify and push a merge request (git bz push) in case you modify/rebase the branch, for example, when there are conflicts and the reporter doesn't answer. This involves: pushing the changes, closing the merge request, point to the commits that were pushed. Alternative is to convince GitLab to do as GitHub and allow write access to the reporter branch in the merge request so you can push --force. -
Set up CI with Flatpak for applications. Alex Larsson was working on a prototype for it. -
Set up CI with custom Fedora base for applications -
Milestones for GNOME. A first serie is created already here. Initially this is for the release team, but maintainers will use it as well as a way to track what issues they want to fix for a certain milestone. We need to figure out and discuss whether it worth to have a "blocker" label for the release team, or if we can assume every issue in there is "blocker". Also, we need to discuss whether this is useful or not and if we cover the use cases of release team.