[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, Иван Комиссаров <abbapoh at gmail.com<mailto:abbapoh at 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.