Re: [Development] Qbs development

[Lars Knoll]

Hi all,

Just wanted to give a quick heads-up that this hasn’t been forgotten. But I’ve 
been sick with the flu the last week and simply didn’t manage to push things 
forward.

As we have so far not had the need for such a vote, there’s some things we’ll 
need to sort out to make it happen. I’ll follow up with a more detailed email 
in a separate thread hopefully tomorrow after the 6.2 release is out.

Cheers,
Lars

On 16 Sep 2021, at 19:53, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:

I believe there were several other cases, both in gerrit and discord.
I think, we should proceed with a formal vote.

Ivan

16 сент. 2021 г., в 14:50, David Skoland 
mailto:david.skol...@qt.io>> написал(а):



On 15 Sep 2021, at 16:52, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:
your arrogance, dismissiveness, and cynicism are duly noted, as usual.

I believe this constitutes a personal attack, which is in violation of the Qt 
Code of Conduct: 
http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph: Be 
respectful)

Cheers,

David Skoland
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Иван Комиссаров]

The patchset is still blocked.

Gerrit Admins, could you please remove the -2 vote?

Ivan
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Thiago Macieira]

On Friday, 17 September 2021 02:03:39 PDT Volker Hilsheimer wrote:
> The approver that gave the -2 not yielding to the maintainer giving a +2
> should be (and is, in my experience) such an exceptional situation that it
> deserves explicitly notifying the chief maintainer and gerrit admins. And
> perhaps it even requires this kind of conversation to be had on the mailing
> list, because the problem really is not that there is no button.

I agree with Volker.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Edward Welbourne]

On 17 Sep 2021, at 10:51, Edward Welbourne  wrote:
>> The Maintainer has the authority to ask the admins to remove it.
>> Indeed, a button - available only to the Maintainer(s) of the module
>> - would be a nice improvement to the process but, for the present at
>> least, that "button" is implemented by e-mail to the Gerrit admins.

Volker Hilsheimer (17 September 2021 11:03) replied:
> I don’t think this process should be made easy.
>
> The approver that gave the -2 not yielding to the maintainer giving a
> +2 should be (and is, in my experience) such an exceptional situation
> that it deserves explicitly notifying the chief maintainer and gerrit
> admins. And perhaps it even requires this kind of conversation to be
> had on the mailing list, because the problem really is not that there
> is no button.

Fair point.
For reference, relevant e-mail addresses can be found here:
https://wiki.qt.io/Maintainers#CI_Maintainers

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Volker Hilsheimer]

> On 17 Sep 2021, at 10:51, Edward Welbourne  wrote:
> 
> Chris Adams (17 September 2021 03:45) wrote:
>> My point being: maybe the "maintainers can override a -2" is a
>> "conceptual power" rather than a physical button in Gerrit, which
>> still requires the approver to take away their own -2 in that
>> circumstance?  (Obviously Gerrit admins can do it, but not every
>> maintainer is a Gerrit admin.)
> 
> The Maintainer has the authority to ask the admins to remove it.
> Indeed, a button - available only to the Maintainer(s) of the module -
> would be a nice improvement to the process but, for the present at
> least, that "button" is implemented by e-mail to the Gerrit admins.


I don’t think this process should be made easy.

The approver that gave the -2 not yielding to the maintainer giving a +2 should 
be (and is, in my experience) such an exceptional situation that it deserves 
explicitly notifying the chief maintainer and gerrit admins. And perhaps it 
even requires this kind of conversation to be had on the mailing list, because 
the problem really is not that there is no button.

Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Edward Welbourne]

Chris Adams (17 September 2021 03:45) wrote:
> My point being: maybe the "maintainers can override a -2" is a
> "conceptual power" rather than a physical button in Gerrit, which
> still requires the approver to take away their own -2 in that
> circumstance?  (Obviously Gerrit admins can do it, but not every
> maintainer is a Gerrit admin.)

The Maintainer has the authority to ask the admins to remove it.
Indeed, a button - available only to the Maintainer(s) of the module -
would be a nice improvement to the process but, for the present at
least, that "button" is implemented by e-mail to the Gerrit admins.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Thiago Macieira]

On Thursday, 16 September 2021 18:45:35 PDT Chris Adams wrote:
> My point being: maybe the "maintainers can override a -2" is a "conceptual
> power" rather than a physical button in Gerrit, which still requires the
> approver to take away their own -2 in that circumstance?

Correct.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Chris Adams]

Hi,

I'm not related at all to QBS development, but I am a maintainer of another
module or two (add-on modules like QtPIM, QMF), and I've never noticed an
"override review" button (similar to the "override sanity bot" button).
Although I can't ever remember having seen a -2 in those modules, so maybe
I just never saw it.
My point being: maybe the "maintainers can override a -2" is a "conceptual
power" rather than a physical button in Gerrit, which still requires the
approver to take away their own -2 in that circumstance?
(Obviously Gerrit admins can do it, but not every maintainer is a Gerrit
admin.)

