X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 48B345C5866 for ; Fri, 27 Oct 2017 15:51:50 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id C473F9E3136; Fri, 27 Oct 2017 15:51:49 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 012599E0126; Fri, 27 Oct 2017 15:51:48 +0000 (GMT) Date: Fri, 27 Oct 2017 17:51:43 +0200 From: Natanael Copa To: Oliver Smith Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] KDE Plasma packaging in Alpine Message-ID: <20171027175143.63245c69@ncopa-desktop.copa.dup.pw> In-Reply-To: <31b20754-2244-780f-8d98-9ed68478db30@bitmessage.ch> References: <31b20754-2244-780f-8d98-9ed68478db30@bitmessage.ch> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 26 Oct 2017 18:57:00 +0000 Oliver Smith wrote: > Dear alpine-devel, >=20 > two derivatives of Alpine Linux, Ad=E9lie 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.). 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. > However, Ad=E9lie 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. 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. > 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. I don't think it is realistic for us to maintain both. We simply don't have resources for that. =20 > 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].) I want help if we have the resources. I'll followup in that thread. Thanks! -nc >=20 > Thanks for reading! > Oliver Smith >=20 > [1]: https://github.com/alpinelinux/aports/pull/2495 > [2]: https://plasma-mobile.org/ > [3]: https://lists.alpinelinux.org/alpine-infra/0184.html >=20 >=20 >=20 > --- > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > Help: alpine-devel+help@lists.alpinelinux.org > --- >=20 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---