[Development] Qbs development

Lars Knoll lars.knoll at qt.io
Thu Sep 16 09:52:14 CEST 2021


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 <oswald.buddenhagen at gmx.de> wrote:
> 
> On Thu, Sep 16, 2021 at 12:40:37AM +0300, Иван Комиссаров wrote:
>> 15 сент. 2021 г., в 14:03, Oswald Buddenhagen <oswald.buddenhagen at gmx.de> написал(а):
>>> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development



More information about the Development mailing list