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