Qt Contributors Summit 2021 - Program: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
mNo edit summary
m (Removing proposal I don't have time to think about)
Line 28: Line 28:
*...and all the good ideas you probably have.
*...and all the good ideas you probably have.
||any
||any
|-
|Passing small objects by value||Volker Hilsheimer (volker.hilsheimer@qt.io)||Most of our existing APIs pass even small types (such as QPoint(F), QRect, QSize) by reference, in spite of [https://web.archive.org/web/20181027220240/https://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ Thiago's analysis] suggesting that those types should be passed by value to avoid memory access. Peppe has started to hand -1's out when reviewing code that introduces new code that passes those by reference. This goal of this session is to get us all on the same page, agree on what this means for our coding standards and tooling that supports that, and conclude whether it's worth and possible to do something about the existing code base.||any
|-
|-
|Wanna help handling oss-fuzz issues?||[https://wiki.qt.io/User:Robert_Loehning Robert Löhning] (robert.loehning@qt.io)||oss-fuzz is [https://wiki.qt.io/Qt_Contributors_Summit_2019_-Fuzzing_Qt fuzzing Qt] since the beginning of 2020. While a number of people contributed to this in various ways (Thank you!), I still seem to be the bottle-neck when it comes to forwarding oss-fuzz' reports to the Qt project as well as documenting affected and fixed versions of Qt. After a brief introduction to oss-fuzz in general, in this talk I'd like to demo what are the required steps. My hope is, that some people will be interested in joining me, so we could share the work, extend the coverage and thus make Qt more secure and reliable.
|Wanna help handling oss-fuzz issues?||[https://wiki.qt.io/User:Robert_Loehning Robert Löhning] (robert.loehning@qt.io)||oss-fuzz is [https://wiki.qt.io/Qt_Contributors_Summit_2019_-Fuzzing_Qt fuzzing Qt] since the beginning of 2020. While a number of people contributed to this in various ways (Thank you!), I still seem to be the bottle-neck when it comes to forwarding oss-fuzz' reports to the Qt project as well as documenting affected and fixed versions of Qt. After a brief introduction to oss-fuzz in general, in this talk I'd like to demo what are the required steps. My hope is, that some people will be interested in joining me, so we could share the work, extend the coverage and thus make Qt more secure and reliable.

Revision as of 11:12, 16 June 2021

Back to Qt Contributors Summit 2021

All times are in Central European Summer Time (CEST)

Talk Proposals

Please add your proposals here before end of day June 16th:

(for proposals to the Akademy program, please submit your proposal at https://akademy.kde.org/2021/cfp by the end of May 2nd)

Topic Who proposed Description/Abstract Preferred timeslot (optional)
Local testing on multiple platforms Volker Hilsheimer (volker.hilsheimer@qt.io) Our CI system Coin makes sure that changes are merged only once they build and pass test runs on all platforms we care about, but for developing cross platform code, nothing beats being able to build, run, and debug your local code before you push your changes to gerrit. In The Qt Company, an increasing number of developers are using minicoin, a vagrant-based system for managing and interacting with virtual machines. As its primary developer I'd like to see how we can make it useful for contributors as well! any
Should Qt have plugin-based I/O? (like KIO but better) Shawn Rutledge (shawn.rutledge@qt.io) QML and Qt Quick have some ad-hoc QNetworkRequest code for fetching qml files and image files from web servers, but it seems a bit short-sighted that this is not done on top of some abstraction for reading files from various kinds of sources. (PDF files are rendered via Image, with this being one reason: to reuse that code rather that duplicating it. QTextDocument should support network loading too: that way it will become possible to load QML Text from a URL, or in widget apps with QTextBrowser, etc.) Http will not always be enough: the distributed web is an up-and-coming concept, and there have always been other protocols for fetching files and assets. Maybe we want to allow loading remote assets in QtQuick3D too, etc. Currently KIO is nicely extensible, but it's not built-in to Qt, and the architecture that requires a separate process for each operation is not ideal. What should we do about it? Another aspect of this is that we should probably have an I/O API in QML eventually; and it should probably follow good asynchronous design principles, and look familiar to Javascript developers. Hopefully it could be built upon the same I/O layer. Therefore we should design the new abstraction to be suitable for that. overflow time should be available (end of the day then?)
Improve the contributor experience of the Qt project 🎉 (Take II) Cristián Maureira-Fredes (cristian.maureira-fredes@qt.io) Back in 2019 we had the discussion around the contribution experience, from which we gather many good ideas: some of them were never addressed, but others have been implemented, like for example the Qt project website and the Community Manager position that was open.

This session will try to address many of the open topics we had from that session looking at "What we could do" to keep improving the experience in topics like:

  • What we can learn from the KDE contribution experience
  • First contribution and initial setup
  • Gerrit improvements, plugins, etc
  • Creation of "good first issues" in JIRA
  • ...and all the good ideas you probably have.
any
Wanna help handling oss-fuzz issues? Robert Löhning (robert.loehning@qt.io) oss-fuzz is fuzzing Qt since the beginning of 2020. While a number of people contributed to this in various ways (Thank you!), I still seem to be the bottle-neck when it comes to forwarding oss-fuzz' reports to the Qt project as well as documenting affected and fixed versions of Qt. After a brief introduction to oss-fuzz in general, in this talk I'd like to demo what are the required steps. My hope is, that some people will be interested in joining me, so we could share the work, extend the coverage and thus make Qt more secure and reliable. any
Wayland client BOF Eskil Abrahamsen Blomfeldt (eskil.abrahamsen-blomfeldt@qt.io) Synchronization on topics concerning the Wayland client plugin with Qt, KDE and others. any
Qt Buildsystem Feedback Alexandru Croitor (alexandru.croitor@qt.io) Qt 6 switched to using CMake for building Qt. The session is meant to gather feedback / pain points about building Qt as well as using Qt in a user project (from a build system perspective). General questions about build system usage are also welcome. any
CMake API for QML modules Ulf Hermann

(ulf.hermann@qt.io)

Let's talk about how we're supposed to write QML modules in Qt 6.2+. It differs quite a bit from what you're used to. any
Testing upstream changes with downstream modules Mitch Curtis

(mitch.curtis@qt.io)

A discussion to find the best solution to the issue of changes in one module (upstream) not being tested with modules (downstream) that depend on that module. any
Changes to Qt WebEngine API and development in Qt 6 Allan Sandfeld Jensen

(allan.jensen@qt.io)

An update and discussion on changes in Qt WebEngine API in Qt 6, and where we are moving from here. any
Wayland text-input-unstable-v4 protocol Eskil Abrahamsen Blomfeldt

(eskil.abrahamsen-blomfeldt@qt.io)

The next iteration of the text-input protocol is currently in specification phase. Qt is lacking in this area, and we should collaborate with the upstream project to make sure we get it right. This is a session to discuss the protocol and get everyone on the same page. any
Documentation test builds in the CI system Paul Wicking / Topi Reiniö

(documentation.infrastructure@qt.io)

Every release of Qt brings with it a lot of "fire fighting" in terms of getting rid of QDoc's warnings across all modules. We propose to block changes that introduce QDoc warnings in CI. This is a session to discuss the proposed solution to the problem. any
Qt Creator Feedback Kai Köhne (kai.koehne@qt.io), Alessandro Portale (alessandro.portale@qt.io) Let's talk about the current state of Qt Creator, and where it's heading. Please join if you have feedback or (constructive) opinions on Qt Creator :) any
Qt for Python Friedemann Kleint (Friedemann.Kleint@qt.io) Let's talk about what can be improved in Qt for Python and how you can contribute any
Moving to qt6.git Volker Hilsheimer (volker.hilsheimer@qt.io) Wrap up the mailing list discussion from https://lists.qt-project.org/pipermail/development/2021-January/040855.html and QTQAINFRA-4200 any
Qt Conan packages Iikka Eklund (iikka.eklund@qt.io), Toni Saario (toni.saario@qt.io), Tino Pyssysalo (tino.pyssysalo@qt.io) The plan to provide Conan packages for Qt6 modules. Discussion about the current state where we are and where we aim for. early afternoon
Qt Bluetooth Andreas Buhr (Andreas.buhr@qt.io), Alex Blasche (alexander.blasche@qt.io) Let's talk about the current state of the Qt Bluetooth port to Qt 6 an the changes it brings along before lunch or early afternoon
Qt Property Bindings Andreas Buhr (andreas.buhr@qt.io), Sona Kurazyan (sona.kurazyan@qt.io), Fabian Kosmale (fabian.kosmale@qt.io), Ivan Solovev (ivan.solovev@qt.io) One of the major changes in Qt 6 are the introduction of bindungs for QProperties. This talk will outline why you should care about them and how to add them to a Qt 6 class. Finally we would like to welcome feedback on experiences you may already have made by using them. any
Git submodules Ville Voutilainen (ville.voutilainen@qt.io) We use submodules in our qt5 git repository, which has its pros and cons. This talk will provide ruminations and a critical look at whether that's a reasonable approach, and whether we should perhaps reconsider our submodule approach. any


Tuesday, 2021-06-22

Wednesday, 2021-06-23