Re: RFC: Conditions of early access to unreleased
On Sunday 03 Jun 2012 22:28:31 Michael Pyne wrote: > I like to view it as we have specific points-of-contact within the various > distributions who have agreed to interact directly with us, the KDE > developers and community in order to deliver the best possible KDE for > their distribution. As such they have early access to unreleased tarballs > to give early feedback of issues that would impair their ability to package > the software so that when Release Day rolls around, there are already KDE > packages available, yaaay! > > Really though, that's where I try to stop thinking of it being a privilege > for the packagers. You've certainly seen how hard it is to tag together > dozens and dozens of disparate modules into a working release, I can't > imagine it is much easier for the packagers to stitch it together on their > end. > > I agree candidate tarball releases shouldn't be deliberately announced to > users or pushed directly to distribution channels, but I would not see > major issue if enterprising users happened to end up with binary packages. > After all, they can already run "the upcoming release" using build-tool or > kdesrc- build so they really have no more advantage or claim to running it > than many other users. > > If it is required for a distribution's packaging build system to push > packages out, I would still rather have that than for them to hold up > making packages until we are ready. > > > * Report any compilation error you might find as soon as possible to the > > > > release team mailing list > > > > * Report any missing package or unpackaged dependency as soon as possible > > > > to the release team mailing list > > I agree with this, and AFAIK the packagers have been doing well with this. > But it's good to have it in writing. > > > Reiterated failure to comply with this guidelines might end up in > > revocation of your special access to unreleased tarballs. > > I would agree with this, with the proviso that we're talking about a > guideline more along the lines of "do your best to avoid publicizing the > new KDE packages" as opposed to "don't let any packages get out at all". > I'm assuming the packagers generally want this as well instead of having to > worry about other distros "breaking the street date". > > > So it turns I'm undecided and don't know if we should un-tighthen the > > first > > point to something like > > > > * Do not make the packages available to your users (in stable or > > > > automatically suggested updates to stable versions) before the official > > tarballs are announced > > I like this much better. I agree with Michael - the privilege is really minimal, and the days when distros were deliberately releasing KDE early to get an advantage are long gone, so there's no need to come on all heavy and threaten sanctions to our downstreams - it just creates a bad atmosphere where KDE stands to lose most. Most distros are offering packaged git snapshots perfectly legitimately anyway. I think these rules are an overreaction to Martin's complaint about the beta1 announce and undo, and would write *that* off as an accidental consequence of the transition within our release management. I'd rather send some guidelines to kde-packager@ and new packagers such as: * Please report any compilation errors you may find as soon as possible to the release-team@kde.org mailing list * Please report any missing package or unpackaged dependency as soon as possible to the release-team@kde.org mailing list * Test the packaged tarballs within your distribution team but please do not announce or release them to end users until the published KDE release date, because premature widespread bugreports about release showstoppers create unnecessary work for developers and bad publicity. IF "Rebel Distribution" steps up and starts deliberately flouting these, then you can revoke their ftp access, but start with a trusting relationship with all downstreams. FWIW the Open Build Service allows packages to be built but not published, and additionally allows selected OBS users the right to download unpublished packages, eg for testing, using "osc getbinaries". But this is of little use for testing a project of KDE's size - it's a pain in the ass to download all the build results of a KDE tarball set, then run createrepo on them, then install from that. For 'openSUSE KDE developer testing' I'd prefer to publish them to an unpublicised repository that can be added as an install source for testing, then copy the packages back into the official repo before release day. If some nosy non-contributor wants to grab these in advance and start spamming BKO then I'd view that as no more serious than someone reporting git snapshots under the wrong version number. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release schedule timing presentation
On Wednesday 04 Apr 2012 18:23:30 Albert Astals Cid wrote: > > which puts 4.8.2 being released at earliest at Wednesday April 4 01:59 > > CEST, if you count a release as a deadline. > > I think your problem is easily solved by looking at the kde.org webpage and > having a look to see if the announcement is out or not. As a distributor, I like to have the packages out there shortly before the announcement is out (typically at about 4pm Europe time) otherwise they are not out and mirrored until the next day. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Release schedule timing presentation
The timing on the release schedule* is confusing. Eg "1.25 Tuesday, April 3, 2012: KDE SC 4.8.2 release" - you'd think we were going to release yesterday. So I enabled publishing on our repo. But according to Dirk, to clarify developer uncertainty about how late on tagging day one can commit, the following phrase was inserted "All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team." which puts 4.8.2 being released at earliest at Wednesday April 4 01:59 CEST, if you count a release as a deadline. I'd like to separate the code freeze/tagging deadlines from the release schedule so that users, press and idiot distributors like myself can easily see when things should happen IIRC there is a script to generate the schedule, anyone know where it is? Will *http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
4.8.2 today?
I'm not aware of any showstopper issues for a 4.8.2 today, I assume we'll announce it later this afternoon. Sebas, are you doing the announcements? Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
4.8.2 today?
I'm not aware of any showstopper issues for a 4.8.2 today, I assume we'll announce it later this afternoon. Sebas, are you doing the announcements? Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BUG 297272
On Tuesday 03 Apr 2012 00:37:53 Thomas Lübking wrote: > W/o wanting to be nasty (rather nervous), has > http://commits.kde.org/kde-workspace/a5c8eca4759d1aace9fc265fef2b7ebb88ca369 > 0 been picked or will it be picked for the official 4.8.2 release? Not yet, but I'm hoping Dirk will pick this and the kdepim-runtime fix mentioned by Allen on r-t too. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9 Release schedule
On Tuesday 07 February 2012 23:03:57 Albert Astals Cid wrote: > Hi guys, are we releasing 4.9? > > Last i heard the Frameworks guys were aiming at some kind of release around > Akademy time (which is kind of the same time we'd release 4.9 in a 6 months > cycle). Obviously this means that either: > a) We release 4.9 not using frameworks at all (and using kdelibs 4.8 > renamed to 4.9 like we did this time) > b) We wait until frameworks is out > > I'm leaning towards a) since b) might end up meaning an undefinite delay. > > Opinions? Strongly for a) (and 4.10, ...) as it lets us show we've learned from 4.0 and keep most users on 4.x until 5.x is really ready for them. See Libreoffice's explicit definition of who .0 releases are for here: http://blog.documentfoundation.org/2011/07/01/libreoffice-3-4-1-provides- stable-new-features-for-every-user/ . Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Commit IDs for 4.7.2
On Saturday 15 October 2011 21:29:25 Will Stephenson wrote: > On Saturday 15 October 2011 15:35:27 Andreas K. Huettel wrote: > > in general it would be great if you could tag 4.7.2 and push the tags > > out... at least kdepim-runtime does not have it yet. > > +1, I'm trying to do a branch diff update in our packages here. Thanks Dirk, these have now been pushed. WIll ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Call for the next release codename to be Ritchie
On Thursday 13 October 2011 12:07:05 Ivan Čukić wrote: > As you all (probably) know, Dennis Ritchie has passed away. In my > opinion, we should somehow make tribute to him. > > I'm not sure the idea to name a release after him would be fitting, > but that's the only thing I've came up with. KDE & Ritchie? Won't Kernighan be offended? ;) Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Commit IDs for 4.7.2
On Saturday 15 October 2011 15:35:27 Andreas K. Huettel wrote: > in general it would be great if you could tag 4.7.2 and push the tags out... > at least kdepim-runtime does not have it yet. +1, I'm trying to do a branch diff update in our packages here. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Monday 20 Jun 2011 23:02:56 todd rme wrote: > On Mon, Jun 20, 2011 at 10:57 PM, Alexander Neundorf wrote: > > On Monday 20 June 2011, Manuel Tortosa wrote: > >> El Monday, 20 of June de 2011, a les 22:39:40, Alexander Neundorf va > > > > escriure: > >> > Or, in other words, I do not yet have any feedback from packagers, > >> > except the early feedback from Sune in Randa, which is incorporated > >> > now, but no fresh feedback yet. > >> > >> Well in our case in Chakra we switched our buildsystem already for match > >> the new separated tarballs.as in fact. our start was KDEMod, a modular > >> KDE set of packages, so the new way is the natural way for us, even > >> more monolithic tarballs makes hard simple things like get the kate > >> perl bindings compiling only each tarball once. > > > > So you want the fine grained tarballs, if I understand correctly ? > > > > Alex > > Just looking at how the openSUSE buildservice is set up, they seem to > use fine-grained tarballs as well, although I don't know how closely > those match to the breakdown you are using. We're using them, and the consensus among the team so far is that they allow faster builds (broader dependency tree instead of deeper) and isolate failures better. These are the kde.org tarballs; is anyone using their own?? Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta2 vs RC1
On Thursday 16 Jun 2011 13:50:14 Sebastian Kügler wrote: > On Thursday, June 16, 2011 13:22:10 Dirk Mueller wrote: > > as I didn't realize that Beta2 was scheduled that soon after Beta1 > > announcement and I was on a longer vacation, how about we skip Beta2 and > > go with RC1 directly? > > > > Alternatively I would have to squeeze in a delay of 2 weeks into the > > schedule, which I currently rather not want to have. > > > > Opinions? > > Fine with me... Does your affirmation apply to cancelling Beta2, or the alternative? Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011 02:00:44 Dirk Mueller wrote: > just finished creating the first set of tarballs for Beta1. compiling > started to look good, but I'm not yet through all of them. > > Please report any important packaging issues or must-fix bugs to the > release- t...@kde.org mailinglist. kdepim needs 6b44080e, compile fix. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [HEADS-UP] kdepim 4.4.11
On Friday 15 Apr 2011 22:03:53 Allen Winter wrote: > A recently reported bug [1] that can crash Plasma (calendar stuff) has been > traced back to using the akonadi serializer built against the kcal > library. > > We need the akonadi serializer to build against the new KCalCore library, > which became available starting in kdepimlibs 4.6. > > Bottom Line: As this is a nasty bug, I have been convinced to make a 4.4.11 > release. Expected Delivery: 18 April (approx) > > PIMsters: if you want to make bug fixes in 4.4, feel free (within the usual > rules) Thanks for the heads up. Is this in 4.4. branch already? Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
On Friday 01 Apr 2011 21:47:44 Dirk Mueller wrote: > I just finished uploading the first set of tarballs. Super :) > kdegraphics probably does not build yet, but other than that, I see good > intermediate results already. From https://build.opensuse.org/package/rawlog?arch=i586&package=kdegraphics4&project=KDE%3ADistro%3AFactory&repository=openSUSE_11.4 : /usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/bin/ld: cannot find -lkdcraw /usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/bin/ld: cannot find -lkexiv2 Looks like some tweaking is needed to find the libs in libs/. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.1 tarballs (try #1) uploaded
On Tuesday 01 Mar 2011 18:12:20 Raphael Kubo da Costa wrote: > Jonathan Riddell writes: > > There's also a binary incompatible change in libkopete > > > > http://websvn.kde.org/branches/KDE/4.6/kdenetwork/kopete/libkopete/kopete > > accountmanager.h?r1=1208598&r2=1219502 > > > > http://paste.kde.org/6125/ > > > > I believe this should be a new overload. > > Does Kopete have a binary compatibility policy? Or should it raise the > lib so version? Yes, there have been external plugins in the past (Skype springs to mind). Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.1 tarballs (try #1) uploaded
On Saturday 26 Feb 2011 11:21:28 Dirk Mueller wrote: > Hi, > > took a lot longer than expected due to solving various git/svn packaging > issues in my scripts, but I think I now was able to upload the first set of > tarballs. > > Please be especially aware if anything is lost in those tarballs (missing) > that should have been there since 4.6.0. the splitting was not changed so > it should be a drop-in replacement. > > I'm still compiling, but I wanted to share it anyway already for others to > give it a try. Kopete added a hard dependency to kdenetwork on libjasper after 4.6.0. Previously it was a soft runtime dependency. I have made it a soft build time dependency. The patch is at http://reviewboard.kde.org/r/6562 Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.7 Release Schedule
On Thursday 27 January 2011 22:52:48 Tom Albers wrote: > Fine by me. > 2 beta's and 2 rc's is working nicely for us I think. Also the cycle as a > whole seems to work ok. +1, I don't see any problems with it. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
branches/KDE/4.6/kdebase/workspace
SVN commit 1217284 by wstephens: Remove MALLOC_CHECK_ from 4.6 branch CCMAIL: release-team@kde.org CCMAIL: kde-packa...@kde.org M +0 -12 startkde.cmake --- branches/KDE/4.6/kdebase/workspace/startkde.cmake #1217283:1217284 @@ -36,18 +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 if not already set -# -- this is for trunk only, we remove it for releases -if [ "x$MALLOC_CHECK_" = "x" ] && [ -x /lib/libc.so.6 ]; then -# Extract the first two components of the version from the output. -glibc_version=$(LC_ALL=C /lib/libc.so.6 | sed -e 's/[^0-9]*\([0-9]\.[0-9]\+\).*/\1/;s/\.\([0-9]\)$/.0\1/;q') - -MALLOC_CHECK_=2 # Default to 2 unless glibc 2.9 or higher. -test $glibc_version \> 2.08 && MALLOC_CHECK_=3 - -export MALLOC_CHECK_ -fi - # 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
MALLOC_CHECK_=3 in 4.6.0
We forgot to disable this when branching 4.6, which kills Eclipse: https://bugs.kde.org/show_bug.cgi?id=247398 Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.6/kdebase/workspace/powerdevil
On Tuesday 25 January 2011 12:51:52 Will Stephenson wrote: > n Monday 24 January 2011 11:17:17 Dario Freddi wrote: > > SVN commit 1216708 by dafre: > > > > > > CCMAIL: Dirk Mueller > > CCMAIL: release-team@kde.org > > > > > > > > Backporting r1216705 > > > > > > > > This commit is critical and needs to be released in 4.6.0; otherwise it > > needs to be reverted. > > I don't understand this sentence, if the commit is not included in 4.6.0, > what needs to be reverted? > > > Please add it to the tag or this issue might cause > > troubles in the future. > > What bug report, so we can look for downstream dupes from the RCs? from 1216705: "Move handling of button events config to the same format of suspendsession's one. This greatly facilitates code sharing and allows to remove quite a lot of redundant code. Bad news for beta/RC users willing to upgrade though: this might break your profiles' button actions." What's the critical part though? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.6/kdebase/workspace/powerdevil/daemon
On Tuesday 25 January 2011 12:52:14 Will Stephenson wrote: > On Monday 24 January 2011 11:19:16 Dario Freddi wrote: > > SVN commit 1216709 by dafre: > > > > CCMAIL: Dirk Mueller > > CCMAIL: release-team@kde.org > > > > Backporting r1216706 > > > > This commit fixes a critical bug in the migrator, hence it should be > > released with 4.6.0 > > What bug, so we can look for downstream dupes from the RCs? >From 1216706: "The profile migrator didn't know how to migrate actions (yet). Make him learn just in time for the final release." ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.6/kdebase/workspace/powerdevil/daemon
On Monday 24 January 2011 11:19:16 Dario Freddi wrote:
> SVN commit 1216709 by dafre:
>
> CCMAIL: Dirk Mueller
> CCMAIL: release-team@kde.org
>
> Backporting r1216706
>
> This commit fixes a critical bug in the migrator, hence it should be
> released with 4.6.0
What bug, so we can look for downstream dupes from the RCs?
>
>
> M +27 -14powerdevilprofilegenerator.cpp
> M +23 -0 powerdevilprofilegenerator.h
>
>
> ---
> branches/KDE/4.6/kdebase/workspace/powerdevil/daemon/powerdevilprofilegene
> rator.cpp #1216708:1216709 @@ -260,26 +260,18 @@
> runScript.writeEntry< uint >("scriptPhase", 0);
> }
> // SuspendSession
> -if (oldGroup.readEntry< int >("idleAction", 0) > 0) {
> +if (oldGroup.readEntry< uint >("idleAction", 0) > 0) {
> KConfigGroup suspendSession(&newGroup, "SuspendSession");
> suspendSession.writeEntry< uint >("idleTime",
> oldGroup.readEntry< int >("idleTime", 30) * 60 * 1000); -if
> (!methods.contains(Solid::PowerManagement::SuspendState)) { -
> suspendSession.writeEntry< uint >("suspendType", 2); -} else
> {
> -suspendSession.writeEntry< uint >("suspendType", 1);
> +suspendSession.writeEntry< uint >("suspendType",
> upgradeOldAction(oldGroup.readEntry< uint >("idleAction", 0))); }
> -}
> // Buttons
> -if (oldGroup.readEntry< int >("powerButtonAction", 0) > 0 ||
> oldGroup.readEntry< int >("lidAction", 0) > 0) { -KConfigGroup
> suspendSession(&newGroup, "SuspendSession"); -
> suspendSession.writeEntry< uint >("idleTime", oldGroup.readEntry< int
> >("idleTime", 30) * 60 * 1000); -if
> (!methods.contains(Solid::PowerManagement::SuspendState)) { -
> suspendSession.writeEntry< uint >("suspendType", 2); -} else
> {
> -suspendSession.writeEntry< uint >("suspendType", 1);
> +if (oldGroup.readEntry< uint >("powerButtonAction", 0) > 0 ||
> oldGroup.readEntry< uint >("lidAction", 0) > 0) { +
> KConfigGroup handleButtons(&newGroup, "HandleButtonEvents"); +
> handleButtons.writeEntry< uint >("powerButtonAction",
> upgradeOldAction(oldGroup.readEntry< uint >("powerButtonAction", 0))); +
> handleButtons.writeEntry< uint >("lidAction",
> upgradeOldAction(oldGroup.readEntry< uint >("lidAction", 0))); }
> }
> -}
>
> // Save and be happy
> profilesConfig->sync();
> @@ -301,4 +293,25 @@
> }
> }
>
> +uint ProfileGenerator::upgradeOldAction(uint oldAction)
> +{
> +switch ((OldIdleAction)oldAction) {
> +case Standby:
> +case S2Ram:
> +return ToRamMode;
> +case S2Disk:
> +return ToDiskMode;
> +case Shutdown:
> +return ShutdownMode;
> +case Lock:
> +return LockScreenMode;
> +case ShutdownDialog:
> +return LogoutDialogMode;
> +case TurnOffScreen:
> +return TurnOffScreenMode;
> +default:
> +return 0;
> }
> +}
> +
> +}
> ---
> branches/KDE/4.6/kdebase/workspace/powerdevil/daemon/powerdevilprofilegene
> rator.h #1216708:1216709 @@ -31,8 +31,31 @@
> ResultUpgraded = 2
> };
>
> +enum OldIdleAction {
> +None = 0,
> +Standby = 1,
> +S2Ram = 2,
> +S2Disk = 4,
> +Shutdown = 8,
> +Lock = 16,
> +ShutdownDialog = 32,
> +TurnOffScreen = 64
> +};
> +
> +enum NewMode {
> +NoneMode = 0,
> +ToRamMode = 1,
> +ToDiskMode = 2,
> +SuspendHybridMode = 4,
> +ShutdownMode = 8,
> +LogoutDialogMode = 16,
> +LockScreenMode = 32,
> +TurnOffScreenMode = 64
> +};
> +
> GeneratorResult generateProfiles(bool tryUpgrade = false);
> void upgradeProfiles();
> +unsigned int upgradeOldAction(unsigned int actionId);
> }
>
> }
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.6/kdebase/workspace/powerdevil
On Monday 24 January 2011 11:17:17 Dario Freddi wrote:
> SVN commit 1216708 by dafre:
>
> CCMAIL: Dirk Mueller
> CCMAIL: release-team@kde.org
>
> Backporting r1216705
>
> This commit is critical and needs to be released in 4.6.0; otherwise it
> needs to be reverted.
I don't understand this sentence, if the commit is not included in 4.6.0,
/what/ needs to be reverted?
> Please add it to the tag or this issue might cause
> troubles in the future.
What bug report, so we can look for downstream dupes from the RCs?
>
> M +6 -40 daemon/actions/bundled/handlebuttonevents.cpp
> M +9 -7 daemon/actions/bundled/handlebuttoneventsconfig.cpp
> M +2 -1 daemon/actions/bundled/suspendsession.h
> M +1 -1 daemon/powerdevilaction.cpp
> M +1 -1 kcmodule/global/GeneralPage.cpp
>
>
> ---
> branches/KDE/4.6/kdebase/workspace/powerdevil/daemon/actions/bundled/handl
> ebuttonevents.cpp #1216707:1216708 @@ -19,6 +19,8 @@
>
> #include "handlebuttonevents.h"
>
> +#include "suspendsession.h"
> +
> #include
>
> #include
> @@ -87,33 +89,13 @@
> void HandleButtonEvents::processAction(uint action)
> {
> // Basically, we simply trigger other actions :)
> -switch (action) {
> -case 1:
> -// Sleep
> -triggerAction("SuspendSession", qVariantFromValue< uint >(1));
> -break;
> -case 2:
> -// Hibernate
> -triggerAction("SuspendSession", qVariantFromValue< uint >(2));
> -break;
> -case 3:
> -// Turn off PC
> -triggerAction("SuspendSession", qVariantFromValue< uint >(8));
> -break;
> -case 4:
> -// Lock
> -triggerAction("SuspendSession", qVariantFromValue< uint
> >(32)); -break;
> -case 5:
> -// Shutdown dialog
> -triggerAction("SuspendSession", qVariantFromValue< uint
> >(16)); -break;
> -case 6:
> +switch ((SuspendSession::Mode)action) {
> +case SuspendSession::TurnOffScreenMode:
> // Turn off screen
> triggerAction("DPMSControl", qVariantFromValue< QString
> >("TurnOff")); break;
> default:
> -// Do nothing
> +triggerAction("SuspendSession", qVariantFromValue< uint
> >(action)); break;
> }
> }
> @@ -134,25 +116,9 @@
> {
> // For now, let's just accept the phantomatic "32" button.
> if (args["Button"].toInt() == 32) {
> -switch (args["Button"].toUInt()) {
> -case 1:
> -// Sleep
> -triggerAction("SuspendSession", qVariantFromValue< uint >(1));
> // To RAM -break;
> -case 2:
> -// Hibernate
> -triggerAction("SuspendSession", qVariantFromValue< uint >(2));
> // To disk -break;
> -case 3:
> -// Turn off PC
> -triggerAction("SuspendSession", qVariantFromValue< uint >(8));
> // Shutdown -break;
> -default:
> -// Do nothing
> -break;
> +triggerAction("SuspendSession", args["Button"]);
> }
> }
> -}
>
> bool HandleButtonEvents::loadAction(const KConfigGroup& config)
> {
> ---
> branches/KDE/4.6/kdebase/workspace/powerdevil/daemon/actions/bundled/handl
> ebuttoneventsconfig.cpp #1216707:1216708 @@ -19,6 +19,8 @@
>
> #include "handlebuttoneventsconfig.h"
>
> +#include "suspendsession.h"
> +
> #include
>
> #include
> @@ -72,19 +74,19 @@
> QSet< Solid::PowerManagement::SleepState > methods =
> Solid::PowerManagement::supportedSleepStates();
>
> foreach (KComboBox *box, boxes) {
> -box->addItem(KIcon("dialog-cancel"), i18n("Do nothing"),
> (uint)0); +box->addItem(KIcon("dialog-cancel"), i18n("Do
> nothing"), (uint)SuspendSession::None); if
> (methods.contains(Solid::PowerManagement::SuspendState)) { -
> box->addItem(KIcon("system-suspend"), i18n("Sleep"), (uint)1); +
> box->addItem(KIcon("system-suspend"), i18n("Sleep"),
> (uint)SuspendSession::ToRamMode); }
> if (methods.contains(Solid::PowerManagement::HibernateState))
> { -box->addItem(KIcon("system-suspend-hibernate"),
> i18n("Hibernate"), (uint)2); +
> box->addItem(KIcon("system-suspend-hibernate"), i18n("Hibernate"),
> (uint)SuspendSession::ToDiskMode); }
> -box->addItem(KIcon("system-shutdown"), i18n("Shutdown"),
> (uint)3); -box->addItem(KIcon("system-lock-screen"),
> i18n("Lock screen"), (uint)4); +
> box->addItem(KIcon("system-shutdown"), i18n("Shutdown"),
> (uint)SuspendSession::ShutdownMode); +
> box->addItem(KIcon("system-lock-screen"), i18n("Lock screen"),
> (uint)SuspendSession::LockScreenMode); if (box != m_lidCloseCombo) {
> -box->addItem(KIcon("system-log-out"), i18n("Prompt log out
> dialog"), (uint)5); +box->addItem(KIcon(
Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011 14:53:19 Martin Schlander wrote: > Tirsdag den 18. januar 2011 20:56:00 skrev Frank Reininghaus: > > Am Dienstag 18 Januar 2011, 20:06:52 schrieb Aaron J. Seigo: > > > On Tuesday, January 18, 2011, Frank Reininghaus wrote: > > > > Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: > > > > > > There is a bug which lets some KDE apps (especially Dolphin) > > > > > > crash every time they are closed: > > > > > > > > > > > > https://bugs.kde.org/show_bug.cgi?id=257944 > > > > > > > > > > has strigi devels been contacted / drawn into this? > > > > > > > > all the Strigi web content I found looks quite outdated, but if > > > > anyone knows how to contact people who work actively on Strigi, > > > > drawing their attention to the bug report would certainly be a good > > > > idea. > > > > > > Jos van den Oever is still "at the helm" afaik and the mailing list is > > > still active, if low volume, at strigi-de...@lists.sf.net .. > > > > thanks, I sent a mail to that list asking the Strigi devs to have a look > > at the report. > > The openSUSE problem seems to be fixed by updating to strigi "0.7.3.99". > Not sure if the problem with strigi 0.7.3 was an upstream bug or a > packaging issue on the openSUSE side or something else. It appears to have been an upstream bug. I just updated the snapshot after Jos van den Oever pointed out that a) 0.7.3 was not an official release, and b) it's several months old. I have prompted him to make an 0.7.4 release, hopefully that will happen soon. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday 18 January 2011 10:17:47 Dirk Mueller wrote: > how are the pros/cons regarding declaring the current 4.6 branch as 4.6.0 > or adding another RC to the game? > > Looks like we have two bugs marked as ship stopper: bug 246678 and 262274, > so just ignoring that is a bit of a problem for me :-) I've been testing a series of patches for trueg. We found one set that fix 246678 last week, but introduces a time-consuming conversion process on first run. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.6 Scheduler: Request for 4.6 Beta 3
On Thursday 09 Dec 2010 21:14:20 Allen Winter wrote: > On Thursday 09 December 2010 2:23:26 pm Tom Albers wrote: > > - Original Message - > > > > > > We really need the extra time; data migration is still taking time > > > > to get > > > > right. > > > > > > For having tried KMail trunk (and reverted to 4.4) I can only agree. > > > > That brings out the question if 2 weeks will make the needed > > difference... If pim is not ready after that two weeks and needs more > > time, do we insert another beta? > > > > Is the wish to insert another beta to test code changes, or is it simply > > to have more time (which is fine too)? > > More time. > > > Maybe pim needs more time, and should skip .0? > > I wish we knew. I really hope it doesn't come to that. > Agreed though, even an extra 2 weeks might not be enough time either. Would the PIM team spend the extra 2 weeks on the desktop versions or on Kontact Mobile? Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KSecretService in KDE 4.6
On Friday 29 October 2010 00:55:55 Allen Winter wrote: > I believe exception requests must go through the release team, so I'm > redirecting. > > On Thursday 28 October 2010 3:25:56 am Michael Leupold wrote: > > Hi, > > > > as announced at Akademy we would really like to get a first > > implementation of ksecretservice into KDE 4.6 in order to further the > > project and adoption of the new D-Bus API. However due to various > > work-work and personal reasons I haven't been as productive as I would > > have liked to be during the last month and - as a result - there are > > some things left to do before ksecretservice can be merged into trunk. > > > > When looking at the release schedule I was quite baffled. Somehow a > > 4-week period between soft and hard freeze was stuck to my mind. > > Obviously the 2 weeks we are left with doesn't leave us with enough time > > to finish everything needed to release AND have a proper review period. > > > > Therefor I'd like to ask for an exception in order to still get > > ksecretservice into KDE 4.6. We're very dedicated to the project and I > > managed to get some time off work-work in order to improve the chances > > of finishing in time. > > > > The parts to be merged will be: > > - A new implementation for KWallet::Wallet using the secrets storage > > D-Bus API (ksecretserviced, gnome-keyring). It is meant to enable a > > smooth transition to the new client API to be released with KDE 4.7. The > > new implementation will not sport any new public API. > > - A new daemon implementation called ksecretserviced which fully > > replaces kwalletd and uses the new D-Bus API. It will end up in > > kdebase/runtime. > > > > This is the timeline which seems reasonable in order to finish: > > 04.11. Move both parts to kdereview > > 14.11. Merge with trunk > > > > So this would involve both a shortened review period of 1.5 weeks as > > well as merging after hard freeze. Tests are already in place and > > extended in parallel to the actual code. We're well aware that angering > > our users by releasing something that puts their secrets in danger is > > not an option and are committed to either releasing quality or not > > delivering. > > > > I'd be grateful if we could make this work somehow. If you have any > > questions I'd be happy to answer them. > > I think we should grant this request. > I have no objections. > > 10 days review time seems good enough to me. > > Committing to trunk 3 days after the hard freeze isn't a big deal either. > If desired, extending the hard freeze 3 days wouldn't be so bad. > > We aren't that intransigent. I just checked with Michael, this didn't get done in time so KSS is delayed until 4.7. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Possible problems with Intel drivers in 4.5.0 release
On Monday 02 August 2010 20:59:24 Martin Gräßlin wrote: > Hi Release-Team, > > I know that the release is scheduled for tomorrow, nevertheless I want to > make you aware of a possible problem with Intel graphics cards and > compositing. > > I think I first have to explain a little bit: KWin uses a test to determine > if OpenGL compositing is working during the startup. This seems to fail > for some Intel drivers since some time. It used to work and the code has > not changed, so it is most likely a driver bug. I was first made aware of > this problem at Akademy. Due to the fact that I do not own Intel hardware > I was unable to reproduce or try to fix the issue. > The best solution would be to fix the failing self check. But due to > missing hardware I am not able to investigate it. Do you know what intel hardware and intel driver combination the test fails on? On my openSUSE 11.3 machine with intel driver 2.12.0 and 945GM chipset, openGL rendering is definitely working - when I switch to XRender I notice that Blur stops working on widget backgrounds. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE SC 4.6 Schedule
With my distribution hat on I'm wondering when KDE SC 4.6 will come out. Aiming for our traditional end of January release, we would have a 5 1/2 month cycle, which is appreciably shorter than what we have achieved during the last 2 releases due to slippages. However if it is released later, it wanders into the time period when distributions would be wanting to freeze their package version numbers for their spring releases. I know it's early but I'd like to do some long range risk planning that might affect 4.6's release, and come up with a schedule promptly after 4.5. Factors off the top of my head with my risk assessment: * Qt releases - 4.7 should be well out and stable then. LOW * Camp KDE - will probably happen around this time, but doesn't have a significant hacking component. LOW * Sprints - is there anything big like a Tokamak in preparation for January? I assume there will be an Osnabrueck KDEPIM meeting but I hope that will be generating 4.7 work and PIM's focus in the 4.6 cycle will be on consolidation after the 4.5 'tick' to Akonadi. MEDIM * Development programs: I'm not aware of any dev programs like GSoC that will be delivering around that time. LOW Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Thursday 20 May 2010 11:36:15 Dirk Mueller wrote: > On Monday 17 May 2010, Sebastian Kügler wrote: > > If that's not achievable in the 4.5 timeframe, maybe we should start > > thinking about 4.6 instead? > > so kdepim should be excluded from 4.5 tagging. what about kdepimlibs? > > will kdepimlibs 4.5 work with kdepim 4.4? Anecdotally, yes. > has this been tested? Raymond has been providing a packaged build of pim 4.4 on pimlibs 4.5 + the rest of trunk for a while now here: https://build.opensuse.org/project/packages?project=home:rwooninck:kdepim45:kdepim44 Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDEPIM Needs More TIme
On Friday 14 May 2010 14:49:34 Allen Winter wrote: > On Friday 14 May 2010 8:42:21 am Allen Winter wrote: > > Howdy All, > > > > I regret to inform everyone that kdepim will not be ready for a 4.5 Beta1 > > that is scheduled to happen in a few days. > > > > We estimate an extra month will be needed. > > > > Unfortunately, the massive porting effort to Akonadi (an even bigger job > > than the Qt3/KDE3 -> Qt4/KDE4 port) is taking longer than we > > anticipated. > > Forgot to mention that Thomas' blog has a lot more details. > http://thomasmcguire.wordpress.com/2010/05/14/akonadi-meeting-and-the-kde-s > c-4-5-release I recommend releasing 4.5 without kdepim as was done with 4.0 and doing an interim kdepim release cycle (call it akonadi tech preview) before 4.6. This gives us a way to soft-launch the major Akonadi ports without the full expectations coupled to being in the SC, and gives us some nice things to talk about between 4.5 and 4.6. Whatever we do, we're not hurting our downstreams, since 4.5 falls between the major distros' release cycles anyway. There will be a bit more packaging work during the 4.5 cycle to maintain repos containing SC 4.5 + kdepim 4.4 and SC 4.5 + kdepim ATP, but as a packager I'm ok with that. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
4.5 schedule on Techbase?
Hi team Is there a 4.5 schedule that can be published on Techbase? People here at SUSE are asking me. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Nepomuk] kde-4.4, virtuoso-6.1.0, and virtuosoconverter
On Monday 08 February 2010 21:39:43 you wrote:
> well, the index problem already is resolved.
Sorry, I should have said that I started with a clean apps/nepomuk - no
conversion. If you said the index problem resolved on the basis of Sebas'
experience, I'm afraid mine contradicts that.
Will
> A real showstopper is the dbus problem though :(
>
> http://bugreports.qt.nokia.com/browse/QTBUG-7475
Yuck.
> Cheers,
> Sebastian
>
> Will Stephenson wrote:
> > On Saturday 06 February 2010 15:11:24 Sebastian Trueg wrote:
> >> the big problem is that I cannot reproduce this error.
> >> Even without the patch queries work...
> >> I need to look into that when I am back from the FOSDEM.
> >
> > I can reproduce it with 4.3.98, soprano 2.3.70, virtuoso 6.1. I asked
> > Sebas, and since he got it working he is using soprano 2.3.73 out of
> > kdesupport trunk, not the blessed for 4.4 2.3.70 version. Is the
> > soprano version relevant?
> >
> > Log extract searching for a file by file name:
> >
> > "/usr/bin/nepomukservicestub(3215)" Error in thread 139951182154000 :
> > "SQLExecDirect failed on quer y 'sparql select distinct ?r where { { {
> > ?r ?v1 ?v2 . ?v2 bif:contains "'Bread Sauce.pdf*'" . } U NION { ?r ?v1
> > ?v3 . ?v3 ?v4 ?v2 . ?v4
> > <http://www.w3.org/2000/01/rdf-schema#subPropertyOf> > www.w3.org/2000/01/rdf-schema#label> . ?v2 bif:contains "'Bread
> > Sauce.pdf*'" . } . { ?r a ?v5 . ?v5
> > <http://www.w3.org/2000/01/rdf-schema#subClassOf>
> > <http://www.semanticdesktop.org/ontologies/2007/
> > 03/22/nfo#FileDataObject> . } UNION { ?r a ?v6 . ?v6
> > <http://www.w3.org/2000/01/rdf-schema#subClass Of>
> > <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Folder> . } .
> > } . }' (iODBC Error: [OpenLink][Virtuoso iODBC Driver][Virtuoso
> > Server]SQ200: Table referenced in contains does not hav e a text
> > index)"
> > "/usr/bin/nepomukservicestub(3215)" Error in thread 139951182154000 :
> > "Invalid iterator."
> > nepomukqueryservice(3215)/nepomuk (query service)
> > Nepomuk::Query::SearchThread::run: 5
> > nepomukqueryservice(3215)/nepomuk (query service)
> > Nepomuk::Query::SearchCore::slotFinished:
> >
> > I am for delaying the release until this is resolved.
> >
> >
> > Will
> >
> >> Cheers,
> >> Sebastian
> >>
> >>> Hey Sebastian,
> >>>
> >>> On Friday 05 February 2010 09:10:36 Sebastian Trueg wrote:
> >>>> Please try the attached patch in
> >>>> kdebase/runtime/nepomuk/services/storage.
> >>>> And if it helps, please apply as I am in the train all day.
> >>>> Starting nepomuk will take a long time probably since the whole index
> >>>> needs to be rebuilt.
> >>>
> >>> That doesn't seem to help. (I've only rebuilt/installed that particular
> >>> directory.)
> >>> The error is apparently the same still. I've attached an updated log
> >>> from my
> >>> nepomukserver (gave it some time to start up, the initial CPU load had
> >>> definitely
> >>> settled).
> >>>
> >>> I'll be on IRC all day and tonight, you can catch me there (or by
> >>> email, of course).
> >>>
> >>>> Sebastian Trueg wrote:
> >>>>> yeah... damn, apparently the text index is not enabled by default
> >>>>> anymore. Still was in 6.0.x snapshots I had.
> >>>>> This is fixed with a simple patch to the storage service though.
> >>>>> Maybe we need to port that back to the 4.4.0 tag, too.
> >>>
> >>> Thanks,
> >>> --
> >>> sebas
> >>>
> >>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> >>
> >> ___
> >> release-team mailing list
> >> release-team@kde.org
> >> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Nepomuk] kde-4.4, virtuoso-6.1.0, and virtuosoconverter
On Saturday 06 February 2010 15:11:24 Sebastian Trueg wrote:
> the big problem is that I cannot reproduce this error.
> Even without the patch queries work...
> I need to look into that when I am back from the FOSDEM.
>
I can reproduce it with 4.3.98, soprano 2.3.70, virtuoso 6.1. I asked Sebas,
and since he got it working he is using soprano 2.3.73 out of kdesupport
trunk, not the blessed for 4.4 2.3.70 version. Is the soprano version
relevant?
Log extract searching for a file by file name:
"/usr/bin/nepomukservicestub(3215)" Error in thread 139951182154000 :
"SQLExecDirect failed on quer y 'sparql select distinct ?r where { { { ?r
?v1 ?v2 . ?v2 bif:contains "'Bread Sauce.pdf*'" . } U NION { ?r ?v1 ?v3 . ?v3
?v4 ?v2 . ?v4 . ?v2 bif:contains "'Bread Sauce.pdf*'" .
} . { ?r a ?v5 . ?v5
.
} UNION { ?r a ?v6 . ?v6
. } . } .
}' (iODBC Error: [OpenLink][Virtuoso iODBC Driver][Virtuoso Server]SQ200:
Table referenced in contains does not hav e a text index)"
"/usr/bin/nepomukservicestub(3215)" Error in thread 139951182154000 : "Invalid
iterator."
nepomukqueryservice(3215)/nepomuk (query service)
Nepomuk::Query::SearchThread::run: 5
nepomukqueryservice(3215)/nepomuk (query service)
Nepomuk::Query::SearchCore::slotFinished:
I am for delaying the release until this is resolved.
Will
> Cheers,
> Sebastian
>
> > Hey Sebastian,
> >
> > On Friday 05 February 2010 09:10:36 Sebastian Trueg wrote:
> >> Please try the attached patch in
> >> kdebase/runtime/nepomuk/services/storage.
> >> And if it helps, please apply as I am in the train all day.
> >> Starting nepomuk will take a long time probably since the whole index
> >> needs to be rebuilt.
> >
> > That doesn't seem to help. (I've only rebuilt/installed that particular
> > directory.)
> > The error is apparently the same still. I've attached an updated log from
> > my
> > nepomukserver (gave it some time to start up, the initial CPU load had
> > definitely
> > settled).
> >
> > I'll be on IRC all day and tonight, you can catch me there (or by email,
> > of course).
> >
> >> Sebastian Trueg wrote:
> >> > yeah... damn, apparently the text index is not enabled by default
> >> > anymore. Still was in 6.0.x snapshots I had.
> >> > This is fixed with a simple patch to the storage service though.
> >> > Maybe we need to port that back to the 4.4.0 tag, too.
> >
> > Thanks,
> > --
> > sebas
> >
> > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: KDE3 maintenance
On Tuesday 24 November 2009 17:25:03 Allen Winter wrote:
> On Wednesday 18 November 2009 1:48:01 pm Timothy Pearson wrote:
> > I have been maintaining and improving KDE3 for Ubuntu for a while now,
> > and have accumulated a massive set of patches that:
> > * Add lots of functionality
> > * Fix old bugs
> > * Allow compilation on new systems
> >
> > How would I go about including them into the KDE3 SVN/GIT, and then
> > generating a new 3.5.11 release?
>
> I think we should put out a formal policy statement on 3.5.
Fair enough, some of us have responsibilities regarding KDE 3 code.
I suggest to neither discourage nor encourage further development beyond
maintenance. KDE 3 is Free Software too, so people (eg KDAB and Timothy) are
free to contribute to it, but the KDE world has enough to do without devoting
general resources (release team time, sysadmin time, i18n time, packager time)
to KDE 3.
> Here are some thoughts:
>
> + 3.5 is done and finished. there will be no more 3.5 releases
This thought does not exclude a KDE 3.6 :). If people want to to continue to
release KDE 3, we should let them, but perhaps under a different identity
('KDE 3 Legacy Project'?) so it's clear the KDE project has moved on and
problems in inadequately-resourced KDE 3 releases don't make KDE as a whole
look bad.
Do you propose KDE 3 hackers like Timothy should commit new substantive new
features into the KDE 3.5 branch or let them open up a KDE 3 trunk? Is this
fair, considering KDAB is putting new pim features into 3.5. branch already?
> + we will not allow commits into the 3.5 branch willy-nilly
Agreed, I've got maintenance responsibilities here too and can't afford for it
to become a playground.
> without the
> normal process of maintainer and/or peer review
However, KDE 3 module maintainers have moved on, we can't expect them to
review KDE 3 stuff, therefore KDE 3 review will be necessarily less specialist
and should be more conservative to prevent stuff getting in we don't
understand.
> + we could create a 3.5 group on reviewboard for 3.5 patches to be
> collected. If the patch creator wants their patch into 3.5 SVN, then they
> need to work through normal maintainer/peer review channels to get the
> patch accepted and committed.
> + the kde-packagers mailing list will be notified if critical/security
> fixes for 3.5 become available.
All good ideas.
> + perhaps we should tell kde-packagers about normal bugfixes and new
> features too??
See if there's demand first before introducing a distraction.
> + I have no idea what we should do about new i18n strings or updated docs
> that need translations.
I'd let just let it happen.
Will
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Detecting Phonon version
On Tuesday 05 May 2009 14:10:05 Matthias Kretz wrote: > So, KDE 4.3 should require Phonon 4.3. Everything else needs to be optional > (I already told Marco about this for mplayerthumbs). What did you tell him? Is he going to hack mplayerthumbs so it doesn't require VideoWidget::snapshot() or remove it entirely? Dirk says this failure to build kdemm vs phonon 4.3 is blocking 4.3beta1 tarballs. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
circular dependency between kdegraphics and extragear/libs
Guys I'm writing to you as module coordinators of extragear and kdegraphics. Have you noticed the dependency loop between extragear/graphics and kdegraphics? kdegraphics/gwenview requires libkipi from extragear/libs, but extragear/libs/kipi-plugins requires kdegraphics/libksane How do you propose to break the loop? best Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 Documentation/Handbook Milestone
On Thursday 22 May 2008 12:59:56 Allen Winter wrote: > On Thursday 22 May 2008 00:01:21 Matt Rogers wrote: > > On Wednesday 21 May 2008 08:29:24 am Allen Winter wrote: > > > Howdy, > > > > > > Um.. .we forgot to put in a separate milestone for Doc/Handbook > > > changes. > > > > > > Unless there are objections, I'd like to create one for 3 June 2008. > > > > > > This gives another 2 weeks for creating content. > > > Then we have about 6 weeks for translations before RC1 is tagged. > > > > > > -Allen > > > > Uhm, no, we didn't. The message freeze applies to documentation too, or > > at least it did in past releases, since documentation is translated. > > Right. > This is new. > > Will Stephenson (representing the doc writers) thought something > like this was needed now. As long as the translators don't complain, > which they haven't so far. No, I only represent my gobby self. Anyway, judging by nixternal's blog the docu people didn't wake up to the freeze yet, so some extra time was needed. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Not available for beta1 release
On Tuesday 20 May 2008 12:28:27 Sebastian Kügler wrote: > I'll be on vacation next week so I don't expect to have a reliable Internet > connection (nor the guts to tell my girlfriend that I have to work) to do > the release announcement for beta1 and website updating dance next Tuesday. > > If anyone else can step up, please do so. I can explain and help where > necessary. It's also a good idea to have a second person aware of the > release PR involves, bus numbers ... > > So, who's in a for a crash-course release PR? I can do it. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Move KJots to kdepim?
On Thursday 15 May 2008 17:29:39 Allen Winter wrote: > It can. > The plugin is listed on the features page and Steve is already > working hard to make it happen for 4.1. My bad, I assumed the move was anticipating a kjots plugin for 4.2. I withdraw my objection. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Move KJots to kdepim?
On Wednesday 14 May 2008 22:47:45 Allen Winter wrote: > On Wednesday 14 May 2008 10:23:30 Matt Rogers wrote: > > On Tue, May 13, 2008 at 3:42 PM, Stephen Kelly <[EMAIL PROTECTED]> wrote: > > > On Tuesday 13 May 2008 20:54:32 you wrote: > > >> Howdy, > > >> > > >> Any objection to moving KJots from kdeutils into kdepim? > > >> > > >> The kjots.desktop file even puts itself into the PIM Utilities > > >> category. > > >> > > >> One big reason to do this is so kjots can be embedded into Kontact. > > > > > > I'm fine with it anyway. > > > > > > Steve. > > > (KJots maintainer) > > > > I don't see the point of moving it. Why does KJots need to be in > > kdepim in order to be embedded into Kontact? > > Because we no longer install the headers which make it > possible to do so. Ok.. technically you could copy the headers > to your project dir and hack a solution. Even still, this makes > kdeutils dependent on kdepim (because the jots plugin will > require the kontact interface library). > > The kontact interface library API is not stable so we can't > move it to kdepimlibs, unfortunately. > > This isn't a huge deal. I almost would be happier without > a kjots plugin, but others seem to want such a thing. So kjots in Kontact won't happen for 4.1 now anyway. During the 4.2 release cycle, copy the (unstable) headers to kjots svn until the plugin is done then shift the whole lot into PIM then - job done. Decide when a kjots plugin is realistic, and make an appropriate decision. Will -- Will Stephenson IRC: Bille ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdereview closed?
On Tuesday 13 May 2008, Tobias Hunger said: > Am Freitag, 9. Mai 2008 23:16:30 schrieben Sie: > > On Tuesday 06 May 2008, Tobias Hunger wrote: > > > How are you providing access > > > to your D-Bus interfaces? > > > > We install the xml file and we let "client" code use qdbusxml2cpp on it. > > I would not mind havig clients regenerate the bindings code, but > unfortunately qdbusxml2cpp is just not able to do that: The client will > need to have access to all the support code (marshalling/demarshaling, type > definitions, etc.) that is required to make the code generated by > qdbusxml2cpp work. > > How do you provide access to that? Do you put that into a library? Forward this to kde-core-devel, I'd like an answer to this. I think the answer is the "client" has to do it statically. WIll ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: the future of kdetoys
On Wednesday 07 May 2008, Pino Toscano said: > > 4. kweather > > kweather is something curious. Some parts are ported (kweatherreport and > > kweatherservice) > > AFAIR, kweather has a service running on DCOP/D-Bus for getting the weather > data, and clients communicate to it via the bus wire. > > Apart the kweather kicker applet, there is another client for it: the > weather plugin for the kontact summary view. I don't know its state, > though. (Although, I think it should be more-or-less working. Any PIM-er > has an idea?) The summary plugin works but it was just getting empty strings back from the weather service when i disabled it a couple of weeks ago. Plasma's weather engine could supply the data but it's tied to Plasma, and Kontact is explicitly designed to work on windows where there is no Plasma. It would be nice to decouple the new engine from Plasma. > About the plasma thing: IMHO it was just the new rewrite, without taking in > consideration kweather at all (especially that now the weather "ions" are > plugins for the plasma engine, so no way to use those like the D-Bus > kweather engine.) Nod. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDEPIM 4.1?
On Wednesday 30 April 2008 15:57:50 Allen Winter wrote: > On Wednesday 30 April 2008 07:04:13 Sebastian Kuegler wrote: > > Which apps are ready? KMail and KOrganizer, I gather? How about > > KAddressbook? Knotes? Akregator? That would make for a good PIM (it's the > > apps I use anyway ;-)). > > > > Not that I was able to try them, yet... > > Some folks say KMail is ready. I'm not so sure. Specifically? > KAlarm and KTimeTracker.. probably. > > Helio says KNode is ready. I'll take his word for it. What does vkrause say? > Kaddressbook is pretty bad, IMO. > > Akregator is getting better. It can probably be ready. > > Kleopatra is maintained by KDAB, so I guess it will be ready. > > KOrganizer is pretty bad and so is Kontact (the summaries suck > and some of the plugins are broken). What's KDAB's take on kdepim core apps' readiness, since AFAIK they are working to make 'Kontact' work and soon? > I don't know about KNotes Nor me, and the existence of the Notes plasmoid is confusing. > KPilot, Korn, KMobileTools, KMailCVT haven't had commits in so long > that I have great doubts about their usefulness and quality. > > And, the various kresources for groupware, kolab, scalix, slox, etc... > who knows. We need testers for those. Not module ship blockers. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM 4.1?
On Wednesday 30 April 2008, Cornelius Schumacher said: > On Wednesday 30 April 2008 04:26:54 Allen Winter wrote: > > One idea is to eliminate kdepim and move any of the apps > > that people still care about and actively maintain to extragear. > > That would be a bad idea. I think we should keep KDE PIM intact. If there > are applications which actually aren't ready for the release, we can easily > disable them and reenable them later. Agreed. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Kate & KDE 4.1 feature plan
On Monday 31 March 2008, Sebastian Kügler said: > On Monday 31 March 2008 15:27:31 Allen Winter wrote: > > On Wednesday 26 March 2008 17:59:52 Dominik Haumann wrote: > > > Hi everyone, > > > > > > according to [1] the KDE 4.1 feature plan is open until 31 March 2008. > > Will spotted that the date in the release schedule is 7th April, he fixed > it in the Feature Plan, in case people wonder. Credit is due to 'Eagle-Eye' Binner (spot) and 'Quicky-Wiki' Mueller (fix), I'm just Feckin' Gobshite Stephenson. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Distro BoF
On Sunday 20 January 2008 12:42:39 Richard Moore wrote: > On 1/19/08, Jonathan Riddell <[EMAIL PROTECTED]> wrote: > > * System Settings Unix tools integration (possibly with Guidance KDE 4 > > * port) > > Could you explain this one? Embedding eg YaST modules (as used to be done) or Guidance in System Settings for consistent user and system configuration. details TBD. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team page on Techbase
On Saturday 19 January 2008 16:32:03 Allen Winter wrote: > Howdy, > > FYI, I started a new Release Team project page on Techbase [1]. Howdy, folks! The project page looks good. I decided to join the r-t list so I can help communicate distros' needs affecting release scheduling and "add my mustard" as they say in nuernberg to the discussions. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdenetwork/kopete
On Wednesday 14 November 2007, Dirk Mueller said: > On Wednesday 14 November 2007, Will Stephenson wrote: > > Adds a much-requested feature: a way for protocols to give a hint to > > Kopete which form a chat should take. > > Thats not a release critical bugfix, is it? Not critical, but adds a string, and fixes a 4 year old bug that a bunch of other stuff is blocked on that we can then work on when trunk branches. Would you mind retagging for this please? Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
