Re: 2.21.0 Issues all verified!

[Han-Wen Nienhuys]

On Sun, May 17, 2020 at 3:12 AM Carl Sorensen <address@hidden> wrote:
> > 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.

I want to dissent here: I think that issues should not be used unless
there is an actual bug or other effort that needs to be tracked
separately from the code.

We now have 3 distinct places to put information

1) issue discussion
2) merge request
3) commit message

for posterity, it is usually easier to put all info inside the commit
message, because it doesn't rely on external sites (rietveld,
sourceforge, gitlab). We need the MRs to discuss the code and commit
message. What benefit do we get from also having an issue?

There is a definite downside to using the issue tracker, which is that
filing bugs becomes harder, because all the chatter from the
development process makes it harder to find relevant bugs.

> 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.

what does "track" mean in this context?

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen