Re: [Development] Debian packaging from Git snapshots (qtsystems, qtfeedback, qtpim)
On 13/03/20 03:32, Chris Adams wrote: > Regarding maintainership: yes, for QtPIM at least it would be very > beneficial if someone from UBPorts could commit significant time to > QtPIM, as there are some open items there currently and unfortunately I > don't have much capacity to spend on QtPIM at the moment. Alberto > Mardegan has done a lot of work in the QtPIM area previously, and might > be a good candidate if his commitments allow... I'm certainly willing to help, even though I'm not sure about how much "significant time" is needed. On the other hand, looking through https://codereview.qt-project.org/q/qtpim it doesn't look like there's a huge amount of work needed. The problem I see is that it looks like most of the meaningful changes (that is, with API or behavioural changes) come from either you or me, so it would be nice to have more reviewers involved, but I guess we have to live with what we have. :-) Ciao, Alberto ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.15 API review
Hi Everyone, Pretty much same reviews still ongoing, see - https://codereview.qt-project.org/q/message:%2522API+comparison+from+v5.14.0+to+5.15%2522+status:open - https://codereview.qt-project.org/q/topic:%2522plugins.qmltypes+update+for+5.15%2522 Please try to finalize these during this week! br, Jani > -Original Message- > From: Development On Behalf Of > Jani Heikkinen > Sent: tiistai 10. maaliskuuta 2020 11.54 > To: development@qt-project.org > Subject: Re: [Development] Qt 5.15 API review > > Hi all, > > It seems API review is still ongoing and many reviews are missing +2: > - qtbase: https://codereview.qt-project.org/c/qt/qtbase/+/289203 > - qtdeclarative: https://codereview.qt- > project.org/c/qt/qtdeclarative/+/289205 > - qttools: https://codereview.qt-project.org/c/qt/qttools/+/289207 > - qtwebengine: https://codereview.qt- > project.org/c/qt/qtwebengine/+/289212 > - qtquick3d: https://codereview.qt-project.org/c/qt/qtquick3d/+/289214 > > + Few from QML API review: > - qt3d: https://codereview.qt-project.org/c/qt/qt3d/+/291189 > - qtquickcontrols2: https://codereview.qt- > project.org/c/qt/qtquickcontrols2/+/291782 > - qtremoteobjects: ttps://codereview.qt- > project.org/c/qt/qtremoteobjects/+/291783 > - qtdeclarative: https://codereview.qt- > project.org/c/qt/qtdeclarative/+/292657 & https://codereview.qt- > project.org/c/qt/qtdeclarative/+/292664 > > Please fix reported issues and finalize API reviews as soon as possible > > br, > Jani > ___ > From: Jani Heikkinen > Sent: Monday, February 24, 2020 12:31 PM > To: development@qt-project.org > Subject: Qt 5.15 API review > > Hi, > > It seems Qt 5.15 API review is still quite badly ongoing, see > https://bugreports.qt.io/browse/QTBUG-81853 > > * qtbase (https://codereview.qt-project.org/c/qt/qtbase/+/289203): started > but pretty low activity there. > * qtdeclarative (https://codereview.qt- > project.org/c/qt/qtdeclarative/+/289205): started & +1 already > * qtmultimedia (https://codereview.qt- > project.org/c/qt/qtmultimedia/+/289206): started & +1 already > * qttools (https://codereview.qt-project.org/c/qt/qttools/+/289207): started > but pretty low activity there. > * qtlocation (https://codereview.qt-project.org/c/qt/qtlocation/+/289208): > started but pretty low activity there. > * qtconnectivity (https://codereview.qt- > project.org/c/qt/qtconnectivity/+/289209) : started & +1 already > * qtwayland (https://codereview.qt-project.org/c/qt/qtwayland/+/289210) : > started & +1 already > * qt3d (https://codereview.qt-project.org/c/qt/qt3d/+/289211): Not started > at all > * qtwebengine (https://codereview.qt- > project.org/c/qt/qtwebengine/+/289212): started > * qtquick3D (https://codereview.qt-project.org/c/qt/qtquick3d/+/289214): > started > > Please try to do reviews ASAP, thanks! > > BR, > Jani > ___ > 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] Debian packaging from Git snapshots (qtsystems, qtfeedback, qtpim)
Hi Mike, On Sun, Mar 15, 2020 at 5:47 AM Mike Gabriel < mike.gabr...@das-netzwerkteam.de> wrote: > Hi Chris, > > thanks for following up on my questions. > > On Fr 13 Mär 2020 01:32:24 CET, Chris Adams wrote: > > > Hi Mike, > > > > I don't know much / anything about QtSystems, > > Ok... > > > perhaps Lorn has more > > Ok, I'll try to ping him directly via mail. Thanks for the pointer. > > > information about that. > > > > I am currently the maintainer of QtFeedback and QtPIM, although the > amount > > \o/ > > > of time I have to spend on them is currently very limited, unfortunately. > > :-( > > > In regards to API and ABI stability: QtFeedback has been very stable, and > > there are no plans to make any changes there in the near future; > > Ok. That is the signal for me to package QtFeedback directly from Git. > If there'll be a release sometime in the future, I'll be happy to pick > that up. > > > but QtPIM > > has seen far more activity than QtFeedback, and we occasionally have made > > breaking changes there when necessary or desirable (the last big one I > can > > think of was the QContactDetail performance improvements in 2015/2016 > > timeframe). There are some changes in the backlog which might be SIC or > > BIC also, e.g. https://codereview.qt-project.org/c/qt/qtpim/+/210812 and > > one other known work item (which I meant to start this week, but didn't > get > > around to it) is that QtPIM currently doesn't build against dev/qt6, so > > some non-SIC porting work is required also. As such, I'm not sure that > > strong BIC/SIC guarantees are possible or desirable there at this point > in > > time at least. > > Thanks for listing recent changes and plans of the upcoming. > > Apologize my not-knowing (as a non-native speaker)... What do BIC and > SIC stand for? > Binary incompatible changes / source incompatible changes. > > > Regarding maintainership: yes, for QtPIM at least it would be very > > beneficial if someone from UBPorts could commit significant time to > QtPIM, > > as there are some open items there currently and unfortunately I don't > have > > much capacity to spend on QtPIM at the moment. Alberto Mardegan has > done a > > lot of work in the QtPIM area previously, and might be a good candidate > if > > his commitments allow... > > I will bring this up in the next UBports dev meeting. We are currently > running short an wo*man power, but I'll can at least let them know. > > > As for release tags, I am open to such (e.g. major version bumps for > binary > > breaks, minor version bumps for API additions, patch version bumps for > > other fixes / improvements) but I am not sure how that is done, in > > practice, for Qt repositories. Is that something which an external like > > myself can do? What is the process? Or maybe this is something which Qt > > release management would want to handle? > > It seems that at least for QtPIM, some sort of versioning scheme would > benefit the version and API/ABI tracking in Debian. Who can be asked > about that? I fear that is something you might have to add to your > list. Do you think that this is feasible over the next couple of weeks? > I am not sure who on Qt side could help answer this question. As Lorn described, these modules are not officially part of the Qt offering (any more), so I don't think that The Qt Company provide any sort of guarantees or effort with regards to packaging and versioning. I also don't know how such version tags could be added (i.e. do you need write access to the underlying git repository, as opposed to the normal "approval / staging via gerrit" access which I currently have, etc) unfortunately. If there is some simple way for me to add tags to the repo, I'm happy to do that (defining some lightweight process for versioning, and applying tags as appropriate when breaking changes are accepted into the repository, etc). Best regards, Chris. > > Thanks+Greets > Mike > -- > > DAS-NETZWERKTEAM > c\o Technik- und Ökologiezentrum Eckernförde > Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde > mobile: +49 (1520) 1976 148 > landline: +49 (4351) 850 8940 > > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 > mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de > > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] GitHub Pull requests
On Sunday, 15 March 2020 02:30:21 EST Richard Weickelt wrote: > > That's why I asked last month (and still have no official reply) on how > > the Qt Company suggests we use Qt in public CIs, if the binary build is > > locked to Qt Accounts. > > Do you seriously expect to get a reply? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] GitHub Pull requests
> AppVeyor supports Linux, but they support Dot Net on Linux, which isn't > interesting. Travis does not support Windows (or didn't, last I checked). > That means I need both to have the two to support three OSes. Travis supports Windows. The machines are not fast, but it is usually enough. > > GitHub Actions didn't exist until last November. But it doesn't help > right now because their Windows support does not come with Qt > pre-installed, like AppVeyor's does. Building Qt, even if just a minimal > QtCore and QtTest, just to unit-test TinyCBOR, is out of the question. > Did you also read the part where I already spend half my yearly > allocation of TinyCBOR just to maintain the .travis.yml file? Note how > that's using apt-get to install Stephan Binner's builds of Qt for Ubuntu > on Linux and Homebrew on Mac. Imagine having to *build* Qt, on Windows. FWIW: We use Travis to build and test Qbs on all 3 major platforms and the maintenance does not require much effort. https://code.qt.io/cgit/qbs/qbs.git/tree/.travis.yml However, important features like sharing artifacts between stages are still missing and reinstalling all dependencies every time is not always 100% reliable. Although Travis is less popular these days, their UI is still the tidiest I have seen and their open source offering (5 parallel executors) is still very generous. AppVeyor recently started advertising that VM images can be customized. I have not tried it. > That's why I asked last month (and still have no official reply) on how > the Qt Company suggests we use Qt in public CIs, if the binary build is > locked to Qt Accounts. Do you seriously expect to get a reply? Are you a paying customer? Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
