Re: [Development] Nominating Jøger Hansegård for approver rights

[Topi Reiniö via Development]

+1

From: Development  on behalf of Matthias 
Rauter via Development 
Sent: Tuesday, March 26, 2024 10:12 AM
To: development 
Subject: Re: [Development] Nominating Jøger Hansegård for approver rights

+1 

From: Development  on behalf of Tor Arne 
Vestbø via Development 
Sent: Thursday, March 14, 2024 10:06 AM
To: development 
Subject: [Development] Nominating Jøger Hansegård for approver rights

Hi,

I would like to nominate Jøger Hansegård for approver rights in the Qt project.

Jøger joined The Qt Company 10 months ago and has since then been getting his 
hands dirty in Qt Multimedia, and lately focusing on color management.

Jøger is a thorough and responsible engineer and I trust that he will make a 
good approver for the Qt project.

Authored changes: 
https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io
Reviews: https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io

Cheers,
Tor Arne
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How to document API only deprecated in future Qt versions

[Topi Reiniö via Development]

> I'm not sure how viable this is, it's just an idea off the top of my head: we 
> could perhaps implement support
> for "from/until" e.g. in the class members section, similar to what's on 
> cppreference.com (e.g. void foo()
> [since 5.15, until 6.5]). The docs for something that's gone could then 
> possibly link to the published docs for
> the last version (defined by whatever sets the "until" version) that 
> particular feature is documented in, such
> that the members list for e.g. 6.7 would carry members that don't exist in 
> 6.7 but link to the last known state
> of that member. Then we could drop the -obsolete pages entirely (they 
> sometimes confuse  search engines,
> so that's an argument in favor of getting rid of them) and we'd point users 
> of older Qt versions to versions of
> the docs that are possibly more relevant for them anyway.

Yes, having QDoc support both 'since' and 'until', presented in the same 
context, would be an improvement.
Potentially, QDoc could also parse the deprecation macros and apply them to 
documentation, or ideally,
warn the author about missing deprecation docs. This would be useful to ensure 
that the 'use this instead'
information, as mentioned by Eddy, is available. Dropping deprecated docs in 
favor of linking to old archives
would mean we'd likely lose that bit of useful info. There's a benefit of 
having all the docs in a self-contained
set as well.

-Topi

From: Development  on behalf of Paul 
Wicking via Development 
Sent: Friday, September 15, 2023 11:25 AM
To: Edward Welbourne 
Cc: development@qt-project.org 
Subject: Re: [Development] How to document API only deprecated in future Qt 
versions



On 15 Sep 2023, at 10:44, Edward Welbourne via Development 
 wrote:

On 9/15/23 09:36, Kai Köhne via Development wrote:
The methods are formally marked as deprecated for Qt 6.10. But the
methods are already in the '-obsolete' page for Qt 6.6, which leaves
the API in a weird in-between state.

Christian Kandeler (15 September 2023 10:31) wrote:
Radical idea: Treat all deprecated functions as if they didn't exist,
i.e. remove the documentation entirely. It seems counter-intuitive
that legacy interfaces should take more documentation effort than
current ones. Also, this way, fewer people will even be tempted to
short-sightedly use them.

Tempting as that radical approach is, the temptation you're trying to
prevent is mostly avoided by hiding the docs of deprecated functions on
the -obsolete page; and we do have to think of folk who are trying to
work out what their existing code does.  It's hard to port away from an
old API if you don't have a clear description of what your old code was
achieving by using it, so as to be sure you've achieved the same result
with your use of the new API.  The documentation of a deprecated
function should, also, tell the reader what to use instead, to help them
work that out; they can't read that advice if it's not there.

I'm not sure how viable this is, it's just an idea off the top of my head: we 
could perhaps implement support for "from/until" e.g. in the class members 
section, similar to what's on cppreference.com (e.g. 
void foo() [since 5.15, until 6.5]). The docs for something that's gone could 
then possibly link to the published docs for the last version (defined by 
whatever sets the "until" version) that particular feature is documented in, 
such that the members list for e.g. 6.7 would carry members that don't exist in 
6.7 but link to the last known state of that member. Then we could drop the 
-obsolete pages entirely (they sometimes confuse  search engines, so that's an 
argument in favor of getting rid of them) and we'd point users of older Qt 
versions to versions of the docs that are possibly more relevant for them 
anyway.

