[Development] Qbs development

Lars Knoll lars.knoll at qt.io
Tue Sep 14 14:21:49 CEST 2021

> On 14 Sep 2021, at 12:34, Richard Weickelt <richard at weickelt.de> wrote:
>> Just for the sake of clarity, who *is* the Maintainer of QBS ?
>> Our wiki's [[Maintainers]] page only mentions Christian Kandeler as
>> maintainer of Qt Creator's integration with it.  I gather Ivan is a/the
>> principal developer of QBS in practice.  Is Ossi co-Maintainer, or are
>> you really talking about his Approver rights (which, IIUC, suffice to
>> make a +2 significant) ?
>> Before we resort to [0] QUIP 2's "extreme circumstances" provisions,
>> please let's do what we can to work our way through the steps that come
>> before that - for which we first need to settle the question of who *is*
>> The Maintainer (or who are The Maintainers, if more than one) of QBS.
>> [0] http://quips-qt-io.herokuapp.com/quip-0002.html
> Christian Kandeler is the only maintainer. Ivan Komissarov is the most
> active developer in that repository and has approver rights as well.
> We are talking here about the situation that the maintainer has given a +2
> while a person unrelated to that particular repository has stopped the patch
> with a -2. On the other hand, that person has neither shown any intention to
> implement that feature nor has the person contributed to the codebase during
> the last couple of years.

I think this makes the situation very clear. The maintainer of a module has the right to overrule negative reviews. So if Christian thinks this change is ok to go in, it is his full right to overrule a -1 and also a -2 from someone else.

We should all of us be careful in giving -2s on code reviews. I don’t think anybody should give a -2 unless you are the maintainer/deeply involved in the code in question or the commit violates some of our policies. 
> The question is whether this is an abuse of approver rights.

Blocking a change in an area you aren’t actively working on against the expressed wishes of the maintainer would in my opinion be such an abuse. Giving a -2 directly after the maintainer approved the change is getting very close to that.
> This is a relevant question for the Qt project. Any person with approver
> rights has the ability to cause a production stop. Ivan is asking for help
> in this particular case and I am seconding his request.

Any such system has to be built to a good degree on trust that people do the right thing and have good intentions. We do have gerrit admins that can help in such cases and remove a block.

As a general rule to everybody: Please do not make the perfect the enemy of the good. We shouldn’t block changes that improve an existing situation even if they aren’t covering everything one can think of. The question has to be whether the change improves on the current base and doesn’t cause regressions. Of course this requires that the change itself doesn’t leave loose ends someone else might have to clean up.

If you think something’s missing, you can point those out, also give a -1 if you feel they are important. But please also respect the work others are doing. If someone contributing says is not willing to push it further (or wants to do in later), that should be ok as well (given the conditions above).


More information about the Development mailing list