Subject: [alpine-devel] KDE Plasma packaging in Alpine

From: Oliver Smith <[email-masked]>
Date: Thu, 26 Oct 2017 18:57:00 +0000

Dear alpine-devel,

two derivatives of Alpine Linux, Adélie and postmarketOS, are working on
getting KDE Plasma upstreamed for Alpine. From the discussions in
#alpine-devel, it seems clear that Alpine developers are not against
including it and both groups are currently working together on
upstreaming KDE Frameworks Tier 1[1] (which is basically the first group
of packages, that makes sense to be upstreamed before the next group
etc.).

However, Adélie needs the LTS version (which makes sense to ship a
stable experience for desktop users), while postmarketOS needs the
latest stable (because plasma mobile[2] is still in development and
depends on that). For some context, I'm involved in the latter project.

This topic came up in #alpine-devel yesterday, and we were told, that we
should take this to the mailing list to get more opinions from Alpine
developers, especially from ncopa.

The question is: Does it make sense for Alpine to ship both versions?

In theory we could implement this by shipping the latest greatest
packages with a "-current" suffix. But then again, KDE Plasma is not
that small and means quite a lot of maintenance effort. The derivatives
would maintain the packages, but for a package or update to land in
Alpine, Alpine devs need to review and approve them, so this means
additional work for Alpine, too.

In case the answer to the question above is "no, let's do LTS only!",
kaniini suggested yesterday, that it could be possible to use Alpine's
building infrastructure to provide builds for the "-current" versions as
unsupported packages. I would also be very interested in opinions
regarding that statement. (Related alpine-infra post[3].)

Thanks for reading!
Oliver Smith

[1]: https://github.com/alpinelinux/aports/pull/2495
[2]: https://plasma-mobile.org/
[3]: https://lists.alpinelinux.org/alpine-infra/0184.html

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Jakub Jirutka <[email-masked]>
Date: Thu, 26 Oct 2017 23:17:18 +0200

Hi,

I guess that there will be many packages depending on KDE Frameworks Tier 1, right? If so, then I’m against including multiple versions in aports, because it would most likely start a domino effect (adding two variants even for some/all depending packages). And before someone suggest it, adding LTS to community and latest only to testing is NOT a solution, it’d be even worse.

I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenance load. So I hope that you will also help us with maintenance.

About LTS or non-LTS: I’d definitely vote for non-LTS, the version needed for postmarketOS. As I know, postmarketOS is purely OSS project not backed by any company; Adélie is backed by a company in advertisement business, so they can invest more resources to maintain it themselves.

postmarketOS needs aarch64 builders, right?

Jakub

> On 26. Oct 2017, at 20:57, Oliver Smith <[email-masked]> wrote:
> 
> Dear alpine-devel,
> 

---

---

From: William Pitcock <[email-masked]>
Date: Thu, 26 Oct 2017 20:16:30 -0500

Hello,

> I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenanc…

I think that it is a very interesting project.
But they have not yet proven that it is a sustainable project, and we
shouldn't preference projects that have no actual plan to make the
project sustainable.
There has been no progress on things that seem very critical, like
making phone calls, and now the discussion seems to be shifting toward
tablets instead of phones.

> About LTS or non-LTS: I’d definitely vote for non-LTS, the version needed for postmarketOS.

Adelie will be using LTS branches.
We can upstream those in Alpine, if wanted, or not.
If the pmOS packages are accepted, we will simply continue to use our
own KDE packages.

> As I know, postmarketOS is purely OSS project not backed by any company; Adélie is backed by a company in advertisement business, so they can invest more resources to maintain it themselves.

This needs clarification.

Adelie is not backed by any pre-existing company, either.

It is however, something we are looking to run in a sustainable way,
which does mean commercial deals that make sense, because revenue
helps fund the work we are doing in Alpine (we have to pay the bills
after all).
But, the business around Adelie is pre-revenue (kinda need a finished
product and a full business plan first you know), and nobody is being
paid to work on it.
We are still figuring that out.