//! Paul

Eddy.
--
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] New Qt example development guideline and revamping examples

[Topi Reiniö via Development]

Hi,

Heads up for anyone involved in the work of revamping examples and specifically 
their documentation:

We've updated the guideline for adding an example to a specific category. 
Instead of using the \meta {category} {} command directly, please use 
the newly introduced \examplecategory macro instead. This macro expands to the 
above \meta command and also adds the example to a category-specific group. 
This enables automatic listing of examples per category, as in 
https://doc-snapshots.qt.io/qt6-dev/qtexamplesandtutorials.html#application-examples.

Here's the updated part of the guideline: 
https://wiki.qt.io/Qt6/Example-Guideline#Categorisation

We've already updated existing occurrences in all qt5 submodules.

Thanks!
\topi


From: Development  on behalf of Tuukka 
Turunen via Development 
Sent: Friday, February 3, 2023 4:07 PM
To: Shawn Rutledge ; Qt Development 

Subject: Re: [Development] New Qt example development guideline and revamping 
examples


”The point of examples is to show how to use Qt to do specific things.  Some of 
them are redundant? Well there is not only one way to do things; why should we 
hide something cool just because it’s only the second of several choices? In 
the future I think we will hesitate to write new examples if the risk of 
deletion is so high. ”



On the contrary, target is to make the examples more useful by ensuring all 
examples follow the best practices and improving how they are shown in 
documentation and creator welcome page. No-one want to delete examples that are 
good and useful for our users.



The list I sent is examples that are currently not shown in docs or creator, so 
users are not that likely to find them. We should also think why these examples 
are not shown? Typically this is not by accident, but it has been determined 
that it is better to hide the example.



The list contains 113 examples, so I am sure there are some that would be 
better to fix to meet the example guideline, write the documentation and show 
the example. But for many of these the value as an example is low. Thus is 
better to move to manual tests in case we need it for testing purposes.



Yours,



Tuukka



From: Development  on behalf of Shawn 
Rutledge via Development 
Date: Friday, 3. February 2023 at 15.56
To: Qt Development 
Subject: Re: [Development] New Qt example development guideline and revamping 
examples



On 3 Feb 2023, at 13:56, Tuukka Turunen via Development 
 wrote:



pdf/pdfviewer



Depends which one you mean.  They are all new and maintained at this point.  
There is some redundancy on purpose, because there are multiple PDF-viewing 
components.  So I wouldn’t delete any of them.



quick/delegatechooser



We need to make sure we are showing DelegateChooser somewhere; it’s quite 
useful.  I don’t see it in any other examples.



quick/pointerhandlers



I plan to give the pointerhandlers example some proper docs.  It only recently 
graduated from being a manual test.  It may not look like a “proper desktop 
application” but that’s not the point.



… many more I don’t remember so well, and then...

wayland/custom-extension

wayland/custom-extension/compositor

wayland/custom-extension/cpp-client

wayland/custom-extension/qml-client

wayland/custom-shell/client-plugin

wayland/custom-shell/compositor

wayland/hwlayer-compositor

wayland/minimal-cpp

wayland/server-buffer

wayland/server-buffer/compositor

wayland/server-buffer/cpp-client

widgets/itemviews/flattreeview

widgets/itemviews/storageview

...




As Kimmo mentioned, we should aim to check and move (or remove if not seen 
relevant as a manual test by the module maintainer) these during February.



You are talking about removing them from the manifest, not removing the code, I 
hope? Even so...



The point of examples is to show how to use Qt to do specific things.  Some of 
them are redundant? Well there is not only one way to do things; why should we 
hide something cool just because it’s only the second of several choices?



In the future I think we will hesitate to write new examples if the risk of 
deletion is so high.



Move them to manual tests?  Well that’s better than deleting, but users will 
not tend to find those, because we don’t ship them.



