<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 Sept 2021 at 07:01, Иван Комиссаров <<a href="mailto:abbapoh@gmail.com">abbapoh@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hello everybody</div></blockquote><div><br></div><div>Hello Ivan. I'm sorry to hear that you're experiencing some frustration here.</div><div><br></div><div>I must refrain from commenting on the specific code review that is in dispute, as I'm not familiar with that module, but I would like to offer some more general remarks that I hope both you and Oswald will find helpful.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>I would like to raise an issue about Oswald Buddenhagen abusing his maintainer rights. He is constantly blocking the merge of the patchset which implements a new feature in Qbs [0].</div></div></blockquote><div><br></div><div>From what I can see, there is a subset of the review comments for which the two of you haven't come to an agreement. A few terse comments have been exchanged on the review. It is not clear to me what discussion has occurred elsewhere. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> I started working on this almost a year ago and the issue was approved for the first time in October 2020 (!). Since then, Oswald popped up more and more random topics, demanding answers to all possible questions about the overall architecture and blocking the merge. While I highly appreciate his input, I don’t think it’s productive to postpone a relatively small feature for almost a year based on the assumption that it may not fit in the overall architecture. I prefer to move forward in small step, collect use-cases from actual users’ needs and see how this feature shows itself.</div></div></blockquote><div><br></div><div>This paragraph worries me a little bit.  I will try to explain...<br></div><div><br></div><div>Having spent a large part of my career working as a system architect (either by appointment or de-facto because nobody else wanted to do it), my experience has been that architecture is rarely given enough attention. This is partly because the majority of developers tend to be focused on their specific area of responsibility, so the "big picture" view of a system tends to be concentrated in a very small number of heads. It also happens that architectures become outdated as a system grows (especially one that grows organically like Qt does) and rearchitecting/refactoring rarely happens until a project is in deep trouble.<br></div><div><br></div><div>It has also been my experience that architectural errors are almost always vastly more difficult and costly to repair than coding errors.  For Qt, the backwards compatibility promises we make for most modules make that problem even worse, because certain types of architectural problem can only be corrected in a major release (which only occur once every 5 - 8 years). And on those rare occasions that a major release does come around, only a fraction of the known architectural issues get fixed each time due to limited resources and the desire to limit the extent of source-incompatible changes.  I would wager that every long-term module maintainer has a long laundry-list of such issues that they would love to fix if only they could get an opportunity (or a time machine to undo the original mistake).<br></div><div><br></div><div>Rightly or wrongly, Qt's approach has always been to get the architecture and API nailed down before releasing something as an official part of Qt.  That is why, for example, each major and minor Qt release has the "API Change Review" as part of the release process. That review step is there to minimize the number of architectural and API errors that sneak through into an official release, though obviously we cannot catch every error.<br></div><div><br></div><div> It has been rare for an official Qt release to include something as a "tech-preview" or "not yet subject to the compatibility promises". There are other mechanisms to seek feedback from users outside of official Qt releases for features that need some real-world usage to provide confidence that the use-cases really are being addressed well.  (I think that's what you were implying in your last sentence above. Forgive me if I have misunderstood you.)<br></div><br></div><div class="gmail_quote">I think that it is reasonable (and necessary) for a module maintainer to invest significant brain-power considering the impact of new features on the architecture of a module or system, and to be wary of things that don't seem to fit the existing architecture. Those things aren't automatically bad; they may just require some additional changes to tweak or improve the architecture.<div><br></div><div>FWIW, I can understand why new issues or objections may continue to be raised over time. There have been plenty of times when I have not spotted every issue on my first review of a patch and have had to come back later to revise my comments after realizing some important point that I had initially overlooked.  Occasionally, I have even had to throw away my initial review comments and start over in the light of some new information.  That's not a bad thing.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Also, Oswald mainly reviews the documentation and makes assumptions about the code based onion the documentation… I find this approach flawed, since documentation does not (and should not) show the user all the complexity of the actual implementation. Another annoying part is that Oswald neither does not know the Qbs code nor has desire to read and understand parts he’s commenting on.</div><div>I’ve been tolerating such behaviour for almost a year, but now I am confident that we can and should proceed with the current implementation and that Oswald is stalling the Qbs development. We’re not moving forward, I cannot fix bugs that depend on this feature I cannot implement new features based on this one - see the list of issue blocked by the related JIRA task - [1].</div><div><br></div><div>Oswald has been doing this in the past [2] - instead of allowing to contribute a small fix for a simple bug, Oswald turned the patchset into a lengthy discussion about architecture… I haven’t seen any contributions from Christian Gagneraud ever since (might be unrelated, though) and the bug is not fixed as of today.</div></div></blockquote><div><br></div><div>Again, I cannot comment on the specific patch, but in my experience it is certainly possible for even small patches to trigger legitimate discussions about architecture.  Sometimes it can be difficult to find a more appropriate forum for those discussions when Gerrit is right in front of you.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>I kindly asked Oswald to remove his -2 and allow me to proceed, but he chose to ignore my request. I’d like to ask Gerrit Administrators to remove his -2 so I can proceed with the development.</div><div><br></div><div>Also, some actions might be taken to prevent from happening in the future - if technically possible, I’d like to request the revoke of his approver rights on the Qbs project as per this part of the Qt Governance Model:</div><div>«In extreme circumstances Approver privileges can be revoked by a vote of no confidence, proposed by an existing Approver or Maintainer and arranged by the Chief Maintainer. Privilege revocation requires a two-thirds majority vote of those Approvers and Maintainers who express an opinion.» [3]</div></div></blockquote><div><br></div><div>That action is really designed as the last resort when all other avenues have been exhausted.  Therefore, the "burden of proof" is very high.<br></div><div><br></div><div> I think there are some other avenues you could try first (forgive my ignorance if you have already done so):</div><div><br></div><div>* Try face-to-face communication (e.g. a Zoom call). Sometimes disputes that take ages to resolve on asynchronous channels like IRC or JIRA comments can be resolved in a matter of minutes when discussing in real time. I also find that most people tend to be more conciliatory when they have to look the other person in the eye, even if it's through a computer screen.</div><div><br></div><div><div>* Consider inviting a neutral third-party to mediate online or face-to-face discussions.<br></div><div><br></div></div><div>* Try walking through the code together. Perhaps that can help to gain a deeper understanding of each other's point of view.</div><div><br></div><div>* Try making one or more small example programs that demonstrate the pros and cons of alternative solutions. These could then become part of the Qt examples to assist users (and maybe even future Qt developers trying to figure out why past architectural decisions were made).<br></div><div><br></div><div>* If the module in question has other contributors, consider inviting them to review the patch.  A module maintainer can sometimes be swayed by the consensus or majority opinion of other knowledgeable contributors.</div><div><br></div><div>* Consider whether the patch can be broken up into smaller pieces so that the parts that are not controversial can be merged while the remainder is being debated. Perhaps that could help to unblock some of the other items on your agenda.</div><div><br></div><div>* Consider whether any of the points on which you both disagree could be filed as new bugs in Jira, to be addressed in future releases rather than needing to be resolved immediately.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Ivan.</div><div><br></div><div>[0] <a href="https://codereview.qt-project.org/c/qbs/qbs/+/315910" target="_blank">https://codereview.qt-project.org/c/qbs/qbs/+/315910</a></div><div>[1] <a href="https://bugreports.qt.io/projects/QBS/issues/QBS-1604" target="_blank">https://bugreports.qt.io/projects/QBS/issues/QBS-1604</a></div><div>[2] <a href="https://codereview.qt-project.org/c/qbs/qbs/+/301461" target="_blank">https://codereview.qt-project.org/c/qbs/qbs/+/301461</a></div><div>[3] <a href="https://wiki.qt.io/The_Qt_Governance_Model" target="_blank">https://wiki.qt.io/The_Qt_Governance_Model</a></div></div></blockquote><div><br></div>Best of luck,</div><div class="gmail_quote">--</div><div class="gmail_quote">Jason<br></div></div>