Tails

#7 Updated by Anonymous 2018-08-16 12:31:05

I’m starting to find Redmine more and more unusable. I want tags and merge requests and a readable layout that does not hurt my eyes.

#8 Updated by segfault 2018-08-16 19:07:12

My two cents:

• Merge requests and GitLab CI are awesome, I think it’s crazy we don’t use them yet
• I do miss subtasks in GitLab, it makes it harder to split an issue into smaller tasks and there is no good overview for them
• I also miss the “blocked by” relationship, although less than the subtasks

=> I think we should start using GitLab merge requests and CI ASAP, but maybe still use redmine for the tickets.

#9 Updated by intrigeri 2018-08-16 20:04:30

> => I think we should start using GitLab merge requests and CI ASAP, but maybe still use redmine for the tickets.

Works for me. Next step: identify what prevents us from doing so and find realistic solutions :)

#14 Updated by lamby 2019-02-06 22:58:05

Where’s the +1 button!

#21 Updated by intrigeri 2019-11-12 15:12:51

Here’s a first batch:

• 35 MRs were merged since we started this experiment ~7 months ago.
• On 2019-09-01, I asked feedback to the FT about this by the end of October. No reply so far. I’ve pinged the thread, with an updated deadline (end of this week). I’ll report back here if I receive such feedback.
• I’ve heard enthusiastic feedback about the ability to comment on specific lines while reviewing.
• I’ve heard feedback about not seeing much benefit compared to the Redmine way of doing reviews. For context, this was about a rather small documentation branch.
• It’s now clear to me that we need at least pointers to the relevant GitLab MR documentation: we should not take for granted that everyone is already used to GitHub/GitLab PR/MR workflows and web UIs. I’ve filed Feature #17226 to ensure this is not forgotten by the folks who’ll implement the migration.
• There’s been some confusion caused by the current non-standard setup where the repo hosted on Salsa is not the canonical one, but a mirror one should not push to. These problems will not exist as long as the canonical copy of our repositories live on GitLab, so IMO these are strong points in favor of doing that.
  • One aspect that was initially unclear to one person (i.e. where should follow-up commits be pushed) was promptly clarified, but further misunderstandings arose later in the conversation. For details, see the full discussion.
  • There’s been lots of confusion, for several people, caused by the fact that Salsa shows all pushes as made by yours truly, regardless of who actually pushed. That’s because I’m the one who has set up the deployment key that’s used to do the mirror synchronization.
• Through this experiment, I’ve learnt that one can comment on a commit on GitLab (I had no idea). But somehow the resulting discussion seems to have a different behavior wrt. notifications than a discussion happening on a MR: it looks like there’s no concept of “participant”. This resulted in someone missing a reply to a comment of theirs. I have no idea what’s the deal here. I hope that documentation about MRs will help folks comment on the MR instead of on commits (especially commits that are not part of the MR, like in this case), which will avoid this kind of trouble. For details, see the full discussion.
• The FT has not used GitLab MRs much after the initial excitement, apart of for a few branches that were bigger than average and could truly benefit from GitLab’s inline review facilities. I guess this can be explained by a combination of three factors:
  • Most of our branches are tiny, simple, and get merged with no comment whatsoever by the reviewer. So most of the time, inline comments during code review would not be used. The only benefit we would get is the web UI to inspect the diffs and commits, but since at the end of the day one currently needs to merge via the command line, oh well, one can as well review on the command line.
  • Most of our branches are about a Redmine ticket, so to use a MR, one needs to do extra paperwork. So unless the benefit of doing so is clear (not the case most of the time as said above), understandably we don’t bother. The need for extra paperwork will vanish once our issues are tracked in GitLab.
  • The FT already has a hard time to keep track of Redmine issues that need validation. Having to also monitor the MRs on Salsa requires more busywork, which is not exactly motivating.
• The feature of having N open “discussions” on a merge request, that can be “resolved” (as opposed to the linear list of comments without metadata that we have on Redmine, which makes long discussions harder to follow than they could be), was not used consistently: the default being to simply add a comment to the pile, folks who were not already used to GitLab tended to do that, including in cases where they should really have started a discussion. I trust this can be solved by a combination of documentation, learning by example, and gentle mentoring as folks get started with GitLab. Note that if that does not get solved, the end result is just as bad, and no worse, than what we have on Redmine.

I’ll translate the take aways of this experiment into clear requirements/specifications for the folks who will implement our migration to GitLab.