Snippets? I think those should be complete enough to actually run.  Otherwise 
it’s too much work to keep re-verifying that they still work.  And it is more 
useful to users to start with a complete, minimal example that already runs, 
and then add the extra functionality that they want, rather than just some 
stanza of code that got broken at some point along the way.  With QML that’s 
not too hard; so my rule is every QML snippet should be a complete standalone 
file that can run with the qml tool.  But with C++ snippets it’s not convenient 
to make them runnable; so when we convert C++ examples to snippets, we can 
expect them to rot, unless we come up with a way to auto-wrap 

Re: [Development] qdoc help needed: it isn't seeing a function that is clearly there

[Topi Reiniö]

This will be documented in the qdoc manual as well, see 
https://doc-snapshots.qt.io/qt6-dev/13-qdoc-commands-topics.html#fn-command

In the generated class reference, the hidden friend will appear as a 'related 
non-member'.

\topi

From: Development  on behalf of Volker 
Hilsheimer 
Sent: Monday, July 25, 2022 11:28:58 PM
To: Macieira, Thiago 
Cc: development@qt-project.org 
Subject: Re: [Development] qdoc help needed: it isn't seeing a function that is 
clearly there



> On 25 Jul 2022, at 21:27, Thiago Macieira  wrote:
>
> In https://codereview.qt-project.org/c/qt/qtbase/+/422690
> Build:
> https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1658767511
>
> /home/qt/work/qt/qtbase/src/corelib/kernel/qmetatype.cpp:3032: (qdoc) warning:
> clang couldn't find function when parsing \fn int qRegisterMetaType(QMetaType
> meta)
>
> The function exists because it's unit-tested and compiled. Why can't qdoc see
> it? It's a hidden friend, but that's valid C++ and clang should see it.

Hi Thiago,

In clang’s AST, hidden friends are placed like class member functions, so they 
have to be documented like class members, e.g.

\fn int QMetaType::qRegisterMetaType(QMetaType meta)

This is misleading in this case, and outright invalid C++ in case of operators 
as hidden friends, but it works with the latter, and I expect it will make it 
work with this as well.


Volker

___
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] Nominating Andreas Eliasson as Approver

[Topi Reiniö]

+1

Andreas has proved himself to be a valuable contributor and reviewer of 
documentation changes across multiple modules, I'm confident he'd be a good 
approver.

Disclaimer: Andreas is a colleague of mine.

-Topi
--
Topi Reiniö, Principal Documentation Engineer | The Qt Company

From: Development  on behalf of Kai Köhne 

Sent: Friday, June 24, 2022 5:07 PM
To: development@qt-project.org 
Subject: [Development] Nominating Andreas Eliasson as Approver

Hi,

I'd like to propose Andreas Eliasson as an Qt Project Approver.

Dashboard: https://codereview.qt-project.org/dashboard/1009951

Andreas started working on Qt documentation only in February. But since then, 
he did already quite some documentation related patches in various Qt modules. 
He has also been actively reviewing other people's documentation patches. So, I 
see little reason to wait much longer before making him an approver, also 
because getting another documentation approver would be handy in the upcoming 
vacation season

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
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] Nominating Luca Di Sera as approver

[Topi Reiniö]

+1. Luca has already been an invaluable asset to QDoc development among other 
things.

Disclaimer; we're colleagues.

-Topi

Get Outlook for Android

From: Development  on behalf of Paul 
Wicking 
Sent: Tuesday, February 1, 2022 7:04:13 AM
To: development@qt-project.org 
Subject: [Development] Nominating Luca Di Sera as approver

Hi,

I'd like to nominate Luca Di Sera as approver in the Qt Project.

Luca joined The Qt Company as a Software Engineer six months ago. His 
contributions [0] and reviews [1] are steady and of high quality. Some of his 
contributions are in TQtC internal repositories. I particularly appreciate 
Luca's style of communication in reviews, carefully crafted commit messages, 
and his passion for solid and maintainable software architecture. I've come to 
know him as an engineer that quickly found ways to apply himself within the 
team, who is not afraid to share his views, and that contributes to moving 
discussions toward sensible outcomes.

I am convinced Luca will treat the status as Approver with the utmost respect 
in the years to come.

Disclaimer: I am Luca's line manager in TQtC and as such have a close working 
relationship with him.

//! Paul

