[Development] Debian packaging from Git snapshots (qtsystems, qtfeedback, qtpim)

[Chris Adams]

Hi,


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,
> 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.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200317/89f02377/attachment.html>