Only some work on Alpine is sponsored, which relates largely to
packaging required to run the business that you're talking about.
But that money is entirely separate, and that business holds no
financial interest in Adelie.
It may, in the future, use Adelie instead of Alpine, but we may use
Fedora or Debian or ArchLinux in the future on those servers.
Who knows.

Adelie both as a company, and as a project, is definitely *Alpine first*.
We want to be good actors in the Alpine community and provide Alpine
with high quality, sustainable work that brings no new technical debt
with it.
To me, and perhaps I am mistaken, but that seems like the exact
opposite of what pmOS is bringing.
They are bringing more technical debt, as you recognize yourself when
you wrote, "So I hope that you will also help us with maintenance."

Finally: I am not sure why it is the responsibility of Alpine to give
pmOS special treatment.
They are a downstream derivative, like Adelie, and they should play by
the same rules.
If you are having to hope that they stick around, that doesn't seem
like a very confident call to be making.

> postmarketOS needs aarch64 builders, right?

Seems to me they need: builders, mirrors, and skilled developers.

We haven't come forward with our KDE packaging for merge yet, to
ensure that the pmOS crew gets full opportunity for review, but it
exists and is working today in Adelie.
I would ask pmOS these questions:

* Are they willing to support the entire KDE desktop in Alpine?
* Will they fix the bugs?
* Do they actually have the capability to deliver on this?

Everyone knows where we stand, and everyone knows that the people
involved all have a proven track record.
With pmOS, it is not yet known.
I suggest reviewing their packages and seeing if they are something
you are willing to sign off on.

William

---

---

From: Oliver Smith <[email-masked]>
Date: Thu, 26 Oct 2017 21:47:00 +0000

Hi,

> I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenanc…

Yes, that would be the plan! craftyguy even volunteered to take the path of becoming an Alpine developer, and kaniini offered to be his mentor (in fact, to anyone from postmarketOS who wants to become an Alpine developer).

> As I know, postmarketOS is purely OSS project not backed by any company

True.

> postmarketOS needs aarch64 builders, right?