[0] - https://codereview.qt-project.org/q/owner:luca.disera%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:luca.disera%2540qt.io
___
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] Documentation test builds in CI

[Topi Reiniö]

> How do qtbase module integrations have their docs tested if qdoc is not built 
> at that point?
> I'm guessing there's a pre-provisioned qdoc for each host platform?

Correct. Both qdoc and qtattributionsscanner are provisioned. However, this 
step is run on a single platform only, Ubuntu 20.04 which has the 'TestDocs' 
feature.

-Topi

From: Alexandru Croitor 
Sent: Friday, October 22, 2021 1:02 PM
To: Topi Reiniö 
Cc: development@qt-project.org 
Subject: Re: [Development] Documentation test builds in CI


Hi,
> On 21. Oct 2021, at 21:40, Topi Reiniö  wrote:
>
> Hello!
> The testing cycle in Qt's CI now includes a documentation build step for 
> submodules of the qt5 repository, in dev branch. What this means is that 
> integrations may fail if they introduce new documentation warnings as 
> reported by QDoc, and you are greeted with a "Documentation check failed" 
> message in gerrit.

Cool.

>   * qt/qtbase and qt/qttools already have this step enabled. We're enabling 
> it for the rest of the modules as we clear them of existing warnings. This 
> may take a bit of time as we also need to update the qtbase dependency for 
> some of the less-frequently trafficked repos.

How do qtbase module integrations have their docs tested if qdoc is not built 
at that point?
I'm guessing there's a pre-provisioned qdoc for each host platform?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Documentation test builds in CI

[Topi Reiniö]

Hello!
The testing cycle in Qt's CI now includes a documentation build step for 
submodules of the qt5 repository, in dev branch. What this means is that 
integrations may fail if they introduce new documentation warnings as reported 
by QDoc, and you are greeted with a "Documentation check failed" message in 
gerrit.

To resolve the reported issues, check the documentation on QDoc warnings at 
https://doc.qt.io/qt/qdoc-warnings.html - If you can't figure it out, add 
someone from the documentation team as a reviewer (always a good move when 
touching docs) and we'll do our best to help.

To temporarily disable the doc checks for a module that's under active 
development with a high commit inflow, remove the step from 
/coin/module_config.yaml.

Notes:

  * Testing for broken links is omitted as dependencies to other Qt's 
documentation modules are not available for the test build. These linking 
issues are detected as part of our daily snapshot builds and handled separately.

  * qt/qtbase and qt/qttools already have this step enabled. We're enabling it 
for the rest of the modules as we clear them of existing warnings. This may 
take a bit of time as we also need to update the qtbase dependency for some of 
the less-frequently trafficked repos.

Cheers,

Topi Reiniö | Principal Documentation Engineer | The Qt Company
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Nicholas Bennett as Approver

[Topi Reiniö]

+1

Nick has been doing excellent work dealing with documentation in multiple 
projects.

\topi

From: Development  on behalf of Paul 
Wicking 
Sent: Monday, August 30, 2021 10:02 AM
To: development 
Subject: [Development] Nominating Nicholas Bennett as Approver

Hi all,

I’d like to nominate Nicholas Bennett as approver for the Qt Project.

Nicholas has been working with Qt since he joined the Qt Company as a 
Documentation Engineer at the start of the year. He does stellar work, in my 
opinion, both with his own changes [0] and as a reviewer [1].

I trust he'll use the approver rights responsibly.

[0] - https://codereview.qt-project.org/q/owner:nicholas.bennett%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:nicholas.bennett%2540qt.io

//! Paul
___
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] Qt 6 docs: noexcept and constexpr

[Topi Reiniö]

Hi,

No, those are indeed missing from the generated documentation. QDoc uses 
libclang to parse the C++ sources, and there are cases where C++ 
attributes/specifiers are not exposed in the AST  provided by libclang. It's 
possible to create workarounds for these limitations, but these are yet to be 
implemented.

\topi

From: Development  on behalf of Konstantin 
Shegunov 
Sent: Tuesday, May 4, 2021 1:06 PM
To: Qt development mailing list 
Subject: [Development] Qt 6 docs: noexcept and constexpr

Hi,

Is qdoc supposed to mark the mentioned declarations?

