Re[2]: 2.21.0 Issues all verified!

[Trevor]

Jonas Hahnfeld wrote 17/05/2020 11:57:10

> Am Sonntag, den 17.05.2020, 00:28 +0200 schrieb David Kastrup:
> >  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.
>
> I agree on having an issue for every bug we fix, especially those
> coming from the bug-lilypond list. It's easier to have those in one
> place instead of searching if a merge request happens to fix a problem.
> For cleanups, compiler warnings or performance work I think having only
> a MR is fine. In my opinion creating an issue for about any code change
> is somewhat overkill. But there are guidelines mandating this, so I'd
> be open to discussing the merits if somebody thinks it's the better
> approach. After all, we had this previously...
I agree we need an issue for every bug we uncover, but fixes that are
trivial (in the sense that they are most unlikely to break anything) are
fine to simply issue a MR. In this past we left this judgement to the
fixer and it seemed not to cause any problems. Such trivial fixes are
now more visible than they were, so are even less likely to cause
problems or be applied inappropriately.

It is important to be able to move easily from Issue to Fix and back
when investigating possible problems in the future, so we should
ensure all the tags and links are in place before a fix is pushed.

Trevor