Use list both ways

[Luc Schrijvers]

Hello,

As one of the team members of haikuports I am mostly (lately) in charge of
keeping KDE related work (also trying to keep up on the latest Qt6 release
cycle).
For this we have got a few scripts to update our local recipes to build KF6
and gear related packages, some Haiku specific changes have already been
upstreamed and we are pretty much on par with things, so not much to add
for the time being. Having said that, there are still some patches on our
side that are too Haiku specific to upstream and were rejected upstream, so
we keep them in our repository.

In regards to how things are being done in other OS's, I still find
repology a major asset to check how others do it, another source are the
matrix channels where the community has been a great help so far.

Greetings,
Luc aka Begasus

Op zo 20 sep 2026 om 15:43 schreef Martin Steigerwald <martin at lichtvoll.de>:

> Greetings.
>
> During his talk "Packaging KDE on Debian"¹ Sandro brought up there is not
> much communication about downstream backports and other downstream work
> towards upstream again. And also that coordination between different
> distributions is rare.
>
> I wondered whether it would make sense to use this list both ways. So far
> it has mostly been used for upstream to communicate important patches or
> hot fixes to downstream vendors. But it also could be used by downstream
> people to communicate backports or other work they did. That way upstream
> people can give feedback or give hints.
>
> What do you think? Would that be useful?
>
> This list is quite low volume, so I do not see any issue with downstream
> work summaries posted here once in a while. While I think cross-
> distribution coordination may need a different communication channel that
> way a Gentoo developer can more easily see what was done in Debian and
> vice versa as well².
>
> [1] https://conf.kde.org/event/11/contributions/339/
>
> [2] Just an example. Not meant to exclude any distributions or BSD
> variants.
>
> Best,
> --
> Martin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/distributions/attachments/20260920/1c583a65/attachment.htm>