[Development] Qbs development
Denis Shienkov
denis.shienkov at gmail.com
Wed Sep 15 12:52:24 CEST 2021
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 <tuukka.turunen at qt.io
>> <mailto:tuukka.turunen at 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 <development-bounces at qt-project.org
>> <mailto:development-bounces at qt-project.org>> on behalf of Иван
>> Комиссаров <abbapoh at gmail.com <mailto:abbapoh at gmail.com>>
>> *Date:*Tuesday, 14. September 2021 at 20.49
>> *To:*Lars Knoll <lars.knoll at qt.io <mailto:lars.knoll at qt.io>>
>> *Cc:*Qt development mailing list <development at qt-project.org
>> <mailto:development at 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 <lars.knoll at qt.io
>> <mailto:lars.knoll at qt.io>> написал(а):
>>
>> Hi,
>> Let’s also take up the formal part of the request.
>>
>>
>> On 13 Sep 2021, at 22:59, Иван Комиссаров <abbapoh at gmail.com
>> <mailto:abbapoh at 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
>> <richard at weickelt.de <mailto:richard at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210915/96335e3f/attachment-0001.html>
More information about the Development
mailing list