Best regards,
Chris.


On Fri, Sep 17, 2021 at 4:19 AM NIkolai Marchenko 
wrote:

> Tbf, the only vote that's needed is to make you the official maintainer.
> The only reason this situation even exists is seemingly because while
> Christian +2'd your patch, he didn't override -2 from Ossi while it was
> said above he could. Regardless of who is right in this situation, that he
> didn't lift the blocking vote with his power which made it spill here in
> such a nasty manner is unhealthy.
>
> On Thu, Sep 16, 2021 at 8:55 PM Иван Комиссаров  wrote:
>
>> I believe there were several other cases, both in gerrit and discord.
>> I think, we should proceed with a formal vote.
>>
>> Ivan
>>
>> 16 сент. 2021 г., в 14:50, David Skoland 
>> написал(а):
>>
>> 
>>
>> On 15 Sep 2021, at 16:52, Oswald Buddenhagen 
>> wrote:
>> your arrogance, dismissiveness, and cynicism are duly noted, as usual.
>>
>>
>> I believe this constitutes a personal attack, which is in violation of
>> the Qt Code of Conduct:
>> http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph:
>> Be respectful)
>>
>> Cheers,
>>
>> David Skoland
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[NIkolai Marchenko]

Tbf, the only vote that's needed is to make you the official maintainer.
The only reason this situation even exists is seemingly because while
Christian +2'd your patch, he didn't override -2 from Ossi while it was
said above he could. Regardless of who is right in this situation, that he
didn't lift the blocking vote with his power which made it spill here in
such a nasty manner is unhealthy.

On Thu, Sep 16, 2021 at 8:55 PM Иван Комиссаров  wrote:

> I believe there were several other cases, both in gerrit and discord.
> I think, we should proceed with a formal vote.
>
> Ivan
>
> 16 сент. 2021 г., в 14:50, David Skoland  написал(а):
>
> 
>
> On 15 Sep 2021, at 16:52, Oswald Buddenhagen 
> wrote:
> your arrogance, dismissiveness, and cynicism are duly noted, as usual.
>
>
> I believe this constitutes a personal attack, which is in violation of the
> Qt Code of Conduct:
> http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph:
> Be respectful)
>
> Cheers,
>
> David Skoland
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Иван Комиссаров]

I believe there were several other cases, both in gerrit and discord.
I think, we should proceed with a formal vote.

Ivan

> 16 сент. 2021 г., в 14:50, David Skoland  написал(а):
> 
> 
> 
>> On 15 Sep 2021, at 16:52, Oswald Buddenhagen  
>> wrote:
>> your arrogance, dismissiveness, and cynicism are duly noted, as usual.
> 
> I believe this constitutes a personal attack, which is in violation of the Qt 
> Code of Conduct: 
> http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph: 
> Be respectful)
> 
> Cheers,
> 
> David Skoland
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[David Skoland]

On 15 Sep 2021, at 16:52, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:
your arrogance, dismissiveness, and cynicism are duly noted, as usual.

I believe this constitutes a personal attack, which is in violation of the Qt 
Code of Conduct: 
http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph: Be 
respectful)

Cheers,

David Skoland
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Andy Shaw]

On Thu, Sep 16, 2021 at 09:34:00AM +, Oswald Buddenhagen wrote:
> the thing is that an agreement *can* be reached, as has been many times
> before. the maintainer just doesn't give a shit.

Can we refrain from using such language on the mailing list? Not everyone 
appreciates it and there is no reason to use such language for any reason as 
part of a public discussion. The point can still be made without having to 
resort to swearing to make it.

Kind regards,
Andy
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Ulf Hermann]

QUIP-2 clearly states that the maintainer has decision power in case no
agreement can be reached.

the thing is that an agreement *can* be reached, as has been many times
before. the maintainer just doesn't give a shit.


The question is more about how much effort and discussion is needed to 
reach such an agreement, and what form such discussions take. In 
particular, how much of that effort and discussion actually leads to a 
better understanding? How much of it is just moving sideways and 
bloating the issue at hand with only tangentially related other things, 
while randomly flinging feces at other people? I think Ossi's statements 
in this thread are somewhat exemplary.


There is a limit to what people can tolerate. Personally, I'm not easily 
offended by such games. Yet, having dealt with Ossi before, I can 
understand that other people are.


best regards,
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Oswald Buddenhagen]

On Thu, Sep 16, 2021 at 07:52:14AM +, Lars Knoll wrote:

The original problem is that using a -2 to block a change that has been
approved by the module maintainer is basically abusing gerrit to break
our governance model.


