On 2022-02-05 19:52, Dan Eble (@eble) wrote:
Dan Eble <https://gitlab.com/eble> commented on a discussion
<https://gitlab.com/lilypond/lilypond/-/merge_requests/1173#note_832991904>:
The open thread says that I created a ticket to track an issue. I left
it open because I wanted it to be visible to reviewers.
The test results have been available for 5 days with no comments from
reviewers. If somebody thought that creating a ticket for the oddity
uncovered by the new test was insufficient, they would have said so by
now. I believe this is ready to be pushed.
As I understand it, Dan, you identified a problem with the MR, and
created a new issue to say there is a problem with the patch. I don't
know who gets notified of new issues, so your taking silence for consent
doesn't seem to mean that anyone saw your issue. You now feel that the
patch should be pushed regardless, and you changed the status of your MR
to patch-countdown without informing me. That is why I'm responding this
way: I need to be sure we understand each other as early in the journey
as possible.
It may well be that the issue is minor, but you don't get to overrule
the referee: the ref's decision is final. There is a Patch-Meister role,
outside of the developer group, to ensure as much diligence as possible
by providing disinterested monitoring of the process. Yes, I'm learning
the new technologies and automated systems used by Lilypond, but I
understand software development from experience, and one of the basics
is code review with formal feedback. We seem to have abandoned the
requirement for a formal LGTM, depending on automated testing, and
perhaps that might be something to consider reviving, in another
discussion. Nonetheless, if a developer identifies an issue, and there
is no resolution of the issue, and no assurance other than from the
developer that the issue can safely be set aside, then the MR cannot
proceed.
I have said in another thread, that while I have software development
experience beginning over 40 years ago, I'm the new kid in this latest
iteration of the community. Until, and probably even after, I become
fully on board with the ways developers communicate with each other,
with the ways they record that exchange, and with the status data
available on the various presentations of merge requests, I am likely to
be awkwardly insistent on dotted eyes and crossed tees. I will
inevitably and unintentionally step on toes, and if approached with new
information, suggestions and guidance, will respond gratefully. If you
overrule me and do my job for me, you inherit it.
regards,
Colin
