Re: merging development branch into master

2012-11-04 Thread Andriy Rysin

On 11/04/2012 01:18 AM, Shaun Reich wrote:
well, you've got until november 8th (4 days according to my clock) 
until hard feature freeze which blocks even those on the planned 
feature list.


so, as my procrastinating self would say you've got plenty of time ;)

ok, I tried to do
post-review -n --parent=master
but that generated a lot of changes - most of those are the ones done in 
master since our feature branch was created, I guess we should have 
created 'tracking' branch?


So the question I have:
* is there a way to create a review generating only changes done in 
feature branch?
* or we should rebase feature branch on master and then generate the 
review diff?


Thanks,
Andriy



Re: KDEREVIEW: share like connect and plasmate

2012-11-04 Thread Pino Toscano
Hi,

Alle sabato 3 novembre 2012, Pino Toscano ha scritto:
 Alle giovedì 1 novembre 2012, Aaron J. Seigo ha scritto:
  This is to inform everyone that the plasmate and share-like-connect
  repositories have been moved into KDE Review so that, if all goes
  according to plan, we can move them to their more permanent homes
  in a couple of weeks.
  
  Most of the apps in the plasmate repo have actually been in past SC
  releases; it's just the main app, plasmate, that is still fairly
  new.
 
 Regarding plasmate: I fixed earlier a number of i18n issues (ugh...),
 and the layout of two .ui files.

(A couple more today...)

 On the other hand, there are still the following issues I found
 looking around:

- in plasmate/publisher/remoteinstaller/remoteinstaller.ui there is a 
label: «Choose the source directory of your package.\n\nYour URL must 
end in a metadata.desktop file.», but the URL selector below (named 
srcDirUrl) wants a file and its value is used only as directory (see 
remoteinstaller.cpp)

- there is a bit of string mess for some terms:
  - Add-On vs Addon, used with the capital letter even in middle of
sentences
  - Save Point vs SavePoint (both upper- and lower- case)
I'd recommend (after fixing the .ui files and other issues, as already 
noted in my other email) taking a deep review of the strings of plasmate 
(see plasmate.pot in svn [1]) according to the few bits of HIG [2] we 
have.

- plasmate uses the plasmagick icon, which exists in the Oxygen icon 
theme only; this means it will have no icon when the icon theme is 
another one, or simply in menus of other DEs; please copy it from Oxygen 
(or get a non-Oxygen generic one) and install it as hicolor.

- the following binaries are installed in $prefix/bin:
  - plasmaengineexplorer
  - plasmakconfigxteditor
  - plasmaremoteinstaller
  - plasmate
  - plasmawallpaperviewer
  - plasmoidviewer
  - remote-widgets-browser (*)
  - windowswitcherpreviewer (*)
except the plasma-something ones (including the notable exception of 
plasmoidviewer), the two I marked with (*) look too generic to be 
installed in bindir; please consider moving them to libexecdir (making 
sure to use KStandardDirs::findExe to reach them), or give them less 
generic names

[1] trunk/l10n-kde4/templates/messages/kdereview/plasmate.pot
[2] http://techbase.kde.org/Projects/Usability/HIG

Thanks,
-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.


Re: [RFC] Solution for duplicated or false review/bug notifications

2012-11-04 Thread Jarosław Staniek
Luigi Toscano wrote:

 Jaroslaw Staniek wrote:
 tl;dr
 I propose to treat public KDE git branches (for all repos) having
 '-work' suffix in a special way: ignore REVIEW and BUG/CCBUG lines.
 When commit hits a public KDE git branch without -work suffix, current
 behaviour is preserved.
 
 ** The problem:
 Whenever commits are pushed from work branches and they contain
 merged/cherry-picked commits (from other developers) with REVIEW:
 line, we're getting repeating notes on rb and emails: This review has
 been submitted with commit x by  to branch z.
 I think the hook shall not generate duplicated reviews like this.
 
 [...]
 **What workflow is affected:
 Affected workflow that use integration with git.reviewboard.kde.org
 and/or bugs.kde.org is as follows:
 
 1. Push a change without a REVIEW but optionally with BUG/CCBUG lines.
 Of course because we do not know the review number at the moment).
 Pushing to a public work branch is often needed if we expect someone
 will need/want to test the code.
 
 
 So why not using a personal clone for this (publishing the work), and not
 allowing notifications (if it is not the case) for personal clones,
 instead of changing the rules for official repositories?

It's possible but while personal repos are useful, let's see what is
introduced with them in our context:

- for reviewboard I need to reference public project's repository, e.g. 
calligra; otherwise patches will get rejected reviewboard; so before 
submitting to review I need to create a copy of the commit within the 
official repo anyway

- private repo adds another layer in the (already not trivial to explain) 
multiuser workflow: I need to create a copy of the commit in the official 
repo anyway since the personal repo is meant for use (r/w) by the owner (if 
I understand correctly)

- private repos do not support email notification about the changes (hiding 
them was not requested by me)

 Rebase on officially published repository is always bad. I don't think
 officially allowing rebase on a subset (the -work ones) of public branches
 is the proper way to do.

This is not a part of the request. It's about behaviour of integration with 
rb and b.k.o, i.e. KDE-specific integration. When using cherry-picking.

 For cherry-picking, there is not so much to do, as they are new commits.
 Merged commits (not rebased), afaik, do not produce new notifications.

That's true. Our discussion is based on the assumption that cherry-picking 
is valuable just like editing commits before picking them to other branches 
(e.g. split/squash) is. I am askimg my 'students' to commit early and often 
without a fear to their -work branches.

