Hi,
On Mon, Mar 16, 2020 at 8:49 PM Mike Gabriel < mike.gabr...@das-netzwerkteam.de> wrote: > Hi Chris, > > On Mo 16 Mär 2020 01:55:44 CET, Chris Adams wrote: > > > 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. > > Ah, thanks! > > >> > >> > 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). > > Ok, so let's leave things (untagged) as they are. I do symbols > tracking with my DEB packaging, so I should notice at least BICs (i.e. > removed symbols). > > As the situation is not optimal for these projects (they are core > components of the Ubuntu Phone) would another option be moving the > upstream location away from qt-project.org? > > I am not saying that this should be the goal, I am just wondering how > these code projects can be maintained best (from a distro maintainer's > PoV). > Potentially. The licensing of QtPIM only changed recently (in terms of changes), and Jolla's fork of QtPIM remains LGPLv2.1, so IMO if the upstream were to change, I think taking that version might be a sensible option, as it might attract more contributors / maintainers from commercial side (and developer capacity is currently the bottleneck for improvement, IMO). Of course, that would be an option of last resort, in my opinion. > > 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