Re: merging development branch into master
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
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
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
--- 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
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
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
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.
