lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.21.0 Issues all verified!


From: David Kastrup
Subject: Re: 2.21.0 Issues all verified!
Date: Sun, 17 May 2020 00:28:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Valentin Villenave <address@hidden> writes:

> On 5/16/20, Carl Sorensen <address@hidden> wrote:
>> Thanks to all who have helped us get
>> back to a more regular release schedule!
>
> Well, thanks to you!  And to everybody who gave a hand (Federico,
> Karlin, and a few others?).  For a little while I was reminded of the
> Google tracker era, and of all the great work Graham contributed to.
> (Though today some of us evidently have a different approach in mind
> -- and didn’t seem to be impressed by this collective effort, which
> Jonas criticized as favoring "quantity over quality".)
>
> We’ll see what the issue-tracking policy becomes in the future
> (marking issues as "Verified" may well go the way of the dodo, since
> from what Jonas told me GitLab pushes us to only have two states: Open
> and Closed).  My main concern is that merge requests shoudn’t get
> prioritized over code consistency and QA.  (From a personal point of
> view, I am feeling quite discouraged but that’s my sort-of default
> mode so it doesn’t carry much meaning.)

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.

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.

But there is no point in being discouraged as long as we haven't even
decided on particular workflows: instead one should bring up problems
one sees.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]