telling the maintainer to not do a proper job as a maintainer is also
"breaking the model".


QUIP-2 clearly states that the maintainer has decision power in case no
agreement can be reached. 


the thing is that an agreement *can* be reached, as has been many times
before. the maintainer just doesn't give a shit.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Lars Knoll]

Hi,

I think this discussion about details is pretty much irrelevant.

The original problem is that using a -2 to block a change that has been 
approved by the module maintainer is basically abusing gerrit to break our 
governance model. QUIP-2 clearly states that the maintainer has decision power 
in case no agreement can be reached. 

You might disagree with that +2, but it is *not* your decision at that point. 
As an Approver you are expected to know our governance model and work within 
its frame. So if the maintainer gives a +2, you are abusing the system by 
continuing to block the change and violating our governance model. 

Lars

> On 16 Sep 2021, at 01:06, Oswald Buddenhagen  
> wrote:
> 
> On Thu, Sep 16, 2021 at 12:40:37AM +0300, Иван Комиссаров wrote:
>> 15 сент. 2021 г., в 14:03, Oswald Buddenhagen  
>> написал(а):
>>> for example, he plainly admits that his documentation doesn't match
>>> the code.
>> 
>> That’s not true.
>> 
> for it not being true you're making a _remarkable_ effort to establish
> that it would be _just fine_. ;)
> 
>> And if it is, feel free to submit patches, if you want the perfect
>> documentation
>> 
> it's not about perfect docu, it's about docu that even remotely matches
> the actual behavior. your argument was that my criticism of your patch
> is unjustified because the code actually does what i'm asking for, even
> though the docu _clearly_ says something else.
> 
> i don't actually care which it is, because either one justifies a -1.
> 
>> I am not interested in translating from C++ to English in order to
>> mention every small detail about implementation
>> 
> are you aware of point 1.1 of the qt commit policy?
> (and yes, qbs' documentend behavior is equivalent to qt's api in that
> regard.)
> 
>> (which you chose not to review despite being directly asked to do so.
>> Several times).
>> 
> that's entirely correct. i refuse to review code (which takes an order
> of magnitude more effort to do properly) when the documentation already
> tells me that what the code does is wrong. that's *reasonable*.
> 
>> The rest of the community is not interested either.
>> 
> which is quite unfortunate. but at least they are not the maintainers.
> 
>> It is not boring, it is irrelevant to the patch - I haven’t done any
>> global changes to the patch in a YEAR constantly pleasing you desire to
>> discuss the bigger picture.
>> 
> it's funny that you say that, because the very existence of the property
> whose precise semantics we're debating so hotly now is actually wholly
> my idea, and it took me long enough (that aforementioned year) to
> convince you that it is a necessary and good one (the review logs refer
> to it as QBS-61, prior to factoring it out to QBS-1604).
> 
> you have also convinced me of two things just recently, so you know it's
> possible if you just do it properly.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Oswald Buddenhagen]

On Thu, Sep 16, 2021 at 12:40:37AM +0300, Иван Комиссаров wrote:

15 сент. 2021 г., в 14:03, Oswald Buddenhagen  
написал(а):

for example, he plainly admits that his documentation doesn't match
the code.


That’s not true.


for it not being true you're making a _remarkable_ effort to establish
that it would be _just fine_. ;)


And if it is, feel free to submit patches, if you want the perfect
documentation


it's not about perfect docu, it's about docu that even remotely matches
the actual behavior. your argument was that my criticism of your patch
is unjustified because the code actually does what i'm asking for, even
though the docu _clearly_ says something else.

i don't actually care which it is, because either one justifies a -1.


I am not interested in translating from C++ to English in order to
mention every small detail about implementation


are you aware of point 1.1 of the qt commit policy?
(and yes, qbs' documentend behavior is equivalent to qt's api in that
regard.)


(which you chose not to review despite being directly asked to do so.
Several times).


that's entirely correct. i refuse to review code (which takes an order
of magnitude more effort to do properly) when the documentation already
tells me that what the code does is wrong. that's *reasonable*.


The rest of the community is not interested either.


which is quite unfortunate. but at least they are not the maintainers.


It is not boring, it is irrelevant to the patch - I haven’t done any
global changes to the patch in a YEAR constantly pleasing you desire to
discuss the bigger picture.


it's funny that you say that, because the very existence of the property
whose precise semantics we're debating so hotly now is actually wholly
my idea, and it took me long enough (that aforementioned year) to
convince you that it is a necessary and good one (the review logs refer
to it as QBS-61, prior to factoring it out to QBS-1604).

you have also convinced me of two things just recently, so you know it's
possible if you just do it properly.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Иван Комиссаров]