I just checked the Qt 6 docs for the QFlags and it doesn't seem to indicate 
either, although they are declared as such in code. Am I missing something here?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Johanna Vanhatapio as an approver

[Topi Reiniö]

+1

From: Development  on behalf of 
Riitta-Leena Miettinen 
Sent: Wednesday, April 28, 2021 10:22 AM
To: development@qt-project.org 
Subject: Re: [Development] Nominating Johanna Vanhatapio as an approver


Date: Tue, 27 Apr 2021 18:38:01 +
From: Paul Wicking 
To: "development@qt-project.org" 
Subject: [Development] Nominating Johanna Vanhatapio as an approver

Hi all,

I'd like to nominate Johanna Vanhatapio as an approver.
Johanna has been working as a documentation engineer for the Qt Company
for over a year now, focusing on Qt Creator and Design Studio. She works
predominantly with creating both documentation and video tutorials (from
script to recording), and also participates actively in reviewing
documentation patches.

Commits:
https://codereview.qt-project.org/q/owner:johanna.vanhatapio%2540qt.io

Reviews:
https://codereview.qt-project.org/q/reviewer:johanna.vanhatapio%2540qt.io

--
Paul Wicking
R Manager

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
https://qt.io

The Future is Written with Qt
--

+1



Disclaimer: We work on the same project.



Cheers,



Leena



Leena Miettinen

Sr. Documentation Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany

riitta-leena.mietti...@qt.io

www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

[cid:image001.png@01D73C18.5BB68950]

[cid:image002.png@01D73C18.5BB68950]

[cid:image003.png@01D73C18.5BB68950]

[cid:image004.png@01D73C18.5BB68950]

[cid:image005.png@01D73C18.5BB68950]






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

Re: [Development] Nominating Andreas Buhr as approver

[Topi Reiniö]

+1!

From: Development  on behalf of Paul 
Wicking 
Sent: Thursday, April 29, 2021 8:20 AM
To: development 
Subject: [Development] Nominating Andreas Buhr as approver

Hi all,


I’d like to nominate Andreas Buhr as approver for the Qt Project.

Andreas has been working with Qt since he joined the Qt Company as a full-time 
employee in Germany about a year ago. I believe his patches [0] spesk for 
themselves. He has also participated actively in reviewing others’ work [1]. My 
impression is that Andreas holds quality in high regard in production code, 
tests, and in documentation, and that he tirelessly works to further our 
quality in all these areas.

I trust he'll use the approver rights responsibly.

[0] - https://codereview.qt-project.org/q/owner:andreas.buhr%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:andreas.buhr%2540qt.io

//! Paul
___
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] "Examples and demos" component in Jira (QTBUG project)

[Topi Reiniö]

+1. Going through the open bugs under 'Examples and Demos', it was clear that 
out of 149 items, only two fell clearly within the realm of documentation or 
documentation infrastructure, and all were better off with a specific module or 
area as a component. There's also the risk of critical issues not receiving 
immediate attention if they are discovered via an example and only reported 
against that component. We're better off without it.

\topi

From: Development  on behalf of Paul 
Wicking 
Sent: Monday, September 7, 2020 12:27 PM
To: Qt development mailing list ; Product 
Management 
Cc: inter...@qt-project.org 
Subject: [Development] "Examples and demos" component in Jira (QTBUG project)

Hi all,

Documentation engineers are most often not the right assignee for example bugs, 
which end up going stale. I propose to retire the "Examples and demos” 
component.

Bugs in examples are often discovered during package testing, or soon after 
release of a new minor version. In most cases, documentation engineers are the 
wrong assignees for these issues. The QTBUG project requires that all 
components have a default assignee, and Jira chooses the default assignee for 
an issue from its components in alphabetical order. Thus, most issues reported 
against the “Examples and demos” component end up with the Qt Documentation 
Team as the assignee, even if the reporter or triage team adds the component 
the code belongs to. The result is that these issues often receive almost as 
little attention as if they had been without an assignee in the first place. 
They go stale.

