Re: Elisa Music Player and KDE Applications Bundle
On Wed, Sep 25, 2019 at 08:35:05PM +0200, Matthieu Gallien wrote: > Hello, > > Sorry for my very late answer. > > On Friday, August 2, 2019 2:31:21 AM CEST Michael Pyne wrote: > > On Thu, Aug 01, 2019 at 02:55:16PM -0600, Nate Graham wrote: > > > On 7/28/19 3:06 AM, Matthieu Gallien wrote: > > > > Hello, > > > > > > > > After discussion in Elisa mailing list, we would like to know if it > > > > would be possible to integrate Elisa in the KDE Applications Multimedia > > > > module. > > > > > > > > We hope that would allow to have more regular and predictable releases > > > > for > > > > Elisa. That should help potential contributors know when their > > > > contribution > > > > will be released to users. > > > > > > > > We would use the KDE Applications version to lower the maintenance > > > > burden. > > > > > > > > What do you think ? > > > > As the maintainer of one of the existing KDE Multimedia applications, I > > think it would be a fine idea to integrate Elisa, if nothing else to > > help add some vitality to the overall suite of multimedia apps. > > Maybe we could also ask the promo team some help here ? It could help, but as with everything we do, we would also need to have the time and willingness to be able to describe to promo team what we'd want to achieve, and how we'd be able to help to achieve that (improvements to the app, helping to build a strong user community, or whatever). > > I haven't been able to run Elisa yet but it's already in Extragear and > > being actively developed so I think this would be mostly the matter of > > integrating it into KDE Applications releases. > > > > Does anyone know if there are additional review requirements for modules > > to go from Extragear to Applications? > > I was not able to come to Akademy and I am not sure I have understood the > plan > for the releases of applications made by KDE. > Is something needed to do to integrate Elisa in the future coordinated > releases ? > Can I help achieve that ? So I found the page I was thinking of, at https://community.kde.org/Policies/Application_Lifecycle If I'm understanding it right, the fact that Elisa is in Extragear means it's already been through the review and incubation process described at the link above. That would mean the only 'permission' needed would be the module coordinator for the module you'd want to join (kde-multimedia, here). So the question is "who's the coordinator"... and I'm not entirely sure! I think Harald Sitter has been most active, between Phonon and other multimedia components, but I don't know if we've even needed a coordinator recently. If Harald volunteers I'll defer to him. If not I think we should email release-team@kde.org and I can volunteer to help with shepherding over into kde-multimedia. Regards, - Michael Pyne
Re: Elisa Music Player and KDE Applications Bundle
On Thu, Aug 01, 2019 at 02:55:16PM -0600, Nate Graham wrote: > On 7/28/19 3:06 AM, Matthieu Gallien wrote: > > Hello, > > > > After discussion in Elisa mailing list, we would like to know if it would be > > possible to integrate Elisa in the KDE Applications Multimedia module. > > > > We hope that would allow to have more regular and predictable releases for > > Elisa. That should help potential contributors know when their contribution > > will be released to users. > > > > We would use the KDE Applications version to lower the maintenance burden. > > > > What do you think ? As the maintainer of one of the existing KDE Multimedia applications, I think it would be a fine idea to integrate Elisa, if nothing else to help add some vitality to the overall suite of multimedia apps. I haven't been able to run Elisa yet but it's already in Extragear and being actively developed so I think this would be mostly the matter of integrating it into KDE Applications releases. Does anyone know if there are additional review requirements for modules to go from Extragear to Applications? Regards, - Michael Pyne
Re: KDE Applications: Custom version numbers in depth
On Sun, Jun 23, 2019 at 01:16:33AM +0300, Alexander Potashev wrote: > Hi, > > Recently we discussed if applications that are part of the "KDE > Applications" product should follow the same version numbering system: > yy.mm.patch, e.g. 19.04.2. > > After performing a thought experiment, I came to a conclusion that I cannot > property release, say, ktimetracker-5.0.0 with the current KDE Applications > release process (note the version number is different from the standard > 19.08.0). > > Here is how it goes: > > 1. I want a new app release named ktimetracker-5.0.0 which is logical > because the latest release was something like ktimetracker-4.10.13 > (kdelibs4-based). I think my radical suggestion would be to accept changing the version naming convention for ktimetracker to match KDE Applications. i.e. you'd go straight from 4.10.13 to 19.08 for the first KF5-based release under KDE Applications. I had to do a similar thing for juk and it didn't lead to any notable confusion, and in fact reduced confusion for users who weren't sure what "version" to enter against JuK bugs in bugzilla. It's also easier for me to maintain since Bugzilla versions are created automatically now, the release scripts can take care of tagging in git for me, and so on. You could announce this change as part of the migration to 19.08, which means your beta and RC releases could be done and would be under the KDE Applications scheme. Regards, - Michael Pyne
Re: Help kioslave from KF 5.51.0 always crashes
On Sat, Oct 13, 2018 at 03:34:59PM +0200, Heiko Becker wrote: > Hello, > > with kio-5.51.0 the help kioslave always crashes here, doesn't matter if I > use it via F1, the handbook entry in the menu or in khelpcenter directly > (https://bugs.kde.org/show_bug.cgi?id=399709) > > If I revert > https://cgit.kde.org/kio.git/commit/?id=d428fc8e6447ede81f1e1911d0b66b39265672f3 > > it doesn't crash anymore and it becomes usable again, but admittedly I > don't understand the why yet. I never bothered to reproduce the crash but I have a potential fix (which I did test, and wasn't able to reproduce). See https://phabricator.kde.org/D16189 Regards, - Michael Pyne
Re: KDE Applications 17.11.90 (17.12-rc) packages available for packagers
On Sat, Dec 02, 2017 at 12:47:42PM +0100, Bernhard Rosenkraenzer wrote: > Hi, > 17.11.90 looks good for the most part. > One problem detected while upgrading OpenMandriva packages: > juk fails to compile if libtunepimp headers are installed. > > The bits using it are still using KDE4 APIs, but the cmake files still try to > build those files if libtunepimp headers are found. > > "Fixed" it by uninstalling libtunepimp (seems pretty useless these days > anyway) -- but the proper fix is fixing CMakeLists.txt to not build broken > bits even if the dependencies are there... > > ttyl > bero bero, Thanks for the report. I've modified CMakeLists.txt for now in the Applications/17.12 branch at commit 741957e01c7a0e5bfe9e14f86a66ee87e0da609d. I've verified it builds on my end, hopefully I've caught it in time to make RC but either way it in the 17.12 branch so should make release. In the meantime I will forward port to master and either remove the whole thing or fix it to use the modern libs musicbrainz now recommends. Regards, - Michael Pyne
Re: Mailing list for KDE Applications developers?
On Mon, Sep 04, 2017 at 10:24:06PM +1200, Ben Cooksley wrote: > On Mon, Sep 4, 2017 at 6:00 PM, David Faure <fa...@kde.org> wrote: > > And yet he must have been on kde-cvs-announce, if he has a developer > > account, > > no? (iirc that's automatic). > > It's still automatic yes. > > Sadly, this is a trend i've noticed where people filter their inboxes > aggressively and only pay attention to a limited subset of it. > Everything else either gets read at a much, much later time or is > ignored for eternity. I'm 'guilty' of this myself. But it's either that or have no KDE involvement at all so I don't end up feeling too bad about it. ;) But it is certainly true that it makes it difficult to do an "all-hands call" that are directed at certain large subsets of the developer pool, it's very much an all-or-nothing affair, with either kde-cvs-announce or the various mailing lists which have to be assumed to be under heavy filtering. Regards, - Michael Pyne
Re: Repositories to be dropped for KDE Applications 17.12 since they still use kdelibs4
On Mon, Aug 14, 2017 at 12:01:28AM +0200, Albert Astals Cid wrote: > I created > https://community.kde.org/Applications/17.12_repo_drop_list_kdelibs4 > > This lists the repositories that i could find that are part of KDE > Applications that would be dropped since they still use kdelibs4 in the > master > branch. > > Please double check if the list is right. > > There's questions like > Who do we ask if they want to port it? > What is the status? > and some other custom QUESTION: > > If you know the answer fill it in, if you think you know who can know the > answer, either write their name in the wiki or ask them directly and write > the > answer in the wiki. I've updated the entry for JuK. I wasn't aware that KapiX had started on a port from kdelibs4 to KF5; I'll review that but as long as it's not completely crazy it could serve as a good base. I had already given up on the hard slow of a port and started a rewrite but if KapiX's work gets us closer I will get something in releaseable shape in time for 17.12. Regards, - Michael Pyne
Re: Pre-alert for kdesdk-kioslaves/Frameworks in Applications 17.04
On Sun, Mar 19, 2017 at 10:25:16PM -0400, Michael Pyne wrote: > On Sun, Mar 19, 2017 at 05:23:12PM +0100, Luigi Toscano wrote: > > Luigi Toscano ha scritto: > > Update: Michael reviewed the 3 patches and they are merged now. The kioslave > > work, the HTML looks correct and matches for example the output of kio_man, > > but when loaded into Konqueror the styles and the other images (which comes > > from other kioslaves, like help:/) are not shown. If the generated page is > > saved and the file is loaded, they are shown. I'm puzzled and I'm not sure > > where the problem is, probably not on the kioslave side. > > I think it has something to do with the way KHTML applies CSS styles... > if you manually replace all the help:/ links with the equivalent file:// > links then the images show up find. Actually I spoke too soon. If the kioslave applies this same exact replacement (help:/ -> file://) then the generated HTML does not render properly in Konq. If you take the kioslave output, save it to a file, and then load the file containing the exact output, it works fine in Konq -- even if the CSS and links refer to help:/ instead of file:// Sorry for the noise but unless any KHTML experts are able to help understand why rendering the same exact HTML as a file works, while the same HTML from an kioslave does not, then we'll continue to see this problem. Regards, - Michael Pyne
Re: Pre-alert for kdesdk-kioslaves/Frameworks in Applications 17.04
On Sun, Mar 19, 2017 at 05:23:12PM +0100, Luigi Toscano wrote: > Luigi Toscano ha scritto: > > Hi, > > I ported what's left of kdesdk-kioslaves (kio_perldoc) to Frameworks. There > > are 3 pending reviews for Michael Pyne: > > https://phabricator.kde.org/D5020 > > https://phabricator.kde.org/D5021 > > https://phabricator.kde.org/D5022 > > > > and if he agrees, I would like to merge frameworks into master for 17.04. > > > > I'm sending out this as pre-alert. I'd like to ask an exception if it's not > > possible to complete the reviews before the dependency freeze. > > Update: Michael reviewed the 3 patches and they are merged now. The kioslave > work, the HTML looks correct and matches for example the output of kio_man, > but when loaded into Konqueror the styles and the other images (which comes > from other kioslaves, like help:/) are not shown. If the generated page is > saved and the file is loaded, they are shown. I'm puzzled and I'm not sure > where the problem is, probably not on the kioslave side. I think it has something to do with the way KHTML applies CSS styles... if you manually replace all the help:/ links with the equivalent file:// links then the images show up find. The images seem to be the only problem, the CSS itself can be loaded fine from help:/ (as confirmed by diving into the DOM using the 'Show DOM Tree' plugin). If it's really a KHTML CSS bug I'm not sure how difficult it will be to fix (might be as "simple" as fixing an image loader, but I'm not a KHTML expert). We use generate help:/ instead of file:// in the doc kioslaves on purpose since it points to i18n-localized paths, but for the case of images specifically it may be that they are all common and we can hardcode to doc/HTML/en (or at least, that doing so would be better than nothing). > So, I'm open to ideas: if you think that it's fine as it is (i.e. you can show > something, which is more than the current useless kio which only works for > kdelibs4 applications or through kioclient(4)), then I can merge frameworks > into master. I'm biased but I think it's better than nothing. These kind of features need more/better discoverability though. :( Regards, - Michael Pyne
Re: Plasma 5.7.0 tars
On Mon, July 4, 2016 15:16:05 Harald Sitter wrote: > On Mon, Jul 4, 2016 at 2:29 PM, David Edmundson > > <da...@davidedmundson.co.uk> wrote: > > On Mon, Jul 4, 2016 at 1:20 PM, Sebastian Kügler <se...@kde.org> wrote: > >> On Thursday, June 30, 2016 11:06:46 PM CEST Harald Sitter wrote: > >> > On Thu, Jun 30, 2016 at 4:45 PM, David Edmundson > >> > > >> > <da...@davidedmundson.co.uk> wrote: > >> > > *sigh* seems so. Yet plasma-workspace is from the right branch and > >> > > it's > >> > > done by an automated script(!) > >> > > >> > Haven't we fixed that for beta already? > > > > It was the cached kde_projects.xml that you fixed for the beta > > I hadn't pulled your changes as I needed some of my other local mods to > > get > > round some hardcoded paths. So partly my fault - though I still think it's > > very broken that we get version information from two different sources > > within the same script. > > Yes. I mean no. I am confused. > If the projects.xml says that the stable branch of libkscreen is > Plasma/5.6 we can't simply override that on the release side of > things, l10n would still be generated from the wrong branch so you'd > misalign translations and source. That said, one could do a > consistency enforcement by failing if one of the things in a 'set' > (e.g. kde/workspace) is not in line with the rest. > BUT the plasma bash hell on top of releaseme bypasses most smarts of > releaseme todo with projects processing. In this particular case the > fact that releaseme can release a set (e.g kde/workspace) and handle > it as a 'set' is bypassed by the bash scripts wanting to decide what > to release and then calling tarme in a loop for each project. > > So, assuming that is actually a smart way to do it (which it isn't > since it replicates information from projects.xml and allows for > additional human error and makes tarball creation slower), the bash > script would have to check consistency of the output coming out of > tarme (namely the release_data) and make sure that everything is using > the same branch. Sorry for being late to this, but Marko Käning was actually working on just such a tool, which may be useful here. I don't think he ever put it into one of our repositories but it's available from https://git.reviewboard.kde.org/r/123125/ Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Hotfix for KWallet in the Frameworks 5.22.0 Release
On Sat, May 14, 2016 00:11:21 Luca Giambonini wrote:
> In data lunedì, 9 maggio 2016 14:28:16 CEST, laurent Montel ha scritto:
> > Le lundi 9 mai 2016, 10:59:24 CEST Harald Sitter a écrit :
> > > On Sun, May 8, 2016 at 11:29 PM, Allen Winter <win...@kde.org> wrote:
> > > > Howdy,
> > > >
> > > > Unfortunately my commit b3a95ba0540e01a9bb10db53fc449cc49ce9a9e8 for
> > > > the blowfish backend in kwallet broke things.
> > > >
> > > > See https://bugs.kde.org/show_bug.cgi?id=362805
> > > >
> > > > A patch can be found attached to that bug, or you can get commit
> > > > 87e774825b779ba846315a8b2ffe6479dd9f9814 from frameworks kwallet repo.
> > >
> > > There may be more trouble afoot as we debugged a problem in neon today
> > > that turned out to be probably caused by
> > > 87e774825b779ba846315a8b2ffe6479dd9f9814 and went away when rolling
> > > back to a build of 15e6febac44810b1ee640ffd73cd3ef7d6360527
> > >
> > > https://bugs.kde.org/show_bug.cgi?id=362842
> >
> > Same for me It was necessary to revert to
> > 15e6febac44810b1ee640ffd73cd3ef7d6360527
> >
> > Even with last master it doesn't work.
> > For me it will better to revert to
> > 15e6febac44810b1ee640ffd73cd3ef7d6360527
> > and release it until we understand why it's broken with this 2 last
> > patchs.
> >
> > Regards
> >
> > > HS
>
> Hi,
> the official relese is tomorrow, do we have a proper solution to handle this
> issue? From Anke's mail seems that it works by reverting to the old verison
> from 5.21 (commit: 0d56c68d7a2204a987a5255096d004d5a696c0e5)
> there will be a new package online?
The new package should already be there according to dfaure's email from
Tuesday:
> Done, with current master (0d56c68d7), as discussed in the Hotfix thread.
>
> New version and tarball info:
>
> kwallet v5.22.0-rc2
> a581cb8bd390d88d27e2388fad43c1dc0092266d
> 68a0415364235d38cb58d19accfba5a6e384b269fbb88d3caf3cb6f9c29d40c4
> sources/kwallet-5.22.0.tar.xz
With that said, I have generated some autotests to verify the Blowfish
functionality against the Blowfish official test vectors. The "broken" code in
0d56c68d7 is actually unintentionally correct (the "shuffle" calls must be
included in little-endian mode but not while in big-endian mode apparently --
though I've only tested on a little-endian machine!). I had sent the autotests
to this list while the KDE mail servers were down -- apparently my sender did
not re-send.
If anyone would like to verify the autotests I have attached them here,
otherwise I'll open an RR for after the 5.22.0 release. Either way I will wait
until after master becomes 5.23 to commit, but may be useful for packagers'
testing.
Regards,
- Michael Pynediff --git a/autotests/CMakeLists.txt b/autotests/CMakeLists.txt
index ef921ee..b06ce47 100644
--- a/autotests/CMakeLists.txt
+++ b/autotests/CMakeLists.txt
@@ -1,2 +1,18 @@
+include(ECMAddTests)
+
+find_package(Qt5Test ${REQUIRED_QT_VERSION} CONFIG QUIET)
+
+if(NOT Qt5Test_FOUND)
+message(STATUS "Qt5Test not found, autotests will not be built.")
+return()
+endif()
+
+ecm_add_tests(
+blowfishtest.cpp
+LINK_LIBRARIES Qt5::Test kwalletbackend5
+)
+
+target_include_directories(blowfishtest PRIVATE ${CMAKE_SOURCE_DIR}/src/runtime/kwalletd
+${CMAKE_BINARY_DIR}/src/runtime/kwalletd/backend)
add_subdirectory(KWallet)
diff --git a/autotests/blowfishtest.cpp b/autotests/blowfishtest.cpp
index e69de29..f37a8d0 100644
--- a/autotests/blowfishtest.cpp
+++ b/autotests/blowfishtest.cpp
@@ -0,0 +1,186 @@
+/* This file is part of the KDE libraries
+ * Copyright (c) 2016 Michael Pyne <mp...@kde.org>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Library General Public
+ * License version 2 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Library General Public License for more details.
+ *
+ * You should have received a copy of the GNU Library General Public License
+ * along with this library; see the file COPYING.LIB. If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+ */
+
+#include "backend/blowfish.h"
+
+#include
+#include
+#include
+
+#include
+
+class TestBlowfish : public QObject
+{
+Q_OBJECT
+private Q_SLOTS:
+void testBlowfishCipher();
+};
+
+// Source for test vectors: https://www.schneier.com/code/vectors.txt
+stati
Re: KDE Applications 16.04.0 packages available for packagers
On Sat, April 16, 2016 08:49:10 Ben Cooksley wrote: > On Sat, Apr 16, 2016 at 3:20 AM, Eric Hameleers <al...@slackware.com> wrote: > > I understand that the CI tools need to be able to resolve > > interdependencies. So, why not use CI functionality to generate a global > > dependency list and publish that? It would be an essential first stop for > > everyone trying to compile KDE components. > > If you clone the repository kde-build-metadata from git.kde.org you > will find in the tools folder a script called "list_dependencies". > Once given a branch group (usually kf5-qt5, but for Qt 4 based > software you'll want to use latest-qt4) and the name of the repository > it can spit out the complete list of projects a given tarball / > repository depends on. > > Additional work would be needed to sort this into a build order, but > for those of you whose packaging systems just need to know what to > depend on, that should be quite helpful I think. Actually the list_dependencies tool spits out the dependencies in a satisfactory build order already. By default it outputs all dependencies recursively, but can be set to output only direct dependencies. As far as version-specific dependencies, that's a good point... the dependency set is a moving target after all. But a simple solution might be to simply tag kde-build-metadata along with the rest of KF5 and Plasma 5 when we do a release, as a way to baking in what we thought the dependencies were for each release. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde/workspace git module rename
On Thu, July 2, 2015 12:41:32 David Faure wrote: On Thursday 02 July 2015 10:36:09 Jonathan Riddell wrote: On Tue, Jun 30, 2015 at 12:59:41PM +0200, Martin Gräßlin wrote: On Tuesday 30 June 2015 12:01:47 Jonathan Riddell wrote: projects.kde.org has a module called kde/workspace that's used for Plasma bits. The name term workspace is obsolete and it's confusing having it under kde where all the applications modules are. I'd like to rename it to plasma. I guess this will break kde-srcbuild and maybe other build scripts. Is the tidying up worth the hassle? It will not just break kdesrc-build but also the local src code and build trees on our developer's systems. E.g. I have the structure setup with kdesrc- build and imported the projects into kdevelop using the src, build and install structure generated by kdesrc-build. This change would mean dropping all projects from kdevelop and reimport them, having to deal with branches not being moved to the new git structure, etc. etc. I expect that this would cost me several hours of work on each system (I have a build tree on three to four devices). Assuming that other plasma devs have similar setups we waste several person days just with shuffling repositories around. So given that I think this is not worth the hassle. ok I'll drop the idea then One idea would be a kdesrc-build feature that allows it to keep using a checkout 'at the old place' while it exists, rather than moving to 'the new place' I'm pretty sure this already exists with an explicit put this module in that dir per-module setting, but I mean more generally a global setting that makes kdesrc-build conservative about location when stuff is moved, and the developer would get things in the new place only after deleting the old checkout, if he ever wants to. Or never, if he doesn't delete it ever. That's doable, I guess. Would be a matter of storing the saved srcdir/builddir in the existing persistent data store for each module-name and I don't think it would be very difficult from there, if that's something people would desire. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde/workspace git module rename
On Thu, July 2, 2015 17:37:33 Aleix Pol wrote: I'm pretty sure this already exists with an explicit put this module in that dir per-module setting, but I mean more generally a global setting that makes kdesrc-build conservative about location when stuff is moved, and the developer would get things in the new place only after deleting the old checkout, if he ever wants to. Or never, if he doesn't delete it ever. It would be better if kde-src-build didn't adopt the nested tree. It doesn't buy much and it wouldn't have such problems. https://kdesrc-build.kde.org/documentation/conf-options-table.html#conf-ignore-kde-structure might help if you prefer the dir layout to be flat. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Future frameworks releases
On Mon, June 8, 2015 22:29:16 Mario Fux wrote: Am Montag, 08. Juni 2015, 17.21:56 schrieb Benjamin Reed: Morning On 6/8/15 11:02 AM, Eric Hameleers wrote: The only sane way forward is that every Frameworks release contains all Frameworks tarballs, regardless of updates since the previous public release. Every Framework should adhere to the overall version number. Yeah, this proposal makes no sense to me. Then please read the thread on kde-frameworks-devel as there is some sense in this proposal. We might decide against it in the end but to say that it doesn't make sense is just not valid. If you want to individually manage a library with an independent numbering scheme, then shouldn't it be a separate/external project? The whole point of the framework is to provide a monolithic thing that has everything you need. Either I don't get this sarcasm or you might be wrong. The whole point of KDE Frameworks is that it is _modular_ and not monolithic as kdelibs was. As I see it the value of KDE Frameworks is the set of Qt Addons with a unique license and spreading over different platforms. A high quality set of additional features and libraries for Qt developers from developers with a lot of experience. The modularity is only to a point. For instance a Tier 3 framework module at version x.y is allowed to depend on a version x.y of any Tier 1 or 2 framework modules being installed, without any special capability checks. So while you could in theory distribute a kdefoo x.y (Tier 2) that dependss on kdebar x.y (Tier 1), a distributor distributing kdefoo x.y could not be packaged with kdebar x.(y-1) (even if kdebar didn't actually change). Bumping the installed version of a Tier 1 KDE framework module would require bumping the version of all installed higher-tier framework modules. I think that something like this came up some months ago when the packagers had requested that we distribute KF5 with more granularity (and especially, with a stable branch as proposed for KImap here) and the result was that we'd refused, and instead opted for the current scheme where KF5 is tagged essentially all together based on the reviewed code merged into master. There were good reasons for that decision, though I don't remember the details at this point. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: CHANGELOG keyword
On Sun, October 12, 2014 00:30:43 Albert Astals Cid wrote: once after CHANGELOG: I'm not against an empty CHANGELOG: meaning the tool has to use the title, but i'd still want to have the possibility to have a separate line, my titles are usually more geeky and I would not want them in a public consumption changelog so i'd have to craft something more user-friendly in the CHANGELOG: entry. What do others think? I think allowing CHANGELOG: to have a more descriptive title, while falling back to the commit title if CHANGELOG: is left blank, makes perfect sense and is a good idea. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Wed, May 21, 2014 22:40:07 Alexander Neundorf wrote: On Wednesday, May 21, 2014 16:12:50 Kevin Ottens wrote: On Wednesday 21 May 2014 11:28:45 Aaron J. Seigo wrote: On Wednesday, May 21, 2014 10:17:15 Kevin Ottens wrote: ... This type of branch got actually discussed before making the initial proposal, it's not that we don't like the idea at all, it's that we don't feel confident to make it work at that point in time. Even with a single stable branch owner? Yes, that's the exact option we thought about, but you need someone willing to do the job. shouldn't in theory each library in frameworks have a maintainer, who is responsible for that library, and wouldn't this be the obvious person who maintains also the stable branch of the library ? Sort of (and I would volunteer to do this for the one module I maintain). But not every frameworks module has an assigned volunteer, and not all volunteers would necessarily also want to maintain a separate stable branch. But beyond that, there's also the possible issue that all of these stable branches when integrated together would still have regressions. You'd really still want to have an integration manager to volunteer to ensure the units of Frameworks still work well when combined. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
up with the proposal initially proposed (maybe with some downstream packagers working in common to backport patches they need for their users on our KDE-provided stable branch). - Developers backport safe fixes to the stable branch. this is a critical issue. not enough developers who backport are able to accurately judge this consistently enough. many reasons exist for this (tooling, testing, experience, blah blah) but reasons are just reasons - if we rely on developers to backport safe fixes, it's going to break (because it does already) and that will defeat one aspect of what Kevin is trying to achieve: higher quality there are ways around this, however! it is not uncommon in other projects for people to own a long term branch and only they merge in patches. period. that person needs to be disciplined (so they don't just become a rubber-stamp bureaucrat), but this is one area where having a bottleneck is actually good: you don't WANT lots of changes. you WANT a slow rate of change. you WANT every change to be justified. This might be much better (though I wouldn't judge the current stable process so harshly). It comes down to are there maintainers available?, of course, but it is certainly more doable than the amorphous the community is responsible for stable that we've noticed doesn't work too well already. i honestly don't see having a long term branch working otherwise. and perhaps that's were some of the tension arises: one party is asking for something that doesn't work but which they feel a need for, and the other party doesn't want to do something that doesn't work ;) - For complex changes the can't safely be applied to the stable branch, a new branch off of stable is created and the developer issues a call for testing (maybe on this list). If testing succeeds, it gets merged back to stable. my recommendation: no. don't even try this. such changes get folded into the next feature version. users will survive. Agreed - Updates to the stable branch get released monthly at the same time as the monthly feature release. that's a lot of overhead to cater to a subset of KDE's audience. since the stable branch is supposed to be always stable, is there any reason why distributions that desire that stability couldn't just grab a snapshot whenever their release schedule deems it suitable? I was wondering this myself, but in any event if we're willing to release tarballs which we haven't even manually verified can be built (after all, our packagers will let us know... ;), it wouldn't be much additional overhead I think (i.e. could be almost fully scriptable), as Scott has suggested in his reply. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
On Thu, May 1, 2014 11:13:47 Harald Sitter wrote:
On Thu, May 1, 2014 at 1:33 AM, Michael Pyne mp...@kde.org wrote:
Also ideally, we should break with this tendency of upstream/downstream
and you should become upstream, I would love to see opensuse (and others)
keeping the release you picked maintained in a branch.
I think this is wishful thinking. I mean, it would be nice to have happen
as well, but they can't all have that much extra manpower lying around
with nothing to do. Work they do to act as a virtual upstream is work
they can't do for their downstream duties, so you're asking them to stop
doing something they're doing now to pick up for kde.org duties.
They could just as fairly ask for us to start handing downstream packaging
chores.
But it isn't extra work or different work. It is the work a distro
does anyway. As a distribution you pick a KDE platform release to use
in your next distro release and unless your support cycle perfectly
matches KDE's you then end up pushing patches to this version for your
distribution exclusively because there's not going to be another
official release of that platform version.
Where do those patches that get backported by distros come from? Normally KDE
developers, no? So we still have to originate the patches in the first place.
So let's assume that the distros using a given Frameworks version as a base
all band together to maintain their own LTS of that set to reduce the
workload. We're asking them to take the patches we author, and backport to
their common repository. And to do that they must not accidentally backport
their own distro-specific customizations (if they're cooperating with other
distros for maintenance). And they must also remove any features added in the
interim if necessary, or get a policy exception/review for each such backport.
If they do remove a feature, it may end up being required for some future
bugfix-only commit that they should backport, which would mean that from
their perspective the bugfix-only commit is really a bugfix+feature commit.
We can help automate this by adding keywords like BACKPORT: or BUG:, that's
true, but you still need at the very least a manual review to determine if new
features were added, since we leave it indeterminate. And each distro will
probably have slightly different policies about what upstream bugfixes are
acceptable for their own updated packages, which means that they may not even
necessarily be able to cooperate on maintenance. And $DEITY only forbid that a
bugfix-only patch in Tier 3 ends up silently relying on a previous
feature+bugfix commit in Tier 1 of the same Frameworks version. And none of
this has touched on the possibility of new library additions in the Frameworks
delta between their baseline and where the bugfix is (and possibly needs).
I'm not as sure this would be a ton of work *in practice* as I was thinking
yesterday, but even still, there's quite a wow factor associated with that,
and it raises the potential for a ton of custom integration work just to
backport patches, work that wasn't anywhere near as extensive with KDE 4.
I suspect that the non-rolling distros would on average simply not backport
anything at all but the most serious or simplest bugfixes, assuming they can
review every patch across our 50+ frameworks.
This would help solve our development problems to be sure, but I still really
think that if anyone is going to be doing backporting (as opposed to distro
customizations or integrations) it should be actual @kde.org developers either
doing it or at least reviewing it. Failing that, we should make a concerted
effort to determine if there's some other thing we can feasibly do to help our
packagers out, whether that be commit message tags, Tier {1..4} backport
maintainers to sanity review their backports, hosting cherry-picked stable
branches, etc. As it stands we've just unilaterally attempted to transfer a
lot of the work to the distributions, and the eventual consequences of that
are predictable in a relatively straightforward fashion IMHO.
Regards,
- Michael Pyne
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Thu, May 1, 2014 21:20:06 Sune Vuorela wrote: On Wednesday 30 April 2014 21:39:36 Alexander Neundorf wrote: Especially with all the KF5 bits is versioned bound to each others (so that to fix a bug in one component, you need to update *everything* - are you assuming that or is this indeed the case ? Do all frameworks depend on the same version of all other frameworks, or do they have specific required versions ? I haven't checked how it is done, I have only asked around how it is supposed to be done. The only dependency is that a Tier can depend on a lower Tier. Other than that we've essentially just announced that we're only vouching for the quality of Frameworks as a whole at a given version, although BC and SC compatibility guarantees will be there. Obviously in practice something like kio-5.5 might work just fine with kcoreaddons-5.3, but that's not a guarantee we're advertising in general with Frameworks unless it's listed somewhere else. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
On Wed, April 30, 2014 11:28:26 Àlex Fiestas wrote: As for the backporting, you could use bugzilla (even via api) to get a list of everything that has been fixed, get the SHA and backport it automatically, that will ease a lot the process. Is there any reason we can't do this? Even if it's a good idea to have downstream packagers do the testing of this we can't really think it's a good idea for every downstream to duplicate the work of automatically generating a stable branch and coming up with slightly different KF5 x.y+z releases. In this scenario of automated backporting we would still want to take responsibility for tagging at the very least so that the downstreams have a consistent release to tag against. Also ideally, we should break with this tendency of upstream/downstream and you should become upstream, I would love to see opensuse (and others) keeping the release you picked maintained in a branch. I think this is wishful thinking. I mean, it would be nice to have happen as well, but they can't all have that much extra manpower lying around with nothing to do. Work they do to act as a virtual upstream is work they can't do for their downstream duties, so you're asking them to stop doing something they're doing now to pick up for kde.org duties. They could just as fairly ask for us to start handing downstream packaging chores. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
On Wed, April 30, 2014 15:51:56 Àlex Fiestas wrote: So, I understand that for big releases you wouldn't trust us on no regressions, but please take into account that these releases will be a completely different monster. Finally, could you (or any packager with similar concerns) explain to me which reasons (apart from policy) would make you not comfortable releasing this? I can't speak for them, and the list of problems with our current release policy you have given is on the whole accurate as far as I can see. But I think the problem (besides policy) is that the addition of features or major changes would invalidate the integration and testing work done by the distribution itself. The distribution packagers are not simply trying to package up software and send it over the wall to the build infrastructure to be signed and eventually burned onto an .iso. They also have to make sure the packages play nicely together when bundled together into that coherent whole. We ensure coherence of the frameworks as a whole, generally at any given point in time. The problems raised by our packagers is that even if they want to give us a policy exception and rely completely on *our* guarantee of integration testing, that guarantee only extends to *all* of frameworks at that given point in time. In other words, let's say we release Frameworks 5.11. A non-rolling distro based off of 5.9 would have to upgrade *all* of Frameworks, as a complete bundle, to 5.11 if they wanted to integrate a single package. Even a simple KF5-using application that only uses KCoreAddons (a Tier 1 framework) would necessitate the upgrading of all installed Frameworks, no matter what Tier they are in. And even if they do that, that only gets the quality up to the level *we* have tested it to. I do not think it is surprising that distributions do not want to take on that type of package maintenance burden, or that distributions do not necessarily trust us (with our noted manpower concerns) to release packages where a Tier 1 package could be at 5.16, Tier 2 at 5.15, Tier 3 at 5.13 and a user-compiled application built against Frameworks 5.12, and be able to trust on our processes alone that this would work. This is a pathological example, but it is the guarantee we give, and the guarantee we're now asking distributions to accept. As far as I can tell there are at least 55 separate frameworks at this time. Are you *sure* there are no ways to inadvertently cause breaking bugs in any valid combination of these 55 frameworks when we're adding features? It's hard enough to make this guarantee with stable branches and freeze periods between tagging and making tarballs. Are you sure that new frameworks releases won't have new library dependencies not already present in that distribution's baseline? I do think that any given framework will be that much more likely to integrate well with the process of the new release cycle. And distributions should already be updating KDE packages en masse to avoid the problem of having things like kdelibs 4.11.5 and kde-runtime 4.11.4 around at the same time. But the addition of new features, translations and even library dependency changes is a much different proposal than we've offered before. What's more, the 2 major pieces of software that do get exceptions do so by including many 3rd party libraries with their source release to guarantee integration, which is something we can't get away with, and they have a much more focused task. Is it fair for them to complain (and they're *all* complaining AFAICS). I would like to use the new release cycle because it solves the many acknowledged issues with ours. Is there a way to get the best of both worlds? Maybe have a stable branch that is reset every 6 months and which we frameworks maintainers can cherry-pick bugfixes into for non-rolling distros (say, every 2 months)? Or would even this be too much work? Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Update on git repository logical branch module groups
Hi all, (please keep discussion on core-devel) A couple of weeks ago at Akademy a decision was reached to allow for the changing of the kde-workspace development branch for KF5 efforts to be 'master' (instead of 'frameworks' as in kdelibs). In exchange we would implement a means for users to give a high-level description of what branch they want in general. That is, a way to say that in general, you just want a stable KDE 4, development KDE 4, or bleeding-edge Qt5/KF5-based desktop. I'd like to announce that the groundwork for that system is now in place. There is a file in the kde-build-metadata repository, logical-module- structure, which contains a high-level overview of which branch to use for the KDE Project git repositories, for each of the various overarching groups. Right now there are 3 such groups, also listed in that file. kde-build-metadata also has a sample Python script (in the tools/ subdir) which can be used to verify the file remains valid JSON, and to see what git- branch would be used for a given module and group based on the rules saved into the file. Please use this before committing changes to the file to ensure that things are as you were expecting. ;) kdesrc-build can now also support this data (I still need to add the docs though). The short story is to use the branch-group option to name one of the groups listed in the JSON file, instead of the branch option (if both are set then branch will take precedence, though I'll have to double-check I actually implemented it that way). branch-group obeys normal option precedence semantics within kdesrc-build, so you can set it globally and then override it within a module or module-set. Just remember that if the JSON file doesn't have any rules for a module that the branch 'master' will be assumed. So you could do something like: global branch-group stable-qt4 ... end global module-set reqs repository kde-projects use-modules qt soprano attica cagibi # etc... end module-set # List all desired modules common to KDE 4/KF5 in one file include common-kde-modules.ksbrc and then have a KF5 kdesrc-buildrc with something similar but just change out the branch-group. I intend on having kdesrc-build (and possibly the Python script too) warn about branch-groups that are not actually listed within the layers list of the JSON file as a backup against speling errors. It doesn't do this yet, however. But please make sure that if you decide to add a fourth group or rename the existing ones, that you've updated the layers list in the JSON as well. I'd like for people (especially those working on frameworks or just trying to huddle to KDE 4) to go ahead and test this. On or around the __19th__ I'd like to bake in whatever we consider the names of logical groups to be, so that they are not modified further without discussion on kde-core-devel. (Think of that as a backward-compat concern). I hope this all makes sense, if the feature seems to be evolving in a way other than desired during the discussion at Akademy please let me know. You can find some further documentation on the Community Wiki: http://community.kde.org/Infrastructure/Project_Metadata. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Proposal for branching policy towards KF5
On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. First note: There's a lot of different mailing lists with at least some interest in this discussion, so I've mailed them all for informational purposes... but let's keep the discussion limited to the kde-core-devel mailing list! Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. I didn't want to write another parser, but JSON has no native comment support, so the documentation [1] is on community.kde.org (though perhaps that's for the best). For those with no clue what I'm talking about, the original thread from kde- core-devel is available from [2]. A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. I put the effort into doing this as it would also help make the implementation of some kdesrc-build misfeatures relating to dependency-data additions a bit easier, as there's no need to construct an AST and a parser. Additionally it would permit 'soft' dependencies, which are useful for modules that can utilize optional features but don't have required dependencies on other git modules. However that can, and probably should, be considered separately (though I'll take comments now, if you have them). [1]: http://community.kde.org/Infrastructure/Project_Metadata [2]: http://markmail.org/message/4l3yqerga7mfiit5 Anyways, thanks for your interest and please let me know if this will work to solve the problem at hand. If so I will start on integrating within kdesrc- build, and working with the sysadmins to support within the continuous integration infrastructure. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.11 Release Schedule (bis)
On Tuesday, March 05, 2013 00:43:53 Albert Astals Cid wrote: I'm a bit unsure about 1, 2 and 5. Anyone has extra opinions to share? I'd like to have a finalized schedule for 4.11 next week. In this case my silence was really a I have no opposition to the proposal, so go ahead and put me as a +1 for all of them if that helps your math. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kio_sftp changes to fix reported and discovered data corruption bugs (please review)
Hello, As indicated in the title I've committed a couple of changes ([1], [2]) to kio_sftp to fix some data corruption bugs in time for KDE 4.10. The first is bug 312320 [3], which is where an extra 61440 bytes are added to files that are downloaded and have a size that is an exact multiple of 61440 bytes. I was able to reproduce and although I'm still mystified as to the exact sequence of errors leading to the corrupt file, I can confirm the reporter's proposed fix seems to work. In the sequence of trying to figure out why the fix work I dove into the libssh source code and to cut a long story short, it's not a good idea to mix the async read setup and async read perform calls, which kio_sftp currently does. It's more of a theoretical concern but if this bug is triggered the data corruption will be much more difficult to notice for a user who isn't using checksums or cryptographic hashes. The commit log entries have more details for both. I'm very confident that both changes are at the very least no worse than what was present before given how near we are to 4.10 but I wanted to post the heads-up to the list in case it is decided to revert and aim for 4.10.1 instead. Regards, - Michael Pyne [1] http://commits.kde.org/kde- runtime/7f87a968f622d95b5279fece58a1717d52ba23b9 [2] http://commits.kde.org/kde- runtime/829de23454b3a6bb07641a810bb436ef230d60ef [3] https://bugs.kde.org/show_bug.cgi?id=312320 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
On Friday, December 28, 2012 00:48:51 Albert Astals Cid wrote: We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. Which means someone needs to do a lot of work (lot of work, getting all the new and old versions for more than 100 repos and then running the script and then putting it somewhere in the web) Coding the script is the easy part, finding someone to run and maintain it is the hard part. Of course the great part would be having this run automagically. I guess I was assuming we were already feeding the query output into a separate script already to generate the changelog. As a practical measure I agree with using the KDE SC version for FIXED-IN (which is what I do with JuK, when I work on it), I was more pointing out that the query from Bugzilla is already not the primary source for this particular data (so much as fat-fingering the FIXED-IN line in the commit will drop it from the changelog). Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday, December 27, 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. There's an existing script which figures out how to generate a changelog from the old XML based on a version number which would probably be easy to adapt (and I'd even volunteer to do it, if that would be helpful). The question would be what type of output is needed to make this easy to use (e.g. list of bugs, or ?) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9.5?
On Sunday, December 02, 2012 16:00:33 laurent Montel wrote: Hi, A 4.9.5 is planned ? I need to know for kdepim. I don’t know if I can push in 4.9 branch. According to http://techbase.kde.org/Schedules/KDE4/4.9_Release_Schedule the answer is No. So if it is planned the release dudes haven't updated the plan for it. I would assume that there's no such plan though since 4.10 will be released before a 4.9.5 would be. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: print-manager (kdeutils) has no KDE/4.9 branch
On Monday, October 01, 2012 11:00:27 David Faure wrote: On Sunday 30 September 2012 18:17:56 Albert Astals Cid wrote: El Diumenge, 30 de setembre de 2012, a les 10:20:31, David Faure va escriure: All other git modules that are part of kdeutils have a KDE/4.9 branch, but not print-manager. Is that on purpose? print-manager is not part of 4.9 releases, so it does not have a KDE/4.9 branch. OK so that becomes a kdesrc-build bug. kde_projects.xml indeed has no branchKDE/4.9/branch element for print- manager, as it does for other kdeutils modules. So, IMHO module-set use-modules kde/kdeutils branch KDE/4.9 end module-set should skip print-manager altogether, rather than give a git checkout error. Cc'ing Michael Pyne. Oh wow. Looking at kde_projects.xml it seems it should be doable to figure which branches are available for each kde-projects module to allow for filtering out modules where a given branch is not present. A workaround for now might be the recently-reintroduced use-stable-kde option. Despite what I have in the docs currently (not online but in index.docbook), it should work for individual modules or for module-sets, and should fallback to the master branch if a stable branch is not set for a given module. So it would still be pulled in, but at least it wouldn't be using a non-existent branch. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On Monday, July 16, 2012 22:37:24 Michael Jansen wrote: I do not like maskerading pre releases as stable version. Version numbers have a clear semantic meaning. And KDE currently breaks that. We break what? Our numbers have a clear sematic meaning, i can look at a version number and tell you what it is. Agreed it's not trivial, but saying our numbers don't have a semantinc meaning is not true. Cheers, Albert Any version numbered minor.major.patch is a stable release. That's what we are breaking. Internally there must be a major, minor, and patchlevel number assigned and 4,5,71 is certainly more descriptive of what's going on programmatically than leaving it as something like 4,5,4 (and to parrot what dfaure has said, I've also seen code take good advantage of API added after an alpha release). If we want to call the corresponding named version (in git, tarball name, website, etc.) something like 4.6.0_alpha1 then that's fine and great and all but we can't dump text into our KDE version macros so we still must have a mapping for it. I see in your email from yesterday that you propose an automatically- maintained header-only increasing build number (which could possibly encompass snapshots as well)... is this internal-only build number really to keep the 'purity' of the internal-only patchlevel version? Because that really just seems like a needless change, especially given the large corps of people who are already quite familiar with existing KDE practice regarding internal version numbers. (P.S. Does anyone know how to configure KMail to reply to the plain-text version of an email instead of the HTML rich text version? :) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Changes to the kde-cvs-announce mailing list
On Sunday, July 15, 2012 15:24:04 Albert Astals Cid wrote: Given the list only moderated by people in the USA it might be a problem in some hours/dates if we need to get a notification out in a timely manner (e.g. on 4th of July) Would it make sense get some other moderator onboard from a different geographical position? Or given the number of posts to the list is small we accept the potential time turnaround? As an answer I think I'd lean to 'both'. I.e. I don't anticipate issues with time turnaround for posts to *this* mailing list but at the same time there is no reason not to add a moderator geographically from Europe if one would like to volunteer. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Saturday, July 07, 2012 22:22:38 Michael Jansen wrote: On Saturday, July 07, 2012 04:04:42 PM Michael Pyne wrote: On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote: I think we did it for a time. At least i remember some a new snow storm, a new snapshot commits by dirk. But no idea how they got released/packaged. Yes, you did that in the past and we really disliked it. Could you find out how they were named back then for me? Just for information. Mike I can't recall the names used back then, but I'm pretty sure they included the svn id in the names and dir inside the tarball. I tried asking in #gentoo-kde but no one got back to me so I can't help with that. You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of what they used to look like (packagename-svn-$revno.tar.bz2). This was made easier by later having symlinks available (packagename- svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde- common/release/dosnapshot) but I can confirm it was a pain in the ass from a scripting perspective. Of course for packagers they wouldn't be using Subversion snapshots but plain tarball snapshots, although those suffer the same issues. In fact it was worse because the directory name that was extracted to was unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/). (Sorry for the other empty mail. Wrong button) So there is the problem i couldn't see. The directory name it extracts to is considered to be the same as the name of the archive. Just extracted our kdelibs 4.8.3 package and the dir is kdelibs-4.8.3. Build-tool already solves that problem by always using tar --strip-components=1 --directory=empty dir named like that module. That's why i failed to see the problem. Is that naming a must? I think the issue is less about having the version component in the name and more that if there is a version component, that it is easy to piece toward the tagged version. Gentoo already supports betas, RCs, etc. in Portage though they have a different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in Portage). But in order to support generic KDE snapshots that nomenclature shouldn't change too much across future releases. As long as it's mostly set one time it shouldn't be hard to generically rewrite KDE versions into what is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version to find the tarball!). All the rest is administrivia in my opinion for a packager (they can rely on a good-enough GNU tar since they can enforce its presence). I would just make sure that the only versioning info in *released* snapshot tarballs and directories is the version itself (i.e. no dates, no revision tags or commit ids). For actual Git snapshots Gentoo uses a separate scheme anyways that even uses git directly, so that shouldn't pose much drama. But I don't think that's what's being discussed here. :) A final note: It sounds like we're going towards only releasing changed packages between updates. I think this is a wonderful idea (as I hate rebuilding a hojillion KDE packages on Gentoo just for a minor point release) but it will be very labor-intensive for packagers if we don't essentially do the work for them by listing out what libraries and applications *individual* versions are present in a given KDE SC, for each release. So there would need to be some kind of automated version extraction (perhaps individual module maintainers could provide this until that's available?) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Sunday, July 08, 2012 02:30:13 Michael Jansen wrote: Gentoo already supports betas, RCs, etc. in Portage though they have a different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in Portage). But in order to support generic KDE snapshots that nomenclature shouldn't change too much across future releases. As long as it's mostly set one time it shouldn't be hard to generically rewrite KDE versions into what is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version to find the tarball!). All the rest is administrivia in my opinion for a packager (they can rely on a good-enough GNU tar since they can enforce its presence). I would just make sure that the only versioning info in *released* snapshot tarballs and directories is the version itself (i.e. no dates, no revision tags or commit ids). What is the version of a snapshot? Give an example. For me it is the date. What do you expect it to be? Just snapshot? Keep the misuse of stable version numbers? For a beta or RC, just use that version tag with no date (e.g. kdelibs-4.9.0~rc1). There would be no symlink to this as it's a real release, not a snapshot. For the extracted directory name I would include the version name as that seems to be the standard style (I do that with my own software releases at least). For a routine nightly snapshot, use the date as the version, with a symlink to that module on the FTP server. The symlink name should mention that it's a snapshot of some sort (e.g. kdelibs-git.tar.bz2 - kdelibs- git-20120706.tar.bz2). If it is very important to know which git commit was tagged, that can be added to the source just before it is tarred up, similar to how README.svn-nightly was added to our svn snapshots. For the purposes of scripting, if it's OK to assume GNU tar then the extracted directory name can include the date since we can use --strip-components. But that option is non-POSIX. Plus there could easily be non-shell tarball handlers (e.g. Ruby or Python) where you might want to know what the extracted directory name should be. So unless there's a compelling reason otherwise I would recommend leaving any version information out of the extracted directory name (e.g. kdelibs-git-20120706.tar.bz2 would decompress to just kdelibs) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [HEADS-UP] New Shared Desktop Ontologies requirement (v1.10.0)
On Wednesday, June 20, 2012 12:19:51 Allen Winter wrote: Howdy, In a few days we will be requiring v1.10.0 (or higher) of the shared-desktop-ontologies package for building kdepim-runtime master (effectively for KDE SC 4.9) Probably your distro does not have this version yet, so you'll need to install from source. Get the tarball at http://sourceforge.net/projects/oscaf/ at the very least we will require this version for kdepim-runtime, perhaps for kdelibs too. so please install I haven't tried it lately but SDO's trunk release should also be buildable from kdesrc-build, and build-tool probably has a similar recipe (though I haven't checked). The kdesrc-build SDO configuration in the current sample configuration is: module shared-desktop-ontologies repository git://oscaf.git.sourceforge.net/gitroot/oscaf/shared-desktop- ontologies branch master end module Note that this is only truly useful if you have an existing KDE development build of some sort to install to without interfering with the system packages, but that same precaution applies to installing from source. :-/ Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Nepomuk crashes in 4.8.4 fixed in KDE/4.8.x branch
On Saturday, June 16, 2012 15:33:17 Michael Pyne wrote: Any consensus on whether we will make a new kdelibs release? If so I would agree that it should be 4.8.5, with a 4.8.6 in ~1 month. If not that would make the upcoming routine release 4.8.5 (which is why I ask as I have an unrelated bugfix in there that I want to update the changelog for ;)). One thing is that our changelog XML does assume each KDE module in a release is the same version released at the same time, which would seem to argue for 4.8.4.1, or simply calling all of the KDE modules 4.8.6 at the next release... Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Thursday, June 14, 2012 15:36:47 David Faure wrote: On Tuesday 12 June 2012 20:42:28 Michael Pyne wrote: Hi all, Bug 301419 has been reported against kdelibs due to a build failure when KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform even more sanity checking in the KSharedDataCache. These commits use exceptions (as are already used in khtml) since they are actually the right tool in the context of where they are used, and because refactoring everything to use error codes everywhere (ECE) would have risked introducing more bugs. In order to minimize the changes to kdecore I only added the CMake magic to enable exceptions for only kshareddatacache.cpp. This doesn't work when KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that case. The Mageia devs have a proposed patch [1] to enable exceptions for all of kdecore, which fixes the issue. Is it acceptable for me to go this route? The only real alternative this late in the game is to back out the sanity checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL will not work for this tarball although it worked for 4.8.3, both of which I consider less desirable. But I don't want to make the change if there are good reasons to avoid it. The alternative would be to enable exceptions for all of kdecore only if enable-final is enabled. Sorry to be unclear -- that's exactly what the Mageia patch accomplishes. They only flip the exceptions bit for enable-final builds. If that sounds agreeable I intend on making that alteration and forwarding the patch to kde-packager. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Thursday, June 14, 2012 20:18:04 Albert Astals Cid wrote: El Dijous, 14 de juny de 2012, a les 15:36:47, David Faure va escriure: On Tuesday 12 June 2012 20:42:28 Michael Pyne wrote: Hi all, Bug 301419 has been reported against kdelibs due to a build failure when KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform even more sanity checking in the KSharedDataCache. These commits use exceptions (as are already used in khtml) since they are actually the right tool in the context of where they are used, and because refactoring everything to use error codes everywhere (ECE) would have risked introducing more bugs. In order to minimize the changes to kdecore I only added the CMake magic to enable exceptions for only kshareddatacache.cpp. This doesn't work when KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that case. The Mageia devs have a proposed patch [1] to enable exceptions for all of kdecore, which fixes the issue. Is it acceptable for me to go this route? The only real alternative this late in the game is to back out the sanity checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL will not work for this tarball although it worked for 4.8.3, both of which I consider less desirable. But I don't want to make the change if there are good reasons to avoid it. The alternative would be to enable exceptions for all of kdecore only if enable-final is enabled. Is that binary compatible? If I'm understanding it right, it would add extra typeinfo classes for kdecore but would remain binary-compatible with older code. It is not mentioned at all in our TechBase binary compatibility page, which is even the #1 Google hit now. :) Also the flag itself is claimed as binary compatible (in the context of code that doesn't actually /use/ exceptions) in some discussion on the Qt dev list, by Olivier Goffart and Thiago Macieira [1] (both of whom I trust more than myself on this topic). Researching further, the GCC libstdc++ page [2] mentions that exception handling is part of the ABI, but I can only assume this is in the context of does this code throw exceptions or not as opposed to whether non-exception- using code would care about that flag. The GCC docs on -fexceptions talk about extra code to propagate exceptions and perhaps data size overhead but there's no specific warning regarding changing the ABI visible outside of the object file. The detailed GCC ABI spec is at [3] and it seems to me from my reading of it that the changes involved are changes to data included with the .o, changes in function implementations, and extra calls to the C++ runtime library... but no changes to symbol names, mangling, etc. As far as I can tell this change should be binary compatible. As an experiment I've recompiled kdecore here with exceptions and run KDevelop (which I think is a fair exercise of much of the breadth of kdecore technologies) and wasn't able to find any new issues from that change. [1] http://permalink.gmane.org/gmane.comp.lib.qt.devel/3681 [2] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen- Options.html#Code%20Gen%20Options [3] http://sourcery.mentor.com/public/cxx-abi/abi-eh.html#cxx-abi Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
Hi all, Bug 301419 has been reported against kdelibs due to a build failure when KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform even more sanity checking in the KSharedDataCache. These commits use exceptions (as are already used in khtml) since they are actually the right tool in the context of where they are used, and because refactoring everything to use error codes everywhere (ECE) would have risked introducing more bugs. In order to minimize the changes to kdecore I only added the CMake magic to enable exceptions for only kshareddatacache.cpp. This doesn't work when KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that case. The Mageia devs have a proposed patch [1] to enable exceptions for all of kdecore, which fixes the issue. Is it acceptable for me to go this route? The only real alternative this late in the game is to back out the sanity checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL will not work for this tarball although it worked for 4.8.3, both of which I consider less desirable. But I don't want to make the change if there are good reasons to avoid it. Longer term (for frameworks) KSharedDataCache could be split into its own tier if necessary (it only really depends on Qt and KStandardDirs, which is now also in Qt...). Regards, - Michael Pyne [1] http://svnweb.mageia.org/packages/cauldron/kdelibs4/current/SOURCES/kdelibs-4.8.4- correct-use-fexception-switch.patch?revision=260068view=markup signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Change to tarball generation?
On Wednesday, May 23, 2012 19:40:52 Allen Winter wrote: This whole thread is confusing me. Maybe a command line would help? Is this correct? % tar cvf kdefoo-x.y.z.tar files % xz kdefoo-xy.z.tar = resulting in kdefoo-x.y.z.tar.xz That's fine. if not, please tell us what a command line should be I take it from mpyne's original posting that: % tar Jcvf kdefoo-x.y.z.tar.xz files isn't the way to go?? That's actually fine too, as it turns out. As an example, try: $ tar cf kdefoo-x.y.z.tar kdefoo-x.y.z/ $ pixz kdefoo-x.y.z.tar # resulting in kdefoo-x.y.z.tar.xz Because pixz is parallelized it works on whole blocks of data at a time and as far as I can tell makes no special provision for the last bits of compressed data being smaller than the block size. With a normal tar file the decompressed data you get is: 0* (where * is end of data and end of file) With a pixz-encoded tar file the decompressed data you get is: 0*x$ (* is end of data, $ is end of file) When you run a command like tar xfJ kdefoo-x.y.z.tar.xz everything will still work fine: tar knows exactly where the data should really end and will stop decompressing when it needs to. When you run a pipeline like xz --decompress kdefoo-x.y.z.tar.xz | tar xf - though, there's no way to tell xz to stop decompressing early. It tries to write all the decompressed data to the pipe. tar still knows exactly where to stop, and does so at the '*', not the '$', and closes its input (a pipe!) early. When xz tries to write the 'x$' (garble data) of the decompressed output it gets sent to a now-broken pipe, which kills xz on SIGPIPE. Scripts trying to drive automated extraction of that data using a pipeline just see that an error occurred, and will therefore abort. This has affected a couple of distributions that are source-based, but is annoying even for those manually extracting to have to figure out that their tarball actually extracted correctly. So the problem is only parallelizing compressors that take advantage of the allowance to write garbled data past the end of a file and still have the decompressor figure it out. It seems pretty implausible to me that a parallelizing compressor would always do this, perhaps this only occurs when the compressor is run with tar (e.g. tar cJf) instead of as a separate step? I hope this makes more sense. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Change to tarball generation?
Hi all, I noticed something while we were on the topic of tagging the beta tomorrow that I wanted to bring up, which is a concern with tarball generation. Specifically, the various parallizeable tarball generators (pixz, pbzip2) seem to generate extraneous data. tar is smart enough to ignore this extra data, but this can affect decompressing our tarballs in a pipeline (i.e. xz --decompress kdelibs-4.foo.tar.xz | tar xf -), as tar closing its STDIN causes xz to write its excess data to a broken pipe. This probably doesn't annoy a ton of different people (except for the obvious problem with source-based distros like Gentoo, e.g. https://bugs.gentoo.org/show_bug.cgi?id=410861) but if the speedup is not very substantial it would be better to use xz or bzip2 to avoid the problem entirely. (This is done by adjusting the value of compressors in the pack release script in case you're wondering). It might be possible to still get some concurrency benefit by batching up modules to pack and then running 4 or 8 (or however many CPUs are around) separate pack scripts at once, or fire off a pack while starting on tagging the next module, etc. Thoughts? I'll be very clear that I don't think this should affect creating the beta tarballs at all but if we choose to avoid the parallelizing compressors hopefully that would be in time for the release candidates. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: adding kwebkitpart to KDE SC
On Sunday, March 25, 2012 08:14:05 Allen Winter wrote: On Saturday 24 March 2012 8:16:28 PM David Faure wrote: Moving to kde-baseapps would do the job, but this requires replaying history, and will create trouble if we ever want to modularize it out again. So is there a simple way to mark it as part of KDE SC, so that it's released as a separate tarball, but together with the KDE SC releases? Why not treat kwebkitpart exactly like we do konsole? konsole lives in its own repo outside of kde-baseapps, but is conceptually part of kde-baseapps. Todo: 1) In the projects.kde.org database, we would need to make kwebkitpart a child of kde-baseapps. 2) ask Dirk to add it to the SC releases from 4.9 and in the future If we do this, ideally we would also mark kwebkitpart as dependent on kde- baseapps in the kde-build-metadata.git repo. This will prevent tools like kdesrc-build or some of our continuous integration testing software from trying to build kwebkitpart first (which would prevent cloning kde-baseapps). Actually, I can do this now just in case we do it anyways (it would have no effect until kwebkitpart is moved to kde/kde-baseapps/kwebkitpart). If we end up not going through with this please let me know so I can back out the change though. ;) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Sunday, August 21, 2011 17:46:29 Aaron J. Seigo wrote: kdesrc-build was recommended again .. i took the time tonight (after a long day in Taipei working on behalf of KDE) to examine it from scratch again. first the good news: it took me less time to set up this time than in the past, so it is indeed improving. there is no doubt that it is an impressive tool. I've been gone for awhile. (Kind of still am, I'm on open Wifi right now...) and so once normal Internet access resumes I'll be able to help on whatever is deemed necessary. I'll even be on vacation (though unpacking and doing other moving-related errands) which should help with the timeframe. * a script / tool to set up kdesrc-build. the config file is much clearer now, but there are too many little details that require knowledge of how things work and/or are easy to overlook. a tool that asks questions like Where should KDE software be installed?, Do you have a commit account for KDE?, etc. and forms an appropriate config file would pull this tool to within reach of just about everyone There actually used to be just such a tool (an online rc-file creator). I'd like to think it wouldn't be too hard to whip something up in one of those crazy modern Web frameworks or something. An easier thing might be just have kdesrc-build do the asking itself if run without an rc-file. I can see about doing something like that tonight. If anyone has more specific suggestions just let me know. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-scm-interest] git workflow draft
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote: Was this decided upon at some point? I got conflicting stories from sysadmin and other developers. Yesterday after migrating kdeaccessibility to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y I think concensus and consistency are important here. Was there a decision that the official branches should be named X.Y? Is that documented somewhere (I spent some time looking, but didn't find it). Yes, this was decided (by a coin flip, natch) at a IRC meeting which was preannounced on the various mailing lists. The meeting itself was held 2011-Feb-13 at 18:00 (or so) U.S. EST. The timestamp for the coin flip result was 18:51:29 on my logs (again, U.S. EST). aseigo, bcooksley, PovAddict, Uninstall are the nearby names who could probably attest if reminded. My understanding was that someone was going to put the meeting results into a Wiki (and it may have even happened ;), and that there would eventually be git hooks implemented to ensure no KDE/x.y branches are created on official KDE modules to make the rule self-documenting. I'll continue to have only limited Internet connectivity until next week so I hope this doesn't add fuel to some fire somewhere, but hopefully this helps. I can gzip the logs I have an upload them somewhere if that's helpful. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-scm-interest] git workflow draft
On Saturday, August 27, 2011 21:27:06 Michael Pyne wrote: On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote: Was this decided upon at some point? I got conflicting stories from sysadmin and other developers. Yesterday after migrating kdeaccessibility to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y I think concensus and consistency are important here. Was there a decision that the official branches should be named X.Y? Is that documented somewhere (I spent some time looking, but didn't find it). Yes, this was decided (by a coin flip, natch) at a IRC meeting which was preannounced on the various mailing lists. I see this was discussed more on kde-core-devel where support seems to be for KDE/x.y. Although I flipped the coin that gave us x.y, I was voting even at the time for KDE/x.y and fully support switching that decision if that's what we end up doing. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Tuesday, June 07, 2011 19:55:24 Modestas Vainius wrote: Hello, On penktadienis 03 Birželis 2011 17:27:41 Rex Dieter wrote: Split tarballs *after* migrations are final and where it can be carefully planned and executed would be more welcome, say for kde-4.8. Personally, I'm in favour of split tarballs. But as there seems to be so much opposition to this approach [1], I could take return to old ways with everything except kdebindings. Could you please keep that ugly beast split in 4.7 and on onwards? I don't think anyone (even Slackware packagers) are opposed to split tarballs being available, or even the default. From what I can tell the Slackware packagers would have significantly less packaging burden if monolithic tarballs are available. For what it's worth as kdesrc-build author trying to maintain a sample configuration, I agree completely, and I make it a business to keep dependency handling as simple as possible! Actually having to key in dependency data as the packagers would have to do is more work and while the consensus from most packagers seems to be that they were doing that work /anyways/ (and therefore split tarballs are fine), that's not the case for all of them. A separate objection had come about from the process of creating split tarballs (e.g. kdeedu migration as annma already mentioned), not the idea of having split tarballs itself. I think most of us would agree that a smooth migration to split tarballs is the much preferred mode of operation if we're going to be migrating at all, so I don't see that as controversial either. So in other words: Split tarballs are still the answer, but taking a little bit of extra work on our end to get a decent monolithic compilation can help some of packagers save a significant amount of maintenance burden, and as we transition over we just need to take advantage of past experience to try and ensure everything moves as smoothly as possible. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Perl version in KDELibs
On Sunday, June 05, 2011 22:07:25 Raphael Kubo da Costa wrote: Frederik Schwarzer schwar...@kde.org writes: So I changed the affected script and let it require Perl 5.10. Now I wanted to backport the change to 4.6 but I am not sure if that is OK due to the version bump and the with it changed dependency. So I looked at kdelibs' CMakeLists.txt and found out that it does not state a version. Does that mean it would also be satisfied by Perl 5.4 or something? Yes. Should we set a minimum version there? Well, we use CMake's FindPerl.cmake, which does not check Perl's version at all. If that's really needed, we could add a FindPerl.cmake to kdelibs, but the kde-buildsystem mailing list is a better place to discuss that. AFAICS CMake's FindPerl supports requesting a minimum version just fine, we just were not setting a minimum version to look for. As for backporting, my opinion is that if we did not previously state a minimum dependency version before we are not really breaking any dependency version promise (other release-team members might disagree). Both Perl 5.8 and 5.10 are unsupported by Perl upstream, so it doesn't make sense for us to depend on those or anything earlier. 5.10 *was* supported when 4.6 was released, so I think it makes sense to say that 5.10 at least is required from 4.6 on, at least in the case of the affected script for backporting purposes. As far as kdelibs is concerned, we should probably pick a minimum version. It doesn't have to be based on what's supported by Perl (i.e. can be based on what features we actually need) but any version is at least probably incorrect. I would recommend 5.10 due to the quantum leap it had over 5.8 but I'm interested in hearing other opinions. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Friday, June 03, 2011 10:56:12 Ian Monroe wrote: If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. I agree with you there. It's still release-team@kde.org not release-team-ark, release-team-marble etc etc. Why would split tarballs for 4.7 be an uncoordinated shambles? Ian, Having a million difference source tarballs required is a pain even for kdesrc-build, and that's even with the fact that individuals are graciously fixing the kdesrc-buildrc-sample as necessary to keep up with changes to Git module layout. Exposing the KDE project infrastructure over kde_projects.xml was/is supposed to be the fix for the explosion of source modules in kdesrc-build, but what has /actually/ happened for many modules in the kdesrc-buildrc-sample is that every single individual subproject for a given virtual module like kdegraphics has to still be spelled out by hand. And if you want to simply build individual projects, there's no clean way working straight from source tarballs to know beforehand which KDE deps you actually need. For instance I can no longer build Digikam because it required libkface, libkmap, and more which are documented in their CMakeLists.txt, but require Fortran to work for some face recognition algorithm. The point is not to complain about the fact that Fortran is required, but that I had to dig under quite a bit of separate subprojects, always trying to install separately, until I figured out that I would not be able to build Digikam for that reason. Even other projects that are more straightforward are difficult to deal with dependencies sanely. There is no information in the kde_projects.xml to relate what git projects depend on which other ones, so every single individual package from a packager's point of view represents some non-trivial amount of work to handle, as it is not as if it's a flat dependency tree where a given git module depends only on e.g. Qt and kdelibs. Areas where we might have, back in the day, included dependencies all in the same module and made sure they built in the proper order in CMakeLists.txt now get punted to the packagers. Now many packagers have taken this task on board /anyways/ and so splitting things up on our part makes it easier on these packagers. But it's not uniformly easier across the board for all packagers, and it's not like our current migrations have been exceptionally-well coordinated on this mailing list. Just look at the troubles that have occurred doing nothing more than trying to tag 4.6 follow-on releases. So you see, it's not as simple as just doing some copy/paste on a bunch of RPM spec files or whatever. Every individual package that gets created represents actual work to do. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
branches/KDE/4.6/kdelibs/kdecore/util
SVN commit 1214946 by mpyne:
Backport Fully clear cache metadata in clearInternal() to 4.6.
KSharedDataCache uses the clearInternal() method to reset the cache, which is
used if corruption is detected, and when directed through
KSharedDataCache::clear(). For whatever reason I thought that simply setting
the first page pointer for each possible index entry would be sufficient, but
that is not the case at all, as various methods which go through the cache
entries also check things such as the use count, last access time, etc.
Assuming no other errors (:-/) this should be the cause of bug 260309. (The
exact sequence would be a KSharedDataCache user runs ::clear(), later adds some
entries that invoke removeUsedPages(), and removeUsedPages() goes through *all*
index entries, including ones that appear to be in use since their use count is
0, but their first page is still invalid). Easiest way to invoke this bug I've
found is to simply run plasmoidviewer clock at a konsole.
This should fix the annoying bug 260309 just in time for KDE Platform 4.6. I'm
CC-ing release team so that there are no surprises, but I have hopefully
demonstrated enough of the issue to prove that this patch is at least more
correct than previous behavior.
It is possible that this was also the proximate cause of the Plasma crashes
when changing the system time for Daylight Savings (which I worked around with
the error message you've been seeing for months), bug 253795.
FIXED-IN:4.6
BUG:260309
CCBUG:253795
CCMAIL:release-team@kde.org
M +5 -0 kshareddatacache.cpp
--- branches/KDE/4.6/kdelibs/kdecore/util/kshareddatacache.cpp #1214945:1214946
@@ -437,6 +437,11 @@
IndexTableEntry *indices = indexTable();
for (uint i = 0; i indexTableSize(); ++i) {
indices[i].firstPage = -1;
+indices[i].useCount = 0;
+indices[i].fileNameHash = 0;
+indices[i].totalItemSize = 0;
+indices[i].addTime = 0;
+indices[i].lastUsedTime = 0;
}
}
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Question about moving packages *out* of a module before release.
On Thursday, December 23, 2010 09:28:38 Tom Albers wrote: Packagers should have the packaging scripts pretty much ready for the release. Removing a binary will cause work for them. Since we have shipped this for years + the fact that it is not broken, I don't see a reason why it should happen in this RC-stage. Why not remove it from trunk (KDE 4.7) only and leave it in 4.6? That's fine too. I'll get started on that sometime this week then, thanks. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Important fix in kdebindings for RC1
On Wednesday, December 22, 2010 18:36:32 Arno Rehn wrote: On Thursday 23 December 2010 00:10:38 I wrote: Hi, for RC1, the tarballs for kdebindings should be recreated from branch 4.6. It contains a fix necessary for at least gentoo users. Without it the buildsystem might not work as expected. Oh, and please CC me in replies - I'm not subscribed to the list. Mind briefly describing what the fix is? I use Gentoo and so I can help test. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Question about moving packages *out* of a module before release.
Hi all, I've got a question regarding kdesrc-build, my updater-builder thing in kdesdk/scripts. It occurred to me today as I was updating the documentation in a branch so as to avoid interfering with the message freeze that I'm probably going about this the wrong way. There was a point in time where it made sense for what was then kdecvs-build to be in kdesdk/scripts, since it was similar to kde-build in kdesdk/scripts, it used to be small ;), and I think it may have even pre- dated Extragear and at least wasn't far off. However, I've always handled my own releases, there's been a separate website, etc. I even used to routinely update it during freeze and although I've brought that up before myself, with no major dissent about breaking anything, I'm thinking that it makes more sense to split kdesrc-build off from the rest of kdesdk/scripts when it's moved to git.kde.org. So, with that in mind, is there any opposition to removing kdesrc-build from kdesdk/scripts prior to the 4.6 release? I'm not talking about doing it tonight by any means, but it seems like a better idea if it's going to be moved out of kdesdk/scripts to do so before a point release as opposed to after one. What I don't want to do is derail the preparations being made by e.g. release team, translators, packagers, distributions, etc. so I want to make sure that moving would not interfere with the release process. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Moving 4.6 to git next Tuesday or Wednesday
On Monday, December 13, 2010 16:49:29 Tom Albers wrote: - Original Message - Dirk, We were discussing in #kde-sysadmin whether it made sense to move not just trunk/4.7 development to Git next week, but 4.6 as well. No one really likes the idea of having two SCMs active at the same time, which was the current plan. I object to the transition next week of the 4.6.x code. I propose to do the transition after the 4.6.0 has been released. I highly agree that we should wait until after the 4.6 release to shift over. Most devs *should* have at least setup git by now (but in reality there are many still on svn-only for sure), and the rest of Tom's reasons are completely valid IMO. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Keeping binary compatibility
On Saturday, October 02, 2010 14:11:32 Christoph Feck wrote: On Friday 01 October 2010 15:32:41 Lubos Lunak wrote: as you probably know, the theory is that KDE libraries keep backwards binary compatibility. As you might or might not know, that is the theory. Let me add to the discussion that r1174275 added a virtual to an exported class for 4.5.2 and thus breaks binary compatibility. Not sure if the JSObject class is supposed to be used outside kdelibs, though. I've emailed Maks about that and confirmed that although JSObject is KJS_EXPORTed, that only for the usage of other parts of kdelibs. The header itself is never installed. Third-party users of KJS do so via other official wrappers such as KJSEmbed from what I understand. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Thoughts on freeze policy for kdesdk/scripts?
Hi all, I'm wondering if we have any special policy/exemptions for the development freeze for the scripts in kdesdk/scripts. Typically they are for use by KDE platform developers and so it seems to me that they wouldn't necessarily fall under a development freeze like the Software Compilation or Platform. I've developed under such a philosophy before with kdesvn-build, although I've stopped that awhile ago as I started to wonder whether it made sense to break freeze with kdesvn-build as more people use it. The reason I ask is that I'm thinking of going ahead with changing the name of kdesvn-build to kdesrc-build (for lack of a better descriptive name) due to the progress of implementing a git-based source repository for KDE, especially since I haven't made a release since December. We *do* have the 4.5 release coming up though, and kdesvn-build is technically installed as part of kdesdk. So does it make sense to go ahead with a name-change-and-release, or should I do the release now and wait a bit to change the name? And who do I email to get KDE-based web hosting for the tool, since my current donor apparently doesn't have a static IP anymore? Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Monday, May 17, 2010 11:05:17 Cornelius Schumacher wrote: On Monday 17 May 2010 Sebastian Kügler wrote: What is so hard about migrating config data? At least the account setup doesn't look too complicated to the naive me. Migrating config data is very hard. You have to deal with an awful lot of details, weird setups, configs which were migrated over many years again and again, and you have to get it 100% right, otherwise users will be annoyed. I completely agree, but is there some standard-ish layout that most users have? It may make sense to support migrating a very commonly used configuration, or group of options, if it's not too difficult, while letting users know that it can't be supported for other configurations. e.g. it's probably better to be able to migrate at the very least accounts and passwords instead of the font for every possible widget view KMail has. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Fwd: Am I the only person that ever checks sha1sums? :)
Release Team, Apparently SHA1 sums are wrong on some of the tarballs? (See below) Regards, - Michael Pyne -- Forwarded Message -- Subject: Am I the only person that ever checks sha1sums? :) Date: Monday 15 February 2010, 14:54:53 From: Charles Johnston char...@infoplatter.com To: kde-de...@kde.org The two files: kdebase-4.4.0.tar.bz2 and oxygen-icons-4.3.5.tar.bz2 do not match the sha1sums that are listed for them. Either the sums or the files are messed up. Any idea why? Did they get re-rolled and somebody forget to update the sums? Thanks Charles Johnston char...@infoplatter.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe - signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Plasma RunnerContext again
Hi all, A regression was noted in KRunner where ftp/http URLs did not work, probably introduced by my change a couple of weeks ago to fix local protocols. It is bug 224204. It is fixed now (although I think it did not make RC3, it is revision 1083222) and forward-ported, but I just wanted to make sure it was brought to the Release Team's attention. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: MALLOC_CHECK_
On Sunday 10 January 2010 08:39:37 Stephan Kulow wrote: Hi, Can we please take that out for the final 4.4? There are still plenty of ubuntu 9.10 installations with broken glibc out there ;( Hmm, we almost had this happen for 4.3 too, this is only supposed to be enabled for trunk, not for actual releases. :( It's removed now, thanks for reminding. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.3.5?
On Monday 28 December 2009 14:06:49 Sebastian Kügler wrote: On Sunday 27 December 2009 15:08:59 Allen Winter wrote: Did devels effectively backport to make it worth a new release? No, but of course it could be done the other way round: announce 4.3.5, then we'll backport. Although I'd kind of hate spending time backporting all the stuff instead of fixing more bugs for 4.4.0... Apparently there's no strong desire for a 4.3.5. So let's leave it up to the folks who do the actual release work. Dirk? Sebas?? I don't mind doing it. :) If other feel it's not worth it, that's also fine with me. JuK has a crash-on-shutdown fix in branch which could make a 4.3.5 worthwhile for kdemultimedia at least. But on the other hand that fix was put in because of some packagers prodding me so I'd expect that fix to have been picked up downstream anyways. ;) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Minor Point Release Policy
On Friday 11 December 2009 14:58:11 Lubos Lunak wrote: On Friday 11 of December 2009, Jonathan Riddell wrote: Over at Kubuntu we're trying to concince our technical board that its ok to put KDE minor point releases in updates. However it seems there's no formal rules for what is or isn't acceptable in minor point releases. I think it would be a good thing to have some since it gives guidance on what should or shouldn't be put into release branches after release. So I wrote some down quickly. Does this make sense to adopt for KDE? Additions welcome. * Fixes to bugs which are easy to verify and have a report in bugs.kde.org So if I notice a problem, I have to first report it? I'm almost willing to go this route just because it will artificially inflate my bug-closing numbers. :P They must not contain * API changes * New strings This will basically be me too but there have been string changes in minor releases when the string was flat-out wrong before. This is coordinated with the translations teams but not impossible (and nor should it be). I think I've even personally fixed a kdelibs bug that required an API addition. I'm not sure I'd agree with tilting the stability slider all the way up and forbid these types of fixes for slipstreaming KDE releases to downstream packagers. -- However I like to offer solutions where possible. So, assuming KDE switches to git it should be easy to have separate branches for branch releases and really stable releases, e.g. \ +-[4.4-branch]--*--*--*--* | | | | /-/ \-[4.4-stable]--*--*--*--* where * indicates stable bugfixes that would be applied to both -branch and -stable, and indicates bugfixes which might cause regressions that packagers try to avoid and would therefore be applied only to branch. KDE SC would be released from -branch and packagers could adopt -stable bugfixes. BUT, this would be that much more work for us, for (what seems to me at least) an uncertain gain. So even though I've thrown out the idea I don't really like it. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Possible 4.3.0 blocker in the Konsole KPart?
On Sunday 02 August 2009 20:01:01 you wrote: On Sunday 02 August 2009, Eike Hein wrote: Hi, this one seems to be fairly serious: https://bugs.kde.org/show_bug.cgi?id=186745 it's not a data loss bug, just not a very pretty thing. it also only seems to affect the top-left of the scrolled viewport. this is something that would be very good to fix in 4.3.1 for sure, but i don't think it's a release blocker? I'm not sure I would call it a *blocker* either, but this is *the* terminal application we're talking about. The effect is also prominent in Yakuake so it probably affects all users of KonsolePart. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
branches/KDE/4.3/kdebase/workspace
SVN commit 988394 by mpyne: Remove usage of glibc memory checker for 4.3 release in startkde. This is per the comments already in the script. CCMAIL:release-team@kde.org M +0 -4 startkde.cmake --- branches/KDE/4.3/kdebase/workspace/startkde.cmake #988393:988394 @@ -36,10 +36,6 @@ # we have to unset this for Darwin since it will screw up KDE's dynamic-loading unset DYLD_FORCE_FLAT_NAMESPACE -# Enable lightweight memory corruption checker -- this is for trunk only, we remove it for releases -MALLOC_CHECK_=2 -export MALLOC_CHECK_ - # in case we have been started with full pathname spec without being in PATH bindir=`echo $0 | sed -n 's,^\(/.*\)/[^/][^/]*$,\1,p'` if [ -n $bindir ]; then ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.2.4 potential blocker
On Friday 29 May 2009 00:15:43 Michael Pyne wrote: Hi all, I guess there's been problems with KPixmapCache causing crashes for some people, bug 182026 (https://bugs.kde.org/show_bug.cgi?id=182026) I committed a cleaner version of the patch for KDE 4.3 (rev 974349), it may be best to backport to 4.2 as well (I haven't touched branch at all). I've committed to 4.2 branch as revision 974498 since I figure the tagging should be done. I'd recommend including in 4.2.4 if possible but I'll leave that up to those doing the work. =D Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
4.2.4 potential blocker
Hi all, I guess there's been problems with KPixmapCache causing crashes for some people, bug 182026 (https://bugs.kde.org/show_bug.cgi?id=182026) I've never been able to reproduce but it seems related to wrong code generation due to pointer aliasing, as the patches that fix the crash for people who do experience it make the aliasing explicit. I committed a cleaner version of the patch for KDE 4.3 (rev 974349), it may be best to backport to 4.2 as well (I haven't touched branch at all). Another option that might work would be to compile with -fno-strict-aliasing but I haven't tried that (although again, I can't reproduce anyways). Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: About Kamala
On Sunday 12 April 2009 18:50:37 Mauricio Piacentini wrote: Hi. Stanislas Marquis, cc'ed on this message, is working on an astrological application for KDE, named Kamala. But as mentioned by Stanislas above, the application is now starting to become functional, and we need to find a place for it. So... what now? kdetoys and kdeutils do not seem right. Well if we were to call this a KDE application at all then what's wrong with kdetoys (without trying to sound like flamebait here but I don't think it meets the definition of kdeedu). I would hardly start a new KDE/ module for it as well. However that's all kind of moot as I think extragear would be the best place for it, as long as Stanislas doesn't mind having to do the release process. I agree that no existing extragear category seems to apply. I've heard extragear/extra recommended, which I would agree with. Hope this helps. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: About Kamala
On Sunday 12 April 2009 21:52:41 Mauricio Piacentini wrote: Michael Pyne wrote: Well if we were to call this a KDE application at all then what's wrong with kdetoys (without trying to sound like flamebait here but I don't think it meets the definition of kdeedu). I would hardly start a new KDE/ module for it as well. Well, why would you not consider it a KDE application at all? It uses kdelibs, is written in C++, is developed inside our SVN, has members of the community as contributors... can you elaborate? I mean as something distributed by kde.org as the KDE desktop environment. Obviously we can't just dump all kdelibs-using software into /trunk/KDE (even done in C++ by our best contributors), which is one of the reasons that we have extragear and playground. For instance if I were to make a Preventative Maintenance Scheduling program it would probably not be suitable to go into kdeutils or kdetoys because I don't see it as something that KDE the Project needs to solve. I do not want to start the astrology-is-not-a-science discussion here, as I do not think this is what matters. Any discussion that considers this belief (scientific or not) as the basis for including or not the application in KDE will turn into a flame fest: some people will point the historical importance of it, others might point to universities in the US that even today teach it (like the Kepler College), etc. Well there's a fairly decent definition of things which are science and things which are not, mostly involving testing theories by experiment. That doesn't change your point of its importance though, but I just see this in the same fashion that I see Greek mythology for instance. It's a subject that certainly has a lot of university-level discussion and thought behind it, even though it has been discarded as a scientific framework. The question is not that, but instead finding a place for the non-traditional applications that want to be considered for release with KDE. So, let us consider other theoretical applications, some difficult to handle: - A Genealogy program - An application to write dance notation (coreography) - A Biblic analysis/cross-reference tool That's actually a good lead-in, and I'm glad you asked the question. I don't personally feel that any non-traditional apps should be distributed by KDE under the K Desktop Environment banner that things in /trunk/KDE exist in (but that's just me). Now maybe I'm wrong and we're actually trailing standard practice here (e.g. does Mac OS X or GNOME include astrology programs in their localized versions for areas where astrology is important?). So in my mind the technical question is whether, wherever Kamala ends up going in SVN, there is a way to get release-team to handle packaging it as well, since right now the only framework for that is basically /trunk/KDE. Packagers would of course be free to do what some do today: ship only the best 4, or 5, or 10 on their distros. By the same reasoning, having something in kdetoys or kdemisc or kdespecialinterest does not mean it has to be shipped by every KDE distro: it just means it is released in-sync with KDE, as is part of our community. Well right now when packagers do that it is at much extra effort to break up our releases. What KDE actually ships is source code for modules, unbroken. If we were to agree to some standard means of grabbing individual applications or libraries then we'd be maybe be able to say that application foo is made available for interested parties but is not part of a standard KDE desktop module. But right now I don't think that's where we're at. Regards, - Michael Pyne Regards, Mauricio Piacentini signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On Wednesday 18 March 2009, Allen Winter wrote: On Wednesday 18 March 2009 7:04:19 am Dirk Mueller wrote: I am probably missing the discussion somewhere.. but who is going to provide working oxygen tarballs for each KDE release and where are they being found? Dirk, The original thread subject was Fwd: icon packaging. I asked the same question in that thread. The relevant exchange follows: === Are you planning to manage the weekly snapshots yourself? Or do you expect Dirk to manage that? I was hoping I could be automated along with the snapshots. But no I wasn't prepared to do it myself, but if needed I can't be that difficult to blog-advertice for a person to do that. Well snapshots are themselves different from releases anyways, unless this is to be the idea of the oxygen icon release. And it looks to me like no one is doing it since unless the aforementioned blog advertisement has already been made and I missed it. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.2.0 Tagging?
On Tuesday 20 January 2009, Dirk Mueller wrote: --\/ did anyone create a 4.2.0-blocker keyword in bugzilla yet and ask people to tag bugreports with them? Somehow I misread keyword as bug and opened bug 181447 http://bugs.kde.org/show_bug.cgi?id=181447 I then tried adding the keyword but I don't have sufficient karma, so it will have to wait for someone else. As I only know of the KLockFile bug (156759) in discussion for blocker that is all I have set against the tracker bug. If someone would like to go ahead and setup a keyword and close the tracker bug that'd by fine by me. Otherwise if you have a release blocker you can set it to block 181447. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.10
On Thursday 28 August 2008, Benoit Minisini wrote: On mercredi 27 août 2008, Sebastian Kügler wrote: On Wednesday 27 August 2008 11:35:13 Benoit Minisini wrote: Sorry, I was in holidays, so I couldn't add the changes to the ChangeLog. I will know that now for the next time. You can still do it (in fact, that would be useful). OK, this is done. I have modified the changelog_branch_3_5.xml file and committed it. Is there anything other to do? Update the generated PHP documentation after changing the XML file. The process is described in the DOCS file in the same folder. Don't do it now though, I've already fixed it up. ;) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008, Riccardo Iaconelli wrote: On Tuesday 26 August 2008 01:30:06 Allen Winter wrote: That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... I'm not sure I will like this idea. First off, it will break many (all?) scripts, including the widely used kdesvn-build. You can use the branch option to control what version of kdesupport you build. You also do not *need* to build kdesupport unless you need to install packages from it (which if only distro packages are required may not be necessary). If it really becomes a problem then we can copy the latest batch of release changes to a special kdesupport tag and just bump that as needed for use with the kdesvn-build tag option. i.e. phonon 4.2, strigi 0.5.10, etc. go into /tags/kdesupport/4.1.0 or something like that, a tag doesn't *have* to be a simple copy of some other branch, we can cherry pick into a tag as necessary. I'm ok by treating kdesupport as external dependency, less ok if I can't compile it anymore to build KDE. Yes, I think it should be possible to build kdesupport and have it work but it's not fair to those who just need one module to have to build more stuff out of SVN IMO. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008, Allen Winter wrote: On Tuesday 26 August 2008 11:54:34 Cyrille Berger wrote: On Tuesday 26 August 2008, Allen Winter wrote: So maybe they need put up a website with tarballs. Or maybe they need to tells to use the version in branch. Or maybe their API matures over the years and it doesn't become such a big deal. etc. For people taking stuff from svn, for instance kdesvn users, couldn't there be a kdesupport tag of what is good to use with kde ? yes, and the tags already exists for akonadi, decibel, kdewin-installer, phonon, qca, soprano, strigi, taglib ... We just need to start using the tags consistently and enforce them. If we intend to make it easy to say this is the kdesupport for kdesvn-build users then we need to copy those tags into a super-tag or something. i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of the latest phonon, strigi, qca, etc. releases from their appropriate tag or branch. As new releases occur the tag could be updated as well. For example, shouldn't Strigi 0.6.0 be tagged? and shouldn't that be the version compiled by the kdesvn-build scripts? Any release should be tagged. kdesvn-build right now defaults to trunk on everything, changing that wouldn't be too difficult but would require a new version of kdesvn-build. But if you want to go that route let me know so I can make a HOWTO bump kdesvn-build default modules type thing in case this occurs while I'm away. I guess another alternative is a file in SVN that kdesvn-build could parse for the revision/branch to build by default if there's no conf file. But I don't think I'll have time to write that code until 2009... Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008, Tom Albers wrote: Op dinsdag 26 augustus 2008 22:12 schreef u: i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of the latest phonon, strigi, qca, etc. releases from their appropriate tag or branch. As new releases occur the tag could be updated as well. I like and support the idea of a certain tag that contains the kdesupport libs needed to build kde-stable branch. I think another tag would be needed for kde trunk though. Well what I was thinking is we could make a kdesupport 4.1 branch for instance to do the same thing. (unless you mean kdesupport-stable which simply tracks the latest stable release of KDE). And then a kdesupport/kde-trunk or something for /trunk development. If we think this is a good idea then we should probably get a list of required dependencies for each so that we can begin to track this. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: New screensaver proposal for kdeartwork
On Sunday 24 August 2008, Allen Winter wrote: On Sunday 24 August 2008 06:26:12 Tom Albers wrote: Why not use the usual route[1] via kdereview? My fault. I told Michael to come directly here because I didn't know how to handle things since there is no module coordinator for kdeartwork. Toma is correct, first put the new screensaver into kdereview and then let's give it the normal 2 week review period. Sounds good, will do so shortly. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
New screensaver proposal for kdeartwork
Hi all, I'm writing to ask for permission to add the KDE Asciiquarium screensaver to kde-artwork, available from http://purinchu.net/software/asciiquarium.php and in playground/artwork right now as well. I think it's in a suitable shape by this point for KDE quality. I'm not sure what in the way of documentation is required for a screensaver but I can add that as well. Any feedback is appreciated as well of course. Please let me know if you have any questions. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
