[Development] Debian packaging from Git snapshots (qtsystems, qtfeedback, qtpim)
chris.adams at qinetic.com.au
Tue Mar 17 01:42:11 CET 2020
On Mon, Mar 16, 2020 at 8:49 PM Mike Gabriel <
mike.gabriel at 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.gabriel at 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,
> >> :-(
> >> > In regards to API and ABI stability: QtFeedback has been very stable,
> >> > 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
> >> > 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
> >> > BIC also, e.g. https://codereview.qt-project.org/c/qt/qtpim/+/210812
> >> > one other known work item (which I meant to start this week, but
> >> get
> >> > around to it) is that QtPIM currently doesn't build against dev/qt6,
> >> > some non-SIC porting work is required also. As such, I'm not sure
> >> > strong BIC/SIC guarantees are possible or desirable there at this
> >> 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
> >> 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
> >> > 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
> > or effort with regards to packaging and versioning. I also don't know
> > 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
> > 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
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,
Of course, that would be an option of last resort, in my opinion.
> 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.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development