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

[Mike Gabriel]

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).

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200316/ba399880/attachment.sig>