> 15 сент. 2021 г., в 14:03, Oswald Buddenhagen  
> написал(а):
> 
> in a nutshell, though, i think ivan's initial message is revealing
> enough - for example, he plainly admits that his documentation doesn't
> match the code. that's an automatic -1, and a yellow card for attitude.

That’s not true. And if it is, feel free to submit patches, if you want the 
perfect documentation (I think, I mentioned this before. Several times). I am 
not interested in translating from C++ to English in order to mention every 
small detail about implementation (which you chose not to review despite being 
directly asked to do so. Several times).

> in this case, you personally instructed the maintainer to do only
> minimal maintenance work (which he does an excellent job at). he has
> repeatedly made clear that he has exactly *zero* interest in the
> strategic direction of qbs, and is letting "the community" duke it out
> among itself, exactly as you wished. he provides no guidance whatsoever,
> but reserves the right to cut short discussions he finds boring (or
> something). the -2 is an override on that institutionalized
> indifference.

The rest of the community is not interested either. It is not boring, it is 
irrelevant to the patch - I haven’t done any global changes to the patch in a 
YEAR constantly pleasing you desire to discuss the bigger picture. We discussed 
it and guess what changed? Nothing. The only job I did related to the patch is 
moved some code around and I don’t see how it was related to those endless 
discussions either.

Ivan
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Иван Комиссаров]

OK, it will be fair to list the problems/inconveniences we have right now (or, 
in other way, the advantages of GitHib)

- It is hard for the newcomers to get familiar with gerrit - some people 
submitted raw patches in JIRA claiming they don’t have time to learn Gerrit 
while knowing the pull-request model. Gerrit is a great tool, but has high 
learning curve.
- We use GithubActions to test Qbs - in order to do that, we use bot written by 
Richard which pick changes from gerrit and uploads them to Richard’s GitHub. 
The bot doesn’t use Gerrit api (it looks on the e-mails) and can miss some 
events. It will definitely help if we can use Gerrit API somehow. What is 
required to use it? Do we need additional access? Do we need to install the bot 
on the Gerrit server?
- The only one capable of uploading binaries to the website is Christian. We 
cannot do that automatically via GitHub actions release pipeline as we don’t 
have credentials for uploading. The alternatives is to upload binaries using 
the GitHub mirror (not sure if this is possible) or configure the web server 
(https://download.qt.io/official_releases/qbs/ 
) in a way that Qbs organisation 
will have access to this specific folder.
- As Denis mentioned, having a VM running on a QtC's server might be more 
stable than VM running on Denis PC=)
- maybe something else

The migration to GiHub magically solves these issues and I don’t know how much 
work is needed to solve them in the current setup - I assumed it will be harder.
But if QtC is willing to help, we can go this way - there’s no rush to solve 
these issues (can wait till Qt6 release), it’s just minor inconveniences we 
experience, especially during releases.

Ivan

> 15 сент. 2021 г., в 13:32, Lars Knoll  написал(а):
> 
> Hi Ivan,
> 
> I also would very much like you to stay here. QBS is great project and 
> something that came out of the Qt work and still has very strong ties to it.
> 
> I am fully with Tuukka that what we want is to make it a good experience and 
> easy for people to work here in the project. Blocking other peoples work is 
> certainly not in line with this. 
> 
> The governance model has the ’no confidence’ clause for a reason and if you 
> have tried other means before, I can and will of course arrange such a vote.
> 
> Cheers,
> Lars
> 
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Oswald Buddenhagen]

On Wed, Sep 15, 2021 at 01:37:38PM +0200, Christian Kandeler wrote:

I think our definition of "guidance" differs. For me, it does not
involve going into infinite loops of obsessively arguing about points
that only I care about. I do believe, however, that I am reasonably
capable of telling a good patch from a bad one and constructive advice
from self-serving bickering.


your arrogance, dismissiveness, and cynicism are duly noted, as usual.
however, you haven't provided any evidence that your judgement is based
on actual understanding of the matters at hand, as you have chosen to
remain silent despite repeated requests (also from ivan) to participate.
i'd call _that_ abuse of maintainer priviledge.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Tuukka Turunen]

Hi,

Let’s look into what kind of additional systems we could arrange that helps 
development of Qbs. Just now everyone is busy getting Qt 6.2 and QDS 2.2 
successfully released, but we should be able to look into this latest in the 
beginning of October.

Yours,

Tuukka

From: Development  on behalf of Denis 
Shienkov 
Date: Wednesday, 15. September 2021 at 13.59
To: development@qt-project.org 
Subject: Re: [Development] Qbs development

Hi Lars, Tuukka,

> I also would very much like you to stay here.

AFAIK, a main issue here not about of maintenance behaviour. A main issue in 
the access right on the Qbs project. F.e. right now it is hard to maintenance 
the CI integration with the GitHub, to generate the pre-compiled releases and 
other stuff (maybe Ivan can explain a betetr).