I have discussed this problem with the documentation engineers and some of the 
R area leads in TQtC. We believe the component mostly provides 
meta-information. That can be achieved by other means that do not require a 
default assignee. Therefore, we think it’s best to retire the component. The 
Documentation Infrastructure team will triage all "examples and demos” bugs 
during this week, with the goal of assigning the correct components and/or 
teams/maintainers to these tasks. When all tasks are triaged, the component 
will be retired. This means it will not be available when creating a new issue, 
and it will not impact our archives.

--
Paul Wicking
R Manager

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
https://qt.io

The Future is Written with Qt
--

___
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] Nominating Kavindra Palaraja for approvership

[Topi Reiniö]

+1 from me.

\topi

From: Development  on behalf of Paul 
Wicking 
Sent: Thursday, July 11, 2019 5:27 PM
To: development@qt-project.org
Subject: [Development] Nominating Kavindra Palaraja for approvership


Hi all,



I’d like to nominate Kavindra Palaraja as approver. She is a very active 
contributor and reviewer, in particular for documentation related changes, 
focusing on the Qt Automotive platform. She’s a former employee of Trolltech 
and Nokia, and has a lot of experience with Qt’s documentation. Currently, she 
is employed as tech writer for Luxoft.



If you're curious, here's a list of her changes:



https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com



and a list of changes she's on as a reviewer:



https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com





Best,

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

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Topi Reiniö]

+1

\topi

From: Development  on behalf of Volker 
Hilsheimer 
Sent: Thursday, May 16, 2019 4:45 PM
To: Qt development mailing list
Subject: [Development] Nominating Mikhail Svetkin for Approver status

Hi,


I’d like to nominate Mikhail Svetkin for Approver status. He’s been an active 
contributor since March 2018, working on C++11’ifying Qt, contributing to core 
QPA, network code, the QtHttpServer labs project, and right now the integration 
of changes for RTEMS into qtbase.

He’s also been actively helping others with reviews, and does so in a 
professional, respectful, and constructive way that complies with the Code of 
Conduct.

Here’s the list of changes under his current Gerrit account:

  
https://codereview.qt-project.org/#/q/owner:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,z

and a list of changes where he has been reviewing:

  
https://codereview.qt-project.org/#/q/reviewer:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,004c7463725f


Disclaimer: I’m sitting a few offices away from Mikhail in The Qt Company 
office in Oslo, and am also his line manager.


Cheers,
Volker

___
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] Nominating Ryan Chu for Approvership

[Topi Reiniö]

A solid +1 from me.

\topi

From: Development  on behalf of Paul 
Wicking 
Sent: Wednesday, May 15, 2019 1:11 PM
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Approvership

I'd like to nominate Ryan Chu for approvership. He's been an active
contributor since January 2018, working mostly on the Docker-based test
server and network-related code. He is also an active reviewer, and his
manner of communication upholds the values as set forth by the Qt Code
of Conduct.

I know Ryan as a humble and honest person. I trust he will treat this
role with the utmost respect and care, as is required.


If you're curious, here's a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z

and a list of changes he's on as a reviewer:

https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z


Disclaimer: he sits 4 offices down the hall from me, and we're both on
the Core & Network team.


--
Paul Wicking
Documentation Engineer

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
http://qt.io
___
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] Nominating Paul Wicking for Approvership

[Topi Reiniö]

+1



From: Development  on behalf of Martin 
Smith 
Sent: Wednesday, December 12, 2018 12:26:45 PM
To: Simon Hausmann; development@qt-project.org
Subject: Re: [Development] Nominating Paul Wicking for Approvership

+1


From: Development  on behalf of Simon 
Hausmann 
Sent: Wednesday, December 12, 2018 11:58:47 AM
To: development@qt-project.org
Subject: [Development] Nominating Paul Wicking for Approvership

Hi,


I would like to nominate Paul for approvership. He started beginning of 2018 
making changes to docs and reviewing doc changes. Whenever I made changes to 
docs, he has spotted many of my mistakes, so I've had a very good experience 
working with him ;-). I trust him to approve changes he's comfortable with.


If you're curious, here's a list of his changes:


https://codereview.qt-project.org/#/q/owner:%22Paul+Wicking%22,n,z


and a list of changes he's on as a reviewer:


https://codereview.qt-project.org/#/q/reviewer:%22Paul+Wicking%22,n,z




Simon


___
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