Re: 2.21.0 Issues all verified!

[Carl Sorensen]

On Sat, May 16, 2020 at 4:28 PM David Kastrup <address@hidden> 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