Also, a main issue is for the CI for the bare-metal toolchains, where we need 
to use the self-runners instead of Docker containers (there are impossible to 
use the dockers).

So, if you want to be Qbs stayed in the QtCompany infrastructure, then you need 
to help us a bit, e.g. provide some separate server resources (e.g. two VMs 
with Linux && Windows OS installed) where we can setup all required stuff to 
work with CI. ;)

Because right now I use own host PC as self-runner for CI, what is very bad and 
non-stable approach.  ;)

BR, Denis
15.09.2021 13:32, Lars Knoll пишет:
Hi Ivan,

I also would very much like you to stay here. QBS is great project and 
something that came out of the Qt work and still has very strong ties to it.

I am fully with Tuukka that what we want is to make it a good experience and 
easy for people to work here in the project. Blocking other peoples work is 
certainly not in line with this.

The governance model has the ’no confidence’ clause for a reason and if you 
have tried other means before, I can and will of course arrange such a vote.

Cheers,
Lars



On 15 Sep 2021, at 12:18, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

I would not like Qbs development to move away from the Qt project. It is very 
unfortunate that you have had bad experience and misbehavior from one approver. 
We want to constantly improve the experience of working within the Qt project 
and naturally this kind of incidents are not doing that. Therefore, it is very 
good that you have raised the topic in the mailing list, as many were not aware 
of it earlier. On the positive side, I do not think there is any general 
hostility towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,

Tuukka


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Иван Комиссаров mailto:abba...@gmail.com>>
Date: Tuesday, 14. September 2021 at 20.49
To: Lars Knoll mailto:lars.kn...@qt.io>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Qbs development
Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.

Ivan



14 сент. 2021 г., в 17:33, Lars Knoll 
mailto:lars.kn...@qt.io>> написал(а):
 Hi,

Let’s also take up the formal part of the request.



On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
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]




On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

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.



Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.



We will also need to consider that the Qt Go

Re: [Development] Qbs development

[Christian Kandeler]

On 9/15/21 1:03 PM, Oswald Buddenhagen wrote:

in this case, you personally instructed the maintainer to do only
minimal maintenance work (which he does an excellent job at). he has
repeatedly made clear that he has exactly *zero* interest in the
strategic direction of qbs, and is letting "the community" duke it out
among itself, exactly as you wished. he provides no guidance whatsoever,
but reserves the right to cut short discussions he finds boring (or
something). the -2 is an override on that institutionalized
indifference.


I think our definition of "guidance" differs. For me, it does not 
involve going into infinite loops of obsessively arguing about points 
that only I care about. I do believe, however, that I am reasonably 
capable of telling a good patch from a bad one and constructive advice 
from self-serving bickering.



Christian

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Oswald Buddenhagen]

On Tue, Sep 14, 2021 at 02:33:04PM +, Lars Knoll wrote:

Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this.


my view is that ivan is being unreasonable (surprise surprise).
most of the recent discussion happened on discord
(https://discord.com/channels/637429340573007873/637430023682261012), so
you'll need to read that to get an unbiased impression.

in a nutshell, though, i think ivan's initial message is revealing
enough - for example, he plainly admits that his documentation doesn't
match the code. that's an automatic -1, and a yellow card for attitude.


the people doing the actual work decide on the direction and individual changes.


one can always find a suitable definition to devalue some particular
kind of work.


The Governance model states the same, the maintainer takes the decision
in case no agreement can be reached.


in this case, you personally instructed the maintainer to do only
minimal maintenance work (which he does an excellent job at). he has
repeatedly made clear that he has exactly *zero* interest in the
strategic direction of qbs, and is letting "the community" duke it out
among itself, exactly as you wished. he provides no guidance whatsoever,
but reserves the right to cut short discussions he finds boring (or
something). the -2 is an override on that institutionalized
indifference.

On Tue, Sep 14, 2021 at 08:44:01PM +0300, Иван Комиссаров wrote:

we can move Qbs out of the Qt Governance Model by moving to GitHub
[...] there were [...] no votes against.


yeah, right.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Denis Shienkov]

Hi Lars, Tuukka,


> I also would very much like you to stay here.

Also, you need to write some blog post about that Qbs right now is not 
dropped, that the community starts working on that. ;)


Because the previous "deprecation" news had a very bad effect on Qbs 
popularity. You are almost killed this nice build system.


