[Development] Qbs development

[Jason McDonald]

On Tue, 14 Sept 2021 at 07:01, Иван Комиссаров <abbapoh at gmail.com> wrote:

> Hello everybody
>

Hello Ivan. I'm sorry to hear that you're experiencing some frustration
here.

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.


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

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


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

This paragraph worries me a little bit.  I will try to explain...

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.

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

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.

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

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.

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.


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

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.


> 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.
>
> 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:
> «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]
>

That action is really designed as the last resort when all other avenues
have been exhausted.  Therefore, the "burden of proof" is very high.

I think there are some other avenues you could try first (forgive my
ignorance if you have already done so):

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

* Consider inviting a neutral third-party to mediate online or face-to-face
discussions.

* Try walking through the code together. Perhaps that can help to gain a
deeper understanding of each other's point of view.

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

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

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

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



> Ivan.
>
> [0] https://codereview.qt-project.org/c/qbs/qbs/+/315910
> [1] https://bugreports.qt.io/projects/QBS/issues/QBS-1604
> [2] https://codereview.qt-project.org/c/qbs/qbs/+/301461
> [3] https://wiki.qt.io/The_Qt_Governance_Model
>

Best of luck,
--
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210914/6917b5ce/attachment-0001.html>