Author of git explains it's jsut another tool which complements merges 
[https://lkml.org/lkml/2008/5/21/351].
But then multiple messages that contain the same REVIEW or BUG lines will 
exist in the repo, when some of them do not mean a review is submitted or a 
bug is resolved. So here's the proposal for addressing this (when needed) in 
advance - when picking a name for a new branch.

There's different solution that addresses the problem of duplicated 
submissions (but not the unwanted premature submissions):
It may be possible to block 'resolving' of already 'resolved' bug on b.k.o 
and submitting already 'submitted' review on rb by altering logics of these 
two sites. 

--
regards / pozdrawiam, Jaroslaw Staniek
 Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek


Review Request: This change will allow the user to see keyboard layout visually

2012-11-04 Thread Andriy Rysin

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

Review request for KDE Runtime and Shaun Reich.


Description
---

Keyboard layout preview feature


Diffs
-

  kcontrol/keyboard/CMakeLists.txt 29de717975d37949448a922c2297674a796a97c1 
  kcontrol/keyboard/kcm_add_layout_dialog.h 
6c6a795161d95d5203b5943ead6a7787e29ffd67 
  kcontrol/keyboard/kcm_add_layout_dialog.cpp 
34c97163d9267da34ad948347f7cc35b556fdaeb 
  kcontrol/keyboard/kcm_add_layout_dialog.ui 
b73080d08d6281c4f67d079ab016a3df50821012 
  kcontrol/keyboard/kcm_keyboard.ui 22968e8644cae700efe505fde437d332aa9514ed 
  kcontrol/keyboard/kcm_keyboard_widget.h 
fa912c7f7daa497c20e3ce7ec4e40882d7d980af 
  kcontrol/keyboard/kcm_keyboard_widget.cpp 
e1bd830bca8d308470dbba40e5e5a0127672798b 
  kcontrol/keyboard/preview/KeyboardPainter.ui PRE-CREATION 
  kcontrol/keyboard/preview/TODO PRE-CREATION 
  kcontrol/keyboard/preview/kbpreviewframe.h PRE-CREATION 
  kcontrol/keyboard/preview/kbpreviewframe.cpp PRE-CREATION 
  kcontrol/keyboard/preview/keyaliases.h PRE-CREATION 
  kcontrol/keyboard/preview/keyaliases.cpp PRE-CREATION 
  kcontrol/keyboard/preview/keyboardlayout.h PRE-CREATION 
  kcontrol/keyboard/preview/keyboardlayout.cpp PRE-CREATION 
  kcontrol/keyboard/preview/keyboardpainter.h PRE-CREATION 
  kcontrol/keyboard/preview/keyboardpainter.cpp PRE-CREATION 
  kcontrol/keyboard/preview/keys.h PRE-CREATION 
  kcontrol/keyboard/preview/keys.cpp PRE-CREATION 
  kcontrol/keyboard/preview/keysym2ucs.h PRE-CREATION 
  kcontrol/keyboard/preview/keysym2ucs.cpp PRE-CREATION 
  kcontrol/keyboard/preview/keysymhelper.h PRE-CREATION 
  kcontrol/keyboard/preview/keysymhelper.cpp PRE-CREATION 
  kcontrol/keyboard/x11_helper.cpp fdadeeb851bac7511dc924a310c02f6f8a76bc84 

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


Testing
---


Screenshots
---

Keyboard Layout Preview
  http://git.reviewboard.kde.org/r/107202/s/813/


Thanks,

Andriy Rysin



Re: merging development branch into master

2012-11-04 Thread Andriy Rysin

On 11/04/2012 01:18 AM, Shaun Reich wrote:
well, you've got until november 8th (4 days according to my clock) 
until hard feature freeze which blocks even those on the planned 
feature list.


so, as my procrastinating self would say you've got plenty of time ;)

done: https://git.reviewboard.kde.org/r/107202/
I could not find kde-workspace or systemsettings groups so I've added it 
to kde-runtime


I would appreciate any feedback,
Thanks,
Andriy

P.S. I rebased the feature branch locally so we'll be able to FF (or 
just apply the patch)


Re: merging development branch into master

2012-11-04 Thread Weng Xuetian
On Sun, Nov 4, 2012 at 5:27 PM, Andriy Rysin ary...@gmail.com wrote:

 On 11/04/2012 01:18 AM, Shaun Reich wrote:

 well, you've got until november 8th (4 days according to my clock) until
 hard feature freeze which blocks even those on the planned feature list.

 so, as my procrastinating self would say you've got plenty of time ;)

 done: 
 https://git.reviewboard.kde.**org/r/107202/https://git.reviewboard.kde.org/r/107202/
 I could not find kde-workspace or systemsettings groups so I've added it
 to kde-runtime

 I would appreciate any feedback,
 Thanks,
 Andriy

 P.S. I rebased the feature branch locally so we'll be able to FF (or just
 apply the patch)


Hi all,

sorry for interrupt the thread, but I have some code that ported from
libgnomekbd (port to Qt), used in my own project, idea is similar, but
provides more feature though.

https://github.com/fcitx/kcm-fcitx/blob/master/layout/keyboardlayoutwidget.cpp

It's layout is based on parsing xkb model file, not hard code, and key
press can be displayed on the preview.
It's quite standalone, I'm not sure if you guys want to take a look at it.


Re: KDEREVIEW: share like connect and plasmate

2012-11-04 Thread Aaron J. Seigo
On Sunday, November 4, 2012 15:55:00 Pino Toscano wrote:
  Regarding plasmate: I fixed earlier a number of i18n issues (ugh...),
  and the layout of two .ui files.
 
 (A couple more today...)

Thanks for your thorough review; I'll make sure the people working on Plasmate 
start processing your findings and implemening fixes for them :)

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.