So, what sense now to stay on Qt infrastructure (what you can offer to 
us now, what's a goodies ) ? ;)


BR, Denis.

15.09.2021 13:52, Denis Shienkov пишет:


Hi Lars, Tuukka,

> I also would very much like you to stay here.

AFAIK, a main issue here not about of maintenance behaviour. A main 
issue in the access right on the Qbs project. F.e. right now it is 
hard to maintenance the CI integration with the GitHub, to generate 
the pre-compiled releases and other stuff (maybe Ivan can explain a 
betetr).


Also, a main issue is for the CI for the bare-metal toolchains, where 
we need to use the self-runners instead of Docker containers (there 
are impossible to use the dockers).


So, if you want to be Qbs stayed in the QtCompany infrastructure, then 
you need to help us a bit, e.g. provide some separate server resources 
(e.g. two VMs with Linux && Windows OS installed) where we can setup 
all required stuff to work with CI. ;)


Because right now I use own host PC as self-runner for CI, what is 
very bad and non-stable approach.  ;)


BR, Denis

15.09.2021 13:32, Lars Knoll пишет:

Hi Ivan,

I also would very much like you to stay here. QBS is great project 
and something that came out of the Qt work and still has very strong 
ties to it.


I am fully with Tuukka that what we want is to make it a good 
experience and easy for people to work here in the project. Blocking 
other peoples work is certainly not in line with this.


The governance model has the ’no confidence’ clause for a reason and 
if you have tried other means before, I can and will of course 
arrange such a vote.


Cheers,
Lars


On 15 Sep 2021, at 12:18, Tuukka Turunen <mailto:tuukka.turu...@qt.io>> wrote:


Hi,
I would not like Qbs development to move away from the Qt project. 
It is very unfortunate that you have had bad experience and 
misbehavior from one approver. We want to constantly improve the 
experience of working within the Qt project and naturally this kind 
of incidents are not doing that. Therefore, it is very good that you 
have raised the topic in the mailing list, as many were not aware of 
it earlier. On the positive side, I do not think there is any 
general hostility towards Qbs within the Qt projects – on the 
contrary I can see a lot of good co-operation.

Yours,
    Tuukka

*From:*Development <mailto:development-boun...@qt-project.org>> on behalf of Иван 
Комиссаров mailto:abba...@gmail.com>>

*Date:*Tuesday, 14. September 2021 at 20.49
*To:*Lars Knoll mailto:lars.kn...@qt.io>>
*Cc:*Qt development mailing list <mailto:development@qt-project.org>>

*Subject:*Re: [Development] Qbs development

Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt 
Governance Model by moving to GitHub. I have raised this topic on 
our Discord server and the community overall seems positive - there 
were several votes for the migration and no votes against. This 
migration might be healthy to Qbs as a lot of newcomers are not 
familiar with Gerrit but familiar with GitHub and it’s pull-request 
model.
Also, it will clearly separate who can approve/reject patches to Qbs 
and to the rest of Qt world.
If there are no objections, I will create an INFRA issue about the 
migration - it should not be very hard to do.

Ivan


14 сент. 2021 г., в 17:33, Lars Knoll mailto:lars.kn...@qt.io>> написал(а):

 Hi,
Let’s also take up the formal part of the request.


On 13 Sep 2021, at 22:59, Иван Комиссаров mailto:abba...@gmail.com>> wrote:
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]



On 14 Sep 2021, at 12:34, Richard Weickelt
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

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.



Ivan and Richard, do I understand you correctly that you’

Re: [Development] Qbs development

[Denis Shienkov]

Hi Lars, Tuukka,

> I also would very much like you to stay here.

AFAIK, a main issue here not about of maintenance behaviour. A main 
issue in the access right on the Qbs project. F.e. right now it is hard 
to maintenance the CI integration with the GitHub, to generate the 
pre-compiled releases and other stuff (maybe Ivan can explain a betetr).


Also, a main issue is for the CI for the bare-metal toolchains, where we 
need to use the self-runners instead of Docker containers (there are 
impossible to use the dockers).


So, if you want to be Qbs stayed in the QtCompany infrastructure, then 
you need to help us a bit, e.g. provide some separate server resources 
(e.g. two VMs with Linux && Windows OS installed) where we can setup all 
required stuff to work with CI. ;)


Because right now I use own host PC as self-runner for CI, what is very 
bad and non-stable approach.  ;)


BR, Denis

15.09.2021 13:32, Lars Knoll пишет:

Hi Ivan,

I also would very much like you to stay here. QBS is great project and 
something that came out of the Qt work and still has very strong ties 
to it.


I am fully with Tuukka that what we want is to make it a good 
experience and easy for people to work here in the project. Blocking 
other peoples work is certainly not in line with this.


The governance model has the ’no confidence’ clause for a reason and 
if you have tried other means before, I can and will of course arrange 
such a vote.


Cheers,
Lars


On 15 Sep 2021, at 12:18, Tuukka Turunen <mailto:tuukka.turu...@qt.io>> wrote:


