On Sat, May 16, 2020 at 4:28 PM David Kastrup <[email protected]> wrote: > > Uh, I think it's the wrong point of time to feel discouraged: we are at > the current point of time figuring out what the tool does well and not > so well under which usage.
I completely agree with this. I miss the Rietveld review process, but mostly I'm not familiar at all with the GitLab one. > > Personally, so far my main issue is, well, the workflow bypassing > issues. Changes that are only presented as merge requests without any > accompanying issue are just too intangible for my taste: those > correspond more to what we previously said "things like that you can > push directly to staging". I find it awkward to find my way around > them, and after pushing there does not seem an obvious reverse relation > to a tangible report that one could easily derive from seeing the commit > in the repository. > > I prefer having an actual issue number for the details for anything of > non-trivial nature. +1 I believe we should declare (and try to enforce) a policy that the name of a branch in a merge request should include an issue number. With git-cl upload, an issue was automatically created if it didn't already exist. I really liked that functionality. If we can't do such a thing automatically in GitLab, I think we should do it by policy. As you say, it's very hard to track merge requests without a tie to the issue tracker. Thanks, Carl
