Re: [Kde-pim] Push access to kdepim and kdepimlibs suspended

2013-01-23 Thread Ben Cooksley
On Wed, Jan 23, 2013 at 8:33 PM, Till Adam a...@kde.org wrote:
 On Wednesday 23 January 2013 19:33:30 Ben Cooksley wrote:



 Just a quick notice that due to a accidental merge from KDE/4.10 into

 master in both the kdepim and kdepimlibs repositories, both have been

 locked.

 A force push has already been performed to reverse the changes,

 however it has been left locked to ensure that the changes are not

 reintroduced accidentally (changes are also needed on various

 infrastructure systems, which in themselves are not capable of

 handling a force push).



 Unfortunately, due to the manner in which the change occurred, it is

 difficult to block it reoccurring at this time.



 That was me, it seems, please accept my apologies. I was under the imression
 that commit to 4.10, merge 4.10 into master is the recommended work flow.

That is the correct workflow. There was a mistake in my original email
- the problem in this case was that master was merged into KDE/4.10.

 If I understand correctly the problem was that I committed to a 4.10 that
 had just been merged so the parent was a merge commit? Several people
 endorsed my git skill on LinkedIn, so I feel I need to understand what went
 wrong here ;).

In this instance, KDE/4.10 had recently been merged into master (per
the correct workflow), and your work was on the master branch.
Because it had been recently merged, it was possible for Git to
fast-forward the KDE/4.10 branch to the master state without a
problem.




 Thanks to those who fixed the repos late at night, and sorry again.

Not a problem, things happen. Nicolas fixed this after Christophe found it.




 Till



Regards,
Ben


Review Request 108560: Fix kconfigcompiler_test

2013-01-23 Thread Alexander Richardson

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108560/
---

Review request for kdelibs.


Summary (updated)
-

Fix kconfigcompiler_test


Description (updated)
---

Fix kconfigcompiler_test

It previously did not find the required files since CMake set TESTSRCDIR
wrongly. It was surrounded by quotes and lacking a trailing /

This did not cause test failures since QCOMPARE/QVERIFY was not used
directly in the test function, so it simply printed messages instead.


Diffs (updated)
-

  tier2/kconfig/autotests/kconfig_compiler/CMakeLists.txt 
846476a6370ad41b1fbc808e2c738c85042e59a3 
  tier2/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.h 
1be213f5036c03a3ef9347005d5d53e6b440a4d4 
  tier2/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp 
f900aaf53de1996213c27357fee5b436ab3c4c8f 

Diff: http://git.reviewboard.kde.org/r/108560/diff/


Testing (updated)
---

Unit test now passes instead of printing messages and failing silently


Thanks,

Alexander Richardson



Re: [Kde-pim] Push access to kdepim and kdepimlibs suspended

2013-01-23 Thread Sebastian Kügler
On Wednesday, January 23, 2013 08:33:55 Till Adam wrote:
 That was me, it seems, please accept my apologies. I was under the imression
 that commit to 4.10, merge 4.10 into master is the recommended work flow.
 If I understand correctly the problem was that I committed to a 4.10 that
 had just been merged so the parent was a merge commit? Several people
 endorsed my git skill on LinkedIn, so I feel I need to understand what went
 wrong here ;). 
 
 Thanks to those who fixed the repos late at night, and sorry again.

If that makes you feel better, I've also just endorsed you for your Git 
skills. :-)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


Re: Color Management in KDE

2013-01-23 Thread Kai-Uwe Behrmann
On 22.01.2013 17:50, Cristian Tibirna wrote:
 On Monday 21 January 2013 21:22:42 John Layt wrote:
 My big concern is that KDE is sleep-walking into a hodge-podge
 solution with little co-ordination on implementations and dependencies, and
 little knowledge of the implications of the decisions being made.  I've
 tried to come up with a logical pragmatic solution within the usual KDE
 standards and architecture, but I am not a CM expert so if you feel that
 I've got anything wrong or misunderstood the situation please don't
 hesitate to call me on it.
 I guess I understand that a very color-conscient application (like, say, 
 krita), will need to correctly support CM internally, particularly if the app 
 is used outside an integrated KDE session. But then, is there conflict when 
 both the application and the wm try to manage color?

 - you mention a few hypothetical developments (especially in relation with 
 Qt5). Do you have direct information on the plans? Or, in other words, what 
 is 
 the perceived probability that your future-projections could be defeated by 
 predictible developer-opinion/development-direction changes?

 Thanks a lot.

A infection hit me. So, I am not able to check things and answer much
for some days.

kind regards
Kai-Uwe
-- 
www.oyranos.org


Re: KDEREVIEW: Mangonel

2013-01-23 Thread Ben Cooksley
On Wed, Jan 23, 2013 at 7:13 PM, Martin Sandsmark
martin.sandsm...@kde.org wrote:
 Distinguished Sirs and Madams,

 On Tue, Jan 08, 2013 at 09:08:11PM +0100, Martin Sandsmark wrote:
 Mangonel has just been moved to KDE Review.

 The KDE Review process is set to be two weeks, and if Mangonel calculator
 isn't completely wrong, that period is now up.

 Since all the issues raised are fixed, I assume I can now move forward with
 moving it to extragear/base?

Mangonel has now been moved to Extragear Base.


 Thanks to everyone who have reviewed, and contributed comments and fixes.

 --
 Martin Sandsmark

Regards,
Ben


Review Request 108570: This patch add support for bulk operations in systemtray applet settings.

2013-01-23 Thread Sandro Andrade

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108570/
---

Review request for kde-workspace.


Description
---

In page 'entries', user can select/deselect a specific or all entries and then 
change visibility and/or reset shortcut for all of them with a single combo 
selection/clear button click. Individually selecting all entries causes 
header's checkbox to automatically be checked. After selecting all entries 
(individually or by clicking in header's checkbox), a single entry deselection 
causes header's checkbox to automatically be unchecked. General suggestions 
and, in particular about UI usability, are appreciated.


Diffs
-

  plasma/generic/applets/systemtray/ui/applet.h 0b4a869 
  plasma/generic/applets/systemtray/ui/applet.cpp 09482d7 
  plasma/generic/applets/systemtray/ui/autohide.ui 3b6efff 

Diff: http://git.reviewboard.kde.org/r/108570/diff/


Testing
---


Thanks,

Sandro Andrade