Hi,
I would not like Qbs development to move away from the Qt project. It 
is very unfortunate that you have had bad experience and misbehavior 
from one approver. We want to constantly improve the experience of 
working within the Qt project and naturally this kind of incidents 
are not doing that. Therefore, it is very good that you have raised 
the topic in the mailing list, as many were not aware of it earlier. 
On the positive side, I do not think there is any general hostility 
towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,
    Tuukka

*From:*Development <mailto:development-boun...@qt-project.org>> on behalf of Иван 
Комиссаров mailto:abba...@gmail.com>>

*Date:*Tuesday, 14. September 2021 at 20.49
*To:*Lars Knoll mailto:lars.kn...@qt.io>>
*Cc:*Qt development mailing list <mailto:development@qt-project.org>>

*Subject:*Re: [Development] Qbs development

Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt 
Governance Model by moving to GitHub. I have raised this topic on our 
Discord server and the community overall seems positive - there were 
several votes for the migration and no votes against. This migration 
might be healthy to Qbs as a lot of newcomers are not familiar with 
Gerrit but familiar with GitHub and it’s pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs 
and to the rest of Qt world.
If there are no objections, I will create an INFRA issue about the 
migration - it should not be very hard to do.

Ivan


14 сент. 2021 г., в 17:33, Lars Knoll mailto:lars.kn...@qt.io>> написал(а):

 Hi,
Let’s also take up the formal part of the request.


On 13 Sep 2021, at 22:59, Иван Комиссаров mailto:abba...@gmail.com>> wrote:
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]



On 14 Sep 2021, at 12:34, Richard Weickelt
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

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.



Ivan and Richard, do I understand you correctly that you’d like
to have a formal vote of no confidence according to QUIP-2?
Please understand that this clause is meant as a last resort,
when other solutions have failed.


We will also need to consider that the Qt Governance Model only
defines global Approver rights for all of the Qt Project. The
request was however limited to QBS, so we would need to find a
way to handle this. I can only see two options there, either we
start extending our governance model here (can be do

Re: [Development] Qbs development

[Lars Knoll]

Hi Ivan,

I also would very much like you to stay here. QBS is great project and 
something that came out of the Qt work and still has very strong ties to it.

I am fully with Tuukka that what we want is to make it a good experience and 
easy for people to work here in the project. Blocking other peoples work is 
certainly not in line with this.

The governance model has the ’no confidence’ clause for a reason and if you 
have tried other means before, I can and will of course arrange such a vote.

Cheers,
Lars


On 15 Sep 2021, at 12:18, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

I would not like Qbs development to move away from the Qt project. It is very 
unfortunate that you have had bad experience and misbehavior from one approver. 
We want to constantly improve the experience of working within the Qt project 
and naturally this kind of incidents are not doing that. Therefore, it is very 
good that you have raised the topic in the mailing list, as many were not aware 
of it earlier. On the positive side, I do not think there is any general 
hostility towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,

Tuukka


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Иван Комиссаров mailto:abba...@gmail.com>>
Date: Tuesday, 14. September 2021 at 20.49
To: Lars Knoll mailto:lars.kn...@qt.io>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Qbs development
Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.

Ivan


14 сент. 2021 г., в 17:33, Lars Knoll 
mailto:lars.kn...@qt.io>> написал(а):
 Hi,

Let’s also take up the formal part of the request.


On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
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]



On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

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.


Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.


We will also need to consider that the Qt Governance Model only defines global 
Approver rights for all of the Qt Project. The request was however limited to 
QBS, so we would need to find a way to handle this. I can only see two options 
there, either we start extending our governance model here (can be done with a 
lazy consensus on that extension), or change the scope to the whole project 
having much more severe implications.




Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this. As I stated in my previous mail in this thread, I strongly 
believe, that the people doing the actual work decide on the direction and 
individual changes. The Governance model states the same, the maintainer takes 
the decision in case no agreement can be reached. As far as I can see, your 
actions are conflicting with this.


Thank you,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Tuukka Turunen]

Hi,

I would not like Qbs development to move away from the Qt project. It is very 
unfortunate that you have had bad experience and misbehavior from one approver. 
We want to constantly improve the experience of working within the Qt project 
and naturally this kind of incidents are not doing that. Therefore, it is very 
good that you have raised the topic in the mailing list, as many were not aware 
of it earlier. On the positive side, I do not think there is any general 
hostility towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,

Tuukka


From: Development  on behalf of Иван 
Комиссаров 
Date: Tuesday, 14. September 2021 at 20.49
To: Lars Knoll 
Cc: Qt development mailing list 
Subject: Re: [Development] Qbs development
Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.

Ivan


14 сент. 2021 г., в 17:33, Lars Knoll  написал(а):
 Hi,

Let’s also take up the formal part of the request.


On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
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]



On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

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.


Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.