Binary packages for x86_64, armhf and aarch64 actually (I've learned, that not all aarch64 builders can produce armhf packages).

PS: Right now we only have packaged plasma mobile related components from KDE plasma. AFAIK we would need a few more components to get the full desktop working. 

Oliver

---

---

From: "A. Wilcox" <[email-masked]>
Date: Thu, 26 Oct 2017 21:58:47 -0500

On 26/10/17 16:17, Jakub Jirutka wrote:
> Hi,
> 
> I guess that there will be many packages depending on KDE 
> Frameworks Tier 1, right? If so, then I’m against including 
> multiple versions in aports, because it would most likely start a 
> domino effect (adding two variants even for some/all depending 
> packages). And before someone suggest it, adding LTS to community 
> and latest only to testing is NOT a solution, it’d be even worse.

Pretty much all KDE applications, and all Tier 2/3 frameworks, will
depend on Tier 1 frameworks.  That's over 300 packages right now in
Adélie.

> About LTS or non-LTS: I’d definitely vote for non-LTS, the version 

I feel like this would be a mistake for Alpine.

First of all, I'm not sure how happy Alpine users would be at `apk
upgrade` breaking their desktop regularly.  Non-LTS releases of KDE
are known to be wildly unstable.  I have been dealing with dot
releases causing startup issues, graphical glitches, and segmentation
faults since the 5.2 release cycle when I was working with the Gentoo
KDE team trying to stablise Plasma 5[1].  It has not gotten any better
as of 5.11.  LTS branches have significant resources devoted to them
and have other distro maintainers watching for bugs as well.  Non-LTS
releases should be considered the same as 'nightly' releases.

We already have a working KDE desktop running right now.  Our copy of
abuild calls 'die' if check() is not defined[2].  I personally run
tests across all architectures that we support (right now, x86_64,
x86_32, and ppc32) for each desktop package before they are pushed to
the mirror.  And those tests are on real hardware, with different
GPUs; in fact, we have a list of computers that we test on[3].

With the exception of 'blair', 'dha', and 'kelsey', all of the listed
machines are in my house.  (I have yet to add the test machines that
horst@, aerdan@, and emyers@ have at their houses.)  The entire team
at Adélie are dead serious about making sure that our packages are
rock solid on varied hardware.

The reason that we have not already upstreamed our KDE work is that we
are still ensuring that it works *everywhere*.  We have a few people
volunteering to try it out on ARM, and I'm trying to bring up PPC64.

Meanwhile, postmarketOS seems to think that qemu passes for testing.
It's a decent enough smoke-test when you are dealing with bootloaders
or you don't have hardware for a niche architecture.  However,
especially when you are dealing with desktop / graphical packages,
qemu is not going to show you problems with Mesa or OpenGL or X11
properly.  It also has a great deal of bugs in its CPU core
emulations; I've personally patched two in the x86 core[4][5] and I
know of more that were too difficult to patch[6].  Additionally, the
PR needed a lot of fixes and showed a lack of familiarity not only
with APK/abuild but also with the frameworks themselves[7].  (I have
yet to review the second version of the PR and therefore cannot
comment on its quality.)  Everyone's new once, and I fully understand
that and support their willingness to learn and grow.  However, I feel
that an Alpine Desktop would be better served by people who are
*already* familiar with abuild, KDE, and contributing to Alpine.  Then
the postmarketOS developers can continue to learn, and they will be
ready to become contributors.

We at Adélie are working upstream with KDE to make their codebase
ready for musl and have been since 2015[8].  I have contact with most
of their reviewers and I am familiar with their code standards and
processes.

I want to bring all of these resources to Alpine upstream and provide
Alpine with a solid, 'fancy' desktop environment beyond XFCE.  And it
would pain me greatly to see both the Alpine and postmarketOS teams
needlessly suffer trying to maintain this large package set when we
already have the experience and the deliverables needed.

(Honestly, I have wondered for a while why postmarketOS does not want
to try and fork Adélie instead of Alpine.  Since KF5 is ABI stable, we
are always tracking the current version of that anyway.  They would
only need to worry about Plasma Next.  This would lower their expended
effort so that they could focus on what makes them different.  It
would also greatly reduce the amount of code with which they need to
become familiar.)

All the best,
- --arw

[1]: For a few fun ones:

https://bugs.gentoo.org/show_bug.cgi?id=570342#c5

Note that this leak was only prevalent on Radeon GPUs using radeon.ko,
so I doubt postmarketOS would even notice that one.

https://bugs.kde.org/show_bug.cgi?id=352951

This isn't even marked fixed, but was shortly before the 5.6
announcement.  5.4 broke it.  (5.8 was the first LTS release.)

https://bugs.kde.org/show_bug.cgi?id=352548

Let's not forget about this fun little show, at least all the
corruption bugs got fixed before 5.8 LTS.  (And the option to switch
GLX <-> EGL was removed entirely.)  5.4 was truly a bad release, heh.

[2]: https://code.foxkit.us/adelie/abuild/commit/9c4e4018

[3]: https://infra.adelielinux.org/

[4]: https://marc.info/?l=freebsd-current&m=142446699801424&w=2 was
introduced by an error in qemu that I submitted a bug report for and
has since been rectified.

[5]: http://lists.openwall.net/linux-kernel/2015/07/08/1045 <
somewhere in this thread is a patch to qemu that I sent to lkml that
allows one to experience this bug in qemu.  qemu was not emulating CR4
correctly based on the -cpu switch, and the kernel bug wasn't caught
because kernel devs were testing older hardware support using qemu
instead of real CPUs.

[6]: While fixing [5] I found a number of deficiencies in qemu's CRx
and MSR support that would have required a significant overhaul to fix
properly.  I never bothered, opting instead of refurbish my Pentium II
system and use it as a crash test dummy for i686 compat.  That same
Pentium II is the computer I first contributed to Alpine with - I
authored the original py-django APKBUILD on it back in 2011.

[7]: See my comments starting at:
https://github.com/alpinelinux/aports/pull/2495#issuecomment-336684141
but note as above that I have not reviewed the new one yet.

[8]: Starting with https://bugs.kde.org/show_bug.cgi?id=352627 ; you
can search their Phabricator and Bugzilla for more work we've done.

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org

---

---

From: Jakub Jirutka <[email-masked]>
Date: Fri, 27 Oct 2017 14:03:05 +0200

Awilfox, thank you for very solid technical arguments!

In the light of these arguments, I changed my mind – I’d prefer LTS version of KDE to non-LTS. Also I support adding KDE packages to Alpine, if Awilfox will help us maintaining them in long-term.

> The entire team at Adélie are dead serious about making sure that our packages are rock solid on varied hardware.
> 
> The reason that we have not already upstreamed our KDE work is that we are still ensuring that it works *everywhere*.  We have a few people volunteering to try it out on ARM, and I’m trying to bring up PPC64.

I think that this is good enough for adding them to the Alpine’s testing repository right after releasing v3.7 (so we can now focus on release).

Jakub

> On 27. Oct 2017, at 4:58, A. Wilcox <[email-masked]> wrote:
> 
> Signed PGP part
> --arw
> --

---

From: Jakub Jirutka <[email-masked]>
Date: Fri, 27 Oct 2017 14:53:08 +0200

I was thinking about desktop environments and I wonder, why did you choose KDE and not Xfce4, LXDE or some other more lightweight alternative? I don’t have experience with linux desktops, but from what I’ve heard, KDE is quite a big and complex beast; it appears to be against Alpine’s philosophy simple and lightweight, isn’t it?

Jakub

> On 27. Oct 2017, at 14:03, Jakub Jirutka <[email-masked]> wrote:
>

---

From: "A. Wilcox" <[email-masked]>
Date: Fri, 27 Oct 2017 12:46:53 -0500

On 27/10/17 07:53, Jakub Jirutka wrote:
> I was thinking about desktop environments and I wonder, why did you
> choose KDE and not Xfce4, LXDE or some other more lightweight 
> alternative?

We are working on packaging LXQt, which is the spiritual successor to
LXDE.  aerdan@ has been successful at making 0.11.x mostly work, but
their latest 0.12 release has proven to be much more tricky.  We are
hopeful that LXQt may be able to be merged in Alpine 3.8 as well.
Note that LXQt does use a few KDE tier 1 frameworks, so that would
need to be merged first.

I have sent some XFCE 4 fixes on to Alpine, but I know that end users
prefer "shiny" and XFCE 4 is not very "shiny".

Additionally, we offer the Alpine fluxbox and openbox packages for
lighter weight window managers.

> I don’t have experience with linux desktops, but from what I’ve 
> heard, KDE is quite a big and complex beast; it appears to be 
> against Alpine’s philosophy simple and lightweight, isn’t it?

KDE 4 was definitely big and complex.  The entire package set of KF5
was a single package, kdelibs4.  They split them up for
maintainability and size reduction.  Now instead of single monolithic
.so or .a taking up resident memory / disk space, the applications can
choose only what they need.  Unfortunately the cost tradeoff is: more
maintainable, better code, but more work for packagers because there
are so many.

I have a 256 MB RAM computer and Plasma 5 runs happily on it.  The
total RAM usage for the entire environment including udisks, upower,
and such: ~ 185 MB RAM.  Not a lot of room left for heavyweights like
a Web browser, but you can certainly fit AbiWord and such.

This is certainly much more bloated than say fluxbox, which I can
squeeze in to 64 MB RAM if I really try, but that is the price you pay
for shiny :)

Overall I feel that KDE (and Qt, to a point) really are unfairly
judged for the sins of their past.  The desktop environment has become
a lot better these days, especially with 5.8 LTS.

Best,
- --arw

- -- 
A. Wilcox (awilfox)

---

---

From: "V.Krishn" <[email-masked]>
Date: Sun, 5 Nov 2017 21:33:27 +0530

> I was thinking about desktop environments and I wonder, why did you choose KDE and not Xfce4, LXDE or some other more lightweight alternative? I don’t have experience with linux desktops, but from…

Would suggest following if really going forward with it,
1. use separate folder in aports tree, eg aports/desktop or aports/kde.
M
2. have its priority lower than aports/testing (only edge build)
3. tag it as a perpetual testing folder
4. this edge build would serve as base for other spins-offs to test and
enhance, thereby giving them market selling point

Try to hold on to Alpine philosophy, but development should progress.
Funny analogy would be Alpine being raw/dark chocolate and Adélie being
Cadbury/Kit-kat/Lindt or... :-)

-- 
Regards,
V.Krishn

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 27 Oct 2017 18:01:08 +0200

On Fri, 27 Oct 2017 14:03:05 +0200

> Awilfox, thank you for very solid technical arguments!

+1

> 
> In the light of these arguments, I changed my mind * I*d prefer LTS
> version of KDE to non-LTS. Also I support adding KDE packages to
> Alpine, if Awilfox will help us maintaining them in long-term.

I prefer LTS too if possible.

We could maybe have the next version of KDE in edge/testing? similar to
what we do with firefox and firefox-esr?

Needs be done carefully though. We did have some confusion with php7 in
community and testing.

> > The entire team at Adélie are dead serious about making sure that
> > our packages are rock solid on varied hardware.
> > 
> > The reason that we have not already upstreamed our KDE work is that
> > we are still ensuring that it works *everywhere*.  We have a few
> > people volunteering to try it out on ARM, and I*m trying to bring
> > up PPC64.  
> 
> 
> I think that this is good enough for adding them to the Alpine*s
> testing repository right after releasing v3.7 (so we can now focus on
> release).

I agree that we should focus on the v3.7 release now.

A. Wilcox: What is the current state of 5.8? Do you think it is
realistic to merge it now and have it working without delaying the v3.7
release too much?

Are you ok to wait til after Alpine 3.7 release and aim for KDE 5.12 in
Alpine v3.8?

-nc

> > > Frameworks Tier 1, right? If so, then I*m against including
> > > and latest only to testing is NOT a solution, it*d be even
> > > worse.  
> > 
> > 
> > > About LTS or non-LTS: I*d definitely vote for non-LTS, the version
> > > needed for postmarketOS.  
> > 
> > 
> > releases causing startup issues, graphical glitches, and
> > segmentation faults since the 5.2 release cycle when I was working
> > with the Gentoo KDE team trying to stablise Plasma 5[1].  It has
> > not gotten any better as of 5.11.  LTS branches have significant
> > resources devoted to them and have other distro maintainers
> > watching for bugs as well.  Non-LTS releases should be considered
> > the same as 'nightly' releases.
> > 
> > We already have a working KDE desktop running right now.  Our copy
> > of abuild calls 'die' if check() is not defined[2].  I personally
> > run tests across all architectures that we support (right now,
> > x86_64, x86_32, and ppc32) for each desktop package before they are
> > pushed to the mirror.  And those tests are on real hardware, with
> > different GPUs; in fact, we have a list of computers that we test
> > on[3].
> > 
> > With the exception of 'blair', 'dha', and 'kelsey', all of the
> > listed machines are in my house.  (I have yet to add the test
> > machines that horst@, aerdan@, and emyers@ have at their houses.)
> > The entire team at Adélie are dead serious about making sure that
> > our packages are rock solid on varied hardware.
> > 
> > The reason that we have not already upstreamed our KDE work is that
> > we are still ensuring that it works *everywhere*.  We have a few
> > people volunteering to try it out on ARM, and I'm trying to bring
> > up PPC64.
> > 
> > It's a decent enough smoke-test when you are dealing with
> > bootloaders or you don't have hardware for a niche architecture.
> > However, especially when you are dealing with desktop / graphical
> > packages, qemu is not going to show you problems with Mesa or
> > OpenGL or X11 properly.  It also has a great deal of bugs in its
> > CPU core emulations; I've personally patched two in the x86
> > core[4][5] and I know of more that were too difficult to patch[6].
> > Additionally, the PR needed a lot of fixes and showed a lack of
> > familiarity not only with APK/abuild but also with the frameworks
> > themselves[7].  (I have yet to review the second version of the PR
> > and therefore cannot comment on its quality.)  Everyone's new once,
> > and I fully understand that and support their willingness to learn
> > and grow.  However, I feel that an Alpine Desktop would be better
> > served by people who are *already* familiar with abuild, KDE, and
> > contributing to Alpine.  Then the postmarketOS developers can
> > continue to learn, and they will be ready to become contributors.
> > 
> > ready for musl and have been since 2015[8].  I have contact with
> > most of their reviewers and I am familiar with their code standards
> > and processes.
> > 
> > I want to bring all of these resources to Alpine upstream and
> > provide Alpine with a solid, 'fancy' desktop environment beyond
> > XFCE.  And it would pain me greatly to see both the Alpine and
> > postmarketOS teams needlessly suffer trying to maintain this large
> > package set when we already have the experience and the
> > deliverables needed.
> > 
> > (Honestly, I have wondered for a while why postmarketOS does not
> > want to try and fork Adélie instead of Alpine.  Since KF5 is ABI
> > stable, we are always tracking the current version of that anyway.
> > They would only need to worry about Plasma Next.  This would lower
> > their expended effort so that they could focus on what makes them
> > different.  It would also greatly reduce the amount of code with
> > which they need to become familiar.)
> > 
> > All the best,
> > --arw
> > 
> > 
> > 
> > [1]: For a few fun ones:
> > 
> > Note that this leak was only prevalent on Radeon GPUs using
> > radeon.ko, so I doubt postmarketOS would even notice that one.
> > 
> > allows one to experience this bug in qemu.  qemu was not emulating
> > CR4 correctly based on the -cpu switch, and the kernel bug wasn't
> > caught because kernel devs were testing older hardware support
> > using qemu instead of real CPUs.
> > 
> > and MSR support that would have required a significant overhaul to
> > fix properly.  I never bothered, opting instead of refurbish my
> > Pentium II system and use it as a crash test dummy for i686
> > compat.  That same Pentium II is the computer I first contributed
> > to Alpine with - I authored the original py-django APKBUILD on it
> > back in 2011.
> > 

---

---

From: "A. Wilcox" <[email-masked]>
Date: Fri, 27 Oct 2017 13:01:14 -0500

On 27/10/17 11:01, Natanael Copa wrote:
> On Fri, 27 Oct 2017 14:03:05 +0200 Jakub Jirutka <[email-masked]>
> wrote:
>> In the light of these arguments, I changed my mind * I*d prefer
>> LTS version of KDE to non-LTS. Also I support adding KDE packages
>> to Alpine, if Awilfox will help us maintaining them in
>> long-term.
> 
> We could maybe have the next version of KDE in edge/testing?
> similar to what we do with firefox and firefox-esr?

I'm not sure what you mean by that, but edge/testing is definitely
where I would want KDE to land until it is known to work well on Alpine.

> Needs be done carefully though. We did have some confusion with
> php7 in community and testing.
> 
>>> The entire team at Adélie are dead serious about making sure
>>> that our packages are rock solid on varied hardware.
>>> 
>>> The reason that we have not already upstreamed our KDE work is
>>> that we are still ensuring that it works *everywhere*.  We have
>>> a few people volunteering to try it out on ARM, and I*m trying
>>> to bring up PPC64.
>> 
>> 
>> testing repository right after releasing v3.7 (so we can now
>> focus on release).
> 
> realistic to merge it now and have it working without delaying the
> v3.7 release too much?

The frameworks are ready.  They're ABI stable and they work flawlessly
on musl.  I have no doubt that they would be fine in v3.7.  However,
that doesn't include the Plasma desktop, just the frameworks... which
may not be very useful without the desktop itself.  See below.

> Are you ok to wait til after Alpine 3.7 release and aim for KDE
> 5.12 in Alpine v3.8?

My main concern is that we still don't have any display manager
capable of launching a KDE session.  So you would need to have
.xinitrc with:

exec ck-launch-session dbus-launch --exit-with-session startkde

This doesn't seem like a very nice way to do things.  I highly doubt
I'll be able to get sddm to work with ConsoleKit2 before v3.7 is done
and released.  After one week of work I have it communicating with CK2
but not yet creating sessions or reading the seats properly.

I can't really speak for 5.12 yet.  We of course feel confident that
it will be a great release, and they have integrated a lot of our work
upstream for it.  However, there's always the chance for some breakage
as there is with any package release.

I don't know when Alpine 3.8 would be shipping and I don't know when a
version freeze would happen and so on.  There's not a lot of
information that I can find that talks about Alpine's release
schedule.  It looks like, based on past releases, the next one would
be in May 2018?  If that is the case KDE 5.12 should be very ready by
then.

FWIW, at the current rate of progress, Adélie 1.0 is probably due for
a release around January 2018.  We plan to bump to kernel 4.14 and KDE
5.12 and then release Adélie 1.5 somewhere in the summer.  That looks
like it would line up pretty cleanly to being based on Alpine 3.8.

No guarantees, obviously, but assuming everything I have said in this
message turns out to happen, we would probably be looking at
upstreaming KDE Plasma 5.12 in to Alpine some time in February.

As I said, I am willing to work on KDE Frameworks (KF5) integration
now but I don't know how useful those would be without something using
them.

All the best,
- --arw

- -- 
A. Wilcox (awilfox)

---

---

From: Oliver Smith <[email-masked]>
Date: Sun, 29 Oct 2017 11:10:00 +0000

Hi there,

I am sorry that awilfox and kaniini had to explain themselves in lengthy posts. I didn't understand the polite pointers you were already giving, which pointed in the direction that the LTS version is suited better for Alpine.

But with all the facts on the table, it is obvious now, that Adelie's team are the experts for getting KDE into Alpine, way beyond what we could have learned about both KDE and Alpine in such a short time. There's no doubt that the LTS version is the better choice.

> would also greatly reduce the amount of code with which they need to

We're not forking any distribution, we want to be an (ideally thin) layer on top and directly use and contribute to the binary packages provided by upstream. To be honest, I didn't know about the ABI stability yet. Basing on Adelie's KF5 packaging does sounds like a good idea and I'll bring it up in the postmarketOS community.

Thanks for all the answers to this thread, I have read them all multiple times and learned a lot!

Best regards,
Oliver

---

From: Natanael Copa <[email-masked]>
Date: Fri, 27 Oct 2017 17:51:43 +0200

On Thu, 26 Oct 2017 18:57:00 +0000

> of packages, that makes sense to be upstreamed before the next group

I am very happy to see that people find Alpine useful for derivative
work. I want try my best to make things easier for both as much
possible.

> depends on that). For some context, I'm involved in the latter

I am more worried about the maintenance work that the initial work
adding new stuff. We ship stable releases and provide bug fixes and
security fixes. To reduce the workload I would think that it makes more
sense to try aim for LTS releases.

> This topic came up in #alpine-devel yesterday, and we were told, that
> we should take this to the mailing list to get more opinions from
> Alpine developers, especially from ncopa.

Thank you for bringing it up. This is sort of a classic problem of
conflict of interest: you have some users that want latest and greatest
features and you have users who wants stability and rock solid.

This the reason why we do the stable releases every 6 months. People
who wants latest and greatest can use 'edge' and people who wants
stability can use stable branch.

I looked at the KDE release history[1] and it looks like:

- current LTS is 5.8 (from October 2016)

- latest stable is 5.11 (October 2017)

- next planned LTS is 5.12 (January 2018)

We have a 3.7-stable just around the corner and I think it may make
sense to wait with the KDE stuff til after the 3.7-stable release and
branch, unless the KDE 5.8 LTS is in a state where it is ready to merge.

Would it make sense to aim for KDE 5.12 for alpine v3.8?

I think I would prefer that.

> The question is: Does it make sense for Alpine to ship both versions?

We ship a main/nodejs (LTS) and a community/nodejs-current.

We ship a testing/firefox and a community/firefox-esr

This adds some extra maintenance work so I would really like to avoid
it if possible.

> additional work for Alpine, too.

I don't think it is realistic for us to maintain both. We simply don't
have resources for that.
 
> regarding that statement. (Related alpine-infra post[3].)

I want help if we have the resources. I'll followup in that thread.

Thanks!

-nc

---