We will also need to consider that the Qt Governance Model only defines global 
Approver rights for all of the Qt Project. The request was however limited to 
QBS, so we would need to find a way to handle this. I can only see two options 
there, either we start extending our governance model here (can be done with a 
lazy consensus on that extension), or change the scope to the whole project 
having much more severe implications.




Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this. As I stated in my previous mail in this thread, I strongly 
believe, that the people doing the actual work decide on the direction and 
individual changes. The Governance model states the same, the maintainer takes 
the decision in case no agreement can be reached. As far as I can see, your 
actions are conflicting with this.


Thank you,
Lars


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Иван Комиссаров]

Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.
 
Ivan

> 14 сент. 2021 г., в 17:33, Lars Knoll  написал(а):
> 
>  Hi,
> 
> Let’s also take up the formal part of the request.
> 
>>> On 13 Sep 2021, at 22:59, Иван Комиссаров  wrote:
>>> 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]
>> 
>> 
>> On 14 Sep 2021, at 12:34, Richard Weickelt  wrote:
>> The question is whether this is an abuse of approver rights.
>> 
>> 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.
> 
> 
> Ivan and Richard, do I understand you correctly that you’d like to have a 
> formal vote of no confidence according to QUIP-2? Please understand that this 
> clause is meant as a last resort, when other solutions have failed.
> 
> We will also need to consider that the Qt Governance Model only defines 
> global Approver rights for all of the Qt Project. The request was however 
> limited to QBS, so we would need to find a way to handle this. I can only see 
> two options there, either we start extending our governance model here (can 
> be done with a lazy consensus on that extension), or change the scope to the 
> whole project having much more severe implications.
> 
> 
> Ossi, I (and probably others on this mailing list) would also like to hear 
> your view on this. As I stated in my previous mail in this thread, I strongly 
> believe, that the people doing the actual work decide on the direction and 
> individual changes. The Governance model states the same, the maintainer 
> takes the decision in case no agreement can be reached. As far as I can see, 
> your actions are conflicting with this.
> 
> Thank you,
> Lars
> 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Lars Knoll]

Hi,

Let’s also take up the formal part of the request.

On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
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]


On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

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.

Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.

We will also need to consider that the Qt Governance Model only defines global 
Approver rights for all of the Qt Project. The request was however limited to 
QBS, so we would need to find a way to handle this. I can only see two options 
there, either we start extending our governance model here (can be done with a 
lazy consensus on that extension), or change the scope to the whole project 
having much more severe implications.


Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this. As I stated in my previous mail in this thread, I strongly 
believe, that the people doing the actual work decide on the direction and 
individual changes. The Governance model states the same, the maintainer takes 
the decision in case no agreement can be reached. As far as I can see, your 
actions are conflicting with this.

Thank you,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Lars Knoll]

> On 14 Sep 2021, at 12:34, Richard Weickelt  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).

Cheers,
Lars



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Richard Weickelt]

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

The question is whether this is an abuse of approver rights.

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.

Richard Weickelt
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Edward Welbourne]

Jason McDonald (14 September 2021 08:04) replied:
> 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.

Likewise - and thank you for stepping in.

On Tue, 14 Sept 2021 at 07:01, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
>> 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].

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

>> 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...
[snip]
> It has also been my experience that architectural errors are almost
> always vastly more difficult and costly to repair than coding errors.

Indeed, always important to keep an eye on architecture.

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

Just for the sake of clarity, I should point out that QBS isn't a Qt
module, it's a build system, that TQtC started but later decided not to
continue with; members of the community have now adopted it.  It is thus
not part of the same release process as Qt at large, so not tied to the
same major version schedule, and it's not a library.  I don't know what
its existing compatibility promises are, but I can believe it may have
more flexibility than a Qt core library !

That's not to say that architectural considerations are any less crucial
as a result, only that perhaps there is more scope for fixing later and
thus for letting one of the principal contributors to the project
exercise his own judgement on how to move forward and what compromises
are acceptable between short-term progress and long-term structure.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Tuukka Turunen]

Hi,

Not taking a stand to this particular issue, we in general are sometimes not 
very good in taking incremental steps. If some review becomes very long, taking 
months to complete, it rarely is the best way to tackle the issue. It can be 
better to split to multiple smaller items and progress those separately (noting 
that sometimes it is not possible). In some cases it would be better to first 
merge a partial solution that improves from current state – and then take one 
or more additional steps to reach the end goal.

Yours,

Tuukka

From: Иван Комиссаров 
Date: Monday, 13. September 2021 at 23.59
To: Qt development mailing list 
Cc: Lars Knoll , Tuukka Turunen , 
Oswald Buddenhagen , Christian Kandeler 

Subject: Qbs development
Hello everybody

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

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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Jason McDonald]

On Tue, 14 Sept 2021 at 07:01, Иван Комиссаров  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 

[Development] Qbs development

[Иван Комиссаров]

Hello everybody

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

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___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development