Re: Review Request: plasma-thunderbolt
On Wednesday, 15 May 2019 23:08:57 CEST Albert Astals Cid wrote: > El dimecres, 15 de maig de 2019, a les 15:27:07 CEST, Daniel Vrátil va escriure: > > Hi all, > > > > plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt > > KCM for Plasma. I initially submitted the code as a patch against > > plasma-desktop [0], where it got reviewed, but it was ultimately decided > > to better put it into a separate repository, since it's not just a KCM > > but also a library and a KDED module. I have backported all the changes > > from the Phabricator review back to the repository, so the code in the > > repo is identical to the one in the Phab review (minus buildsystem > > changes and a small build fix for clang). > > > > However, since this is still a new code, it must formally pass through > > kdereview before I can submit it into Plasma as a new module. > > > > Thus I'd kindly ask you to take one more look at the codebase [1] and let > > me know if there are any more issues to fix, or if we can proceed to > > include this in the next Plasma release. > > There's this cmake warning > > CMake Warning at /usr/lib64/cmake/KF5Package/KF5PackageMacros.cmake:74 > (message): KPackage components should be specified in reverse domain > notation. Appstream information won't be generated for kcm_bolt. > Call Stack (most recent call first): > src/kcm/CMakeLists.txt:22 (kpackage_install_package) I need some help with this - I looked into plasma-desktop, but all KCMs generate this warning and after renaming the package I just wasn't able to pair it with the library (which makes not sense to be called org.kde.plasma.thunderbolt.so) - so for now I'd just ignore the warning (we don't need Appstream data for KCM anyway, do we?). > clazy complains about a few Q_PROPERTY that should ideally either have a > NOTIFY signal or be marked as CONSTANT I fixed the ones in the code, I can't fix the ones in the generated DBus interfaces and adaptors. > it also complains about a few const slots that return values. Seems like > what you want is to actually mark them as invokable/scriptable and not as > slots? Good point, fixed those. Thanks for the review, Dan > > Cheers, > Albert > > > Thanks, > > - Dan > > > > [0] https://phabricator.kde.org/D19011 > > [1] https://cgit.kde.org/plasma-thunderbolt.git -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Review Request: plasma-thunderbolt
On Wednesday, 15 May 2019 15:55:01 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 15. Mai 2019, 15:27:07 CEST schrieb Daniel Vrátil:
> > Thus I'd kindly ask you to take one more look at the codebase [1] and let
> > me know if there are any more issues to fix, or if we can proceed to
> > include this in the next Plasma release.
>
> Pushed some small fixes to toplevel CMakeLists.txt
>
> Other things seen on quick look at code (also not tested runtime):
> * kded misses a Messages.sh file.
> * no COPYRIGHT license files in the repo
> * kde_enable_exceptions() duplicated a few times, perhaps only do in subdirs
> where needed or use of kde_target_enable_exceptions() if fitting
> * libkbolt being a private library could be reflected in the libname, also
> get install(TARGETS kbolt ${KDE_INSTALL_TARGETS_DEFAULT_ARGS} LIBRARY
> NAMELINK_SKIP)
All fixed, thanks for the review (and the fixes)!
Dan
>
> Cheers
> Friedrich
--
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc
Description: This is a digitally signed message part.
Re: Review Request: plasma-thunderbolt
On Wednesday, 15 May 2019 15:34:58 CEST Nate Graham wrote: > +1 from me; the original was good and this looks good too. > > One minor thing that I don't think should be a blocker: Could we copy > FindBolt.cmake into ECM with an eye towards not needing it here in a > future release? I think having FindBolt in ECM makes sense if there's a chance that some other components will use it. Right now I don't think anyone else is going to look for the Bolt daemon (as a runtime dependency). Dan > > Nate > > On 5/15/19 7:27 AM, Daniel Vrátil wrote: > > Hi all, > > > > plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt > > KCM for Plasma. I initially submitted the code as a patch against > > plasma-desktop [0], where it got reviewed, but it was ultimately decided > > to better put it into a separate repository, since it's not just a KCM > > but also a library and a KDED module. I have backported all the changes > > from the Phabricator review back to the repository, so the code in the > > repo is identical to the one in the Phab review (minus buildsystem > > changes and a small build fix for clang). > > > > However, since this is still a new code, it must formally pass through > > kdereview before I can submit it into Plasma as a new module. > > > > Thus I'd kindly ask you to take one more look at the codebase [1] and let > > me know if there are any more issues to fix, or if we can proceed to > > include this in the next Plasma release. > > > > Thanks, > > - Dan > > > > [0] https://phabricator.kde.org/D19011 > > [1] https://cgit.kde.org/plasma-thunderbolt.git -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Review Request: plasma-thunderbolt
Hi all, plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt KCM for Plasma. I initially submitted the code as a patch against plasma-desktop [0], where it got reviewed, but it was ultimately decided to better put it into a separate repository, since it's not just a KCM but also a library and a KDED module. I have backported all the changes from the Phabricator review back to the repository, so the code in the repo is identical to the one in the Phab review (minus buildsystem changes and a small build fix for clang). However, since this is still a new code, it must formally pass through kdereview before I can submit it into Plasma as a new module. Thus I'd kindly ask you to take one more look at the codebase [1] and let me know if there are any more issues to fix, or if we can proceed to include this in the next Plasma release. Thanks, - Dan [0] https://phabricator.kde.org/D19011 [1] https://cgit.kde.org/plasma-thunderbolt.git -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
On Thursday, March 28, 2019 3:39:54 PM CET Friedrich W. H. Kossebau wrote: > Am Donnerstag, 28. März 2019, 11:27:44 CET schrieb Daniel Vrátil: > > I'm completely fine with mandatory code review for everything and I'd be > > happy to have this in PIM. I think the biggest problem in PIM to overcome > > will be finding the reviewers - I dare say I'm currently the only one who > > has at least a little idea about what's going on in Akonadi, so getting > > for > > instance Laurent to review my Akonadi patches might be hard - same for me > > reviewing Laurent's KMail patches. This will require non-trivial amount of > > effort for all members of the community to gain deeper understanding of > > the > > other components within the project and a willingness to step up and do a > > code review even if they don't feel 100% comfortable with the code base. > > But I believe that in the long run the benefits clearly out-weight the > > cost. > So why do you not do this already? Why would you only do this is there is a > policy requiring you to do it? > And why do you think this policy-driven behavioural change will work or is > needed with everyone else? I wrote this with my PIM hat on and targeted the PIM community, without realizing this is a cross-post, so I apologize for the confusion. I believe each project should choose whatever workflow and policy suits them. That said, I do put up for review everything that is not Akonadi/PIM core (even changes to PIM components that are not "mine"). The reason I don't do this for Akonadi is that there's no-one really to review my code, because no- one else works on it, or at least that has been my perception of the situation lately. I've been thinking about bringing this topic up on the upcoming PIM sprint as I would like to have my code reviewed, I think it's a very good and healthy thing, but in case of KDE PIM, I think we need to agree that we'll actually review each others code, even if it's not "our own" code-base. > Also, how do you ensure the review is actually of quality? How do you ensure that the code people commit without a review is of quality? > And not just socially driven "+1 for my buddie!", where buddy then also > mentally shifts part of responsibility to other buddy, because, he, more > eyes means I do not need to do the full work myself, glitches will be > caught be them surely! Reviewer found a code formatting issue, done here, > review happened. This is a fair point, and I certainly am guilty of doing this occasionally in the past. But even reviewer can have a reviewer: if you keep accepting patches of "dubious quality" (break build, don't work, contain typos ...), someone else from the community will eventually notice and point out you should maybe be more careful with your reviews or pay attention to certain aspects (like "does it actually work?). > The opposite also has been seen, reviewers feel they need to do "real" > review and find things, so start to nitpick or to demand wrong changes, > wasting everyone's time. > > For myself I know I will happily have other people review my patches, but > only if there are qualified people to be expected to do it with the needed > quality in a reasonable time. > > Then, trying to force by that policy other people to become proper > specialist for certain other code projects to do qualified reviews, > actually is a trade- off. They will have less time for their actual code > project, becoming less a specialist there (or having time to review other > people's contribution to that project). > We need more contributors, not force existing contributors to distribute > their abilities & resources over more projects (and thus having less for > their actual one). AFAIU the policy right now is keep putting up patches for review until you get commit access, then continue doing so until you feel like you don't have to anymore. But having experienced contributors putting up their code for review is a good thing as it allows newcomers (and not just them!) to better understand what is happening in the project and simple reviews can be a good starting point for them to get more involved in the community. > I am also not aware of many contributors to KDE projects who are not capable > to make a responsible decision between the few obvious simple fixes and > those normal changes which better get feedback from others first. If one is > unsure about one's post-beer late-night quick hack, one will upload it for > review, no? At least if one's previous late-night commits turned out to be > late-night mental state impacted. This I think is somewhat related to the tooling as I said
Re: CI system maintainability
On Thursday, March 28, 2019 9:50:47 AM CET Kevin Ottens wrote: > Hello, > > On Thursday, 28 March 2019 09:41:29 CET Luca Beltrame wrote: > > In data giovedì 28 marzo 2019 09:29:22 CET, Kevin Ottens ha scritto: > > > at your screen or pair with you" in the past. Clearly this compromise > > > gets > > > somewhat exploited and that's especially bad in the case of a fragile > > > and > > > central component like KDE PIM. > > > > I'm not sure I agree. I can't speak for seasoned developers, but I've > > found > > myself in a situation (more than once) where the fix is trivial (compile > > error, missing ";", etc) and being forced to go through review would (IMO) > > unnecessarily raise friction. This is partially a problem of tooling IMO - review for even a trivial change will not cause any friction, if the tooling makes it super-easy and natural part of your workflow (and then you can always poke someone on IRC "hey, do you have 5 seconds for this super-simple review?"). Using arc with Phab is a bit annoying, so I can understand people fighting this. Gitlab with their "click this link to turn your commit into a merge request" is much better, plus it can be merged by the reviewer with a single click so you as a developer don't even need to care about the MR anymore. > I don't fully disagree with this (although I'd have stories on nefarious > typos even for what was supposed to be a "trivial fix"). But it becomes a > question of trade-off, IOW "how hurtful to the project mandatory reviews?" > vs "how hurtful to the project a central component being very regularly > broken?". > > I'd argue we're loosing more with the current state of PIM than we'd loose > with mandatory reviews. I'm completely fine with mandatory code review for everything and I'd be happy to have this in PIM. I think the biggest problem in PIM to overcome will be finding the reviewers - I dare say I'm currently the only one who has at least a little idea about what's going on in Akonadi, so getting for instance Laurent to review my Akonadi patches might be hard - same for me reviewing Laurent's KMail patches. This will require non-trivial amount of effort for all members of the community to gain deeper understanding of the other components within the project and a willingness to step up and do a code review even if they don't feel 100% comfortable with the code base. But I believe that in the long run the benefits clearly out-weight the cost. Btw we practice this policy at work and I do truly appreciate it, not only as a huge learning experience but so many times just having a second pair of eyes to glance over my code has revealed issues that sometimes almost make me question my career choice as a programmer :-) I think this is especially important for projects like PIM, where most of us contribute at work in between waiting for CI and replying to 15 Slack threads or in the evening after a long day Cao, Dan > Regards. -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Review request: plasma-pass
Hi Albert, thanks for the review! All the issues you mentioned are fixed in master now. Dan On Sunday, 16 December 2018 20:14:37 CET Albert Astals Cid wrote: > El dilluns, 10 de desembre de 2018, a les 14:49:28 CET, Daniel Vrátil va escriure: > > Hi folks, > > > > back in May I wrote a Plasma applet that serves as a GUI frontend for the > > pass password manager [0]. I blogged about it [1], but then somewhat > > forgot to make a release etc. Recently I started getting some emails from > > packagers where to get a tarballs so I think it's time to get some > > translations in and start doing official releases. Thus I'd like to ask > > for a review for inclusion in extragear. > > > > The way pass works is it has a directory in which each password is stored > > in a PGP-encrypted file, the name of the file is the name of the > > password. You can also create subfolders to organize the passwords. > > > > The code of the applet is a C++ model that watches said directory and > > exposes its content as a tree. There's also a filter proxy model which > > uses partial string matching code from KDevelop (so you can filter for > > "jd@f" and it matches "john@fmail.com"). > > > > The applet itself sits in systray, when activated it shows the top-level > > list of folders and password. Code-wise it contains a stack of list > > views, when entering a subfolder it pushes a new listview with content of > > that folder to the stack. Selecting a password decrypts it using gpg and > > puts it into clipboard for 45 seconds. After that it clears it from the X > > clipboard as well as Klipper. > > > > There's a bit of mess regarding focus handling in the QML, but the goal > > was to make the applet fully controllable via keyboard, which wasn't easy > > with my QML skills :) > > You have > > plasma-pass:master$ wcgrep X-KDE-PluginInfo-Name > ./package/metadata.desktop:27:X-KDE-PluginInfo-Name=plasmapass > ./package/metadata.desktop:34:X-KDE-PluginInfo-Name=org.kde.plasma.pass > > Which one is it? I guess the second? Then you also need to update your > Messages.sh to match that one if you change it, see applets/colorpicker in > kdeplasma-addons for example > > > You're using old style connects, use the power of the "new one". > > > PlasmaPass::PasswordsModel::Node has dtor but not copy-ctor, > copy-assignment. Which means that if someone ever does PasswordsModel::Node > a; > PasswordsModel::Node b = a; > things will break since the default implementations will just copy the > children vector and bad things will happen, i suggest you delete the copy > and assignment functions. > > > filterChanged is already a name of an existing function on > QSortFilterProxyModel (i know sucks), so maybe you could rename that signal > to something else? I guess this is not very important though but some > people may get confused when reading the code. > > > In the QML side you do a few == != that would be 0.001% faster doing > === and !==, it's considered better JS code since "weird" promotions are > not done, but your call. > > > I have not actually tested whether the thing works or not, but it's small > enough that i guess it does :D > > Just had time for this quick code review, hope you find it useful :) > > Cheers, > Albert > > > Looking forward to your feedback, > > Dan > > > > > > [0] https://www.passwordstore.org/ > > [1] https://www.dvratil.cz/2018/05/plasma-pass/ -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Review request: plasma-pass
Hi folks, back in May I wrote a Plasma applet that serves as a GUI frontend for the pass password manager [0]. I blogged about it [1], but then somewhat forgot to make a release etc. Recently I started getting some emails from packagers where to get a tarballs so I think it's time to get some translations in and start doing official releases. Thus I'd like to ask for a review for inclusion in extragear. The way pass works is it has a directory in which each password is stored in a PGP-encrypted file, the name of the file is the name of the password. You can also create subfolders to organize the passwords. The code of the applet is a C++ model that watches said directory and exposes its content as a tree. There's also a filter proxy model which uses partial string matching code from KDevelop (so you can filter for "jd@f" and it matches "john@fmail.com"). The applet itself sits in systray, when activated it shows the top-level list of folders and password. Code-wise it contains a stack of list views, when entering a subfolder it pushes a new listview with content of that folder to the stack. Selecting a password decrypts it using gpg and puts it into clipboard for 45 seconds. After that it clears it from the X clipboard as well as Klipper. There's a bit of mess regarding focus handling in the QML, but the goal was to make the applet fully controllable via keyboard, which wasn't easy with my QML skills :) Looking forward to your feedback, Dan [0] https://www.passwordstore.org/ [1] https://www.dvratil.cz/2018/05/plasma-pass/ -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: kdereview: ksmtp
Hi Rolf, thanks for the review, sorry it took me so long to get to you. On Tuesday, May 16, 2017 8:05:17 PM CEST Rolf Eike Beer wrote: > Am Donnerstag, 11. Mai 2017, 17:03:01 schrieb Daniel Vrátil: > > Hi, > > > > please review ksmtp, which is now in kdereview. > > -the CMakeLists.txt has a mix of spaces inside () or not Fixed > > -in loginjob, line 173, you check for code 25. Should this be 250? Or is > that 25*? Where is ServerResponse actually defined, I only see the header. ServerResponse is defined in sessionthread.cpp for some reason. ServerResponse::isCode() indeed checks the prefix of the response, so isCode(25) returns true for any 25x return code. > -does that support pipelining? I don't see any sync points, so I guess not. Not yet, but it's next on the todo list. > -there is a longstanding bug in KMail that it violates the RfC when it has a > problem with authentication (e.g. password rejected), that is does not > properly QUIT the SMTP session, but just closes the socket. Is that > properly handled? It is properly handled now. Calling Session::quit() does not close the connection but sends QUIT command and only closes the connection after a response arrives from the server (unless the server closes it first of course). It's now up to the user to ensure that the Session object is not destroyed until the state changes to Disconnected after calling Session::quit(). Dan > > Greetings, > > Eike -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: kdereview: ksmtp
On Thursday, May 11, 2017 11:11:11 PM CEST Albert Astals Cid wrote: > El dijous, 11 de maig de 2017, a les 17:03:01 CEST, Daniel Vrátil va escriure: > > Hi, > > > > please review ksmtp, which is now in kdereview. > > Are tests supposed to pass? > > 2: QFATAL : SmtpTest::testLoginJob(Plain auth ok) Received signal 11 Hmm, it passes here. Must be some timing issue. I'll see if I can reproduce it on my other system. Dan > > Cheers, > Albert > > > KSMTP is a small simple library with a KJob-based API similar to KIMAP or > > KDAV to send mime messages via SMTP. It was initially written in 2011 by > > Gregory Schlomoff but since then it's been lying around in playground > > without any interest or use. I have recently picked it up, ported to > > Frameworks and improved the job handling and authentication to make the > > library ussable for KDE PIM and would like to have it released as part of > > KDE Applications 17.08. > > > > KDE PIM currently uses a custom KIO Slave to send messages via SMTP, which > > is hard to maintain and extend. Having a Job-based library like KSmtp will > > make it much easier for us to introduce support for example for Google > > XOAUTH2 authentication mechanism. > > > > Thanks, > > Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) signature.asc Description: This is a digitally signed message part.
Re: kdereview: ksmtp
Thanks, totally forgot to run clazy/krazy on the codebase. On Thursday, May 11, 2017 10:25:36 PM CEST Allen Winter wrote: > ran clazy level2 . no hits > > ran krazy checks and it found: > . Check for C++ ctors that should be declared 'explicit' [explicit]... 1 > issue found ./autotests/fakeserver.h: line#36 (1) Fixed > > . Check for normalized SIGNAL and SLOT signatures [normalize]... 4 issues > found ./src/session.cpp: SIGNALS: line#285,286 (2) > ./src/session.cpp: SLOTS: line#285,286 (2) Fixed (converted to the new connect() syntax) > . Check for strings used improperly or should be i18n. [strings]... 5 issues > found ./autotests/fakeserver.cpp: QLatin1String issues > line#172,175,190,201,218 (5) Those are false positives. I guess krazy assumes .startsWith() to be QString::startsWith(), while those are QByteArray::startsWith(). Dan > On Thursday, May 11, 2017 11:03:01 AM EDT Daniel Vrátil wrote: > > Hi, > > > > please review ksmtp, which is now in kdereview. > > > > KSMTP is a small simple library with a KJob-based API similar to KIMAP or > > KDAV to send mime messages via SMTP. It was initially written in 2011 by > > Gregory Schlomoff but since then it's been lying around in playground > > without any interest or use. I have recently picked it up, ported to > > Frameworks and improved the job handling and authentication to make the > > library ussable for KDE PIM and would like to have it released as part of > > KDE Applications 17.08. > > > > KDE PIM currently uses a custom KIO Slave to send messages via SMTP, which > > is hard to maintain and extend. Having a Job-based library like KSmtp > > will make it much easier for us to introduce support for example for > > Google XOAUTH2 authentication mechanism. > > > > Thanks, > > Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
kdereview: ksmtp
Hi, please review ksmtp, which is now in kdereview. KSMTP is a small simple library with a KJob-based API similar to KIMAP or KDAV to send mime messages via SMTP. It was initially written in 2011 by Gregory Schlomoff but since then it's been lying around in playground without any interest or use. I have recently picked it up, ported to Frameworks and improved the job handling and authentication to make the library ussable for KDE PIM and would like to have it released as part of KDE Applications 17.08. KDE PIM currently uses a custom KIO Slave to send messages via SMTP, which is hard to maintain and extend. Having a Job-based library like KSmtp will make it much easier for us to introduce support for example for Google XOAUTH2 authentication mechanism. Thanks, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) signature.asc Description: This is a digitally signed message part.
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday, July 31, 2015 09:55:30 PM Thomas Lübking wrote:
> On Freitag, 31. Juli 2015 19:29:53 CEST, Ingo Klöcker wrote:
> > I also do not see the point in nagging the user after a certain period of
> > time if nobody else ever cared to comment on the bug. Feels a bit like
> > little kids asking "Are we there yet?" over and over again.
>
> The idea is not only to get rid of cruft (bugs which "auto-fixed" either
> implicitly by eg. code cleanups or as dupes) but also to remind developers
> by resubmission (eg. when a bug fell off the table during high activity
> periods)
> > I do see the point in Daniel's proposal because the time a release goes
> > EOL
> > feels like a sensible point in time for asking whether the bug still
> > exists.
> - when do "unspecified" version bugs EOL?
"Unspecified" version is IMO a silly thing in the first place. How is
developer supposed to fix a bug if he does not know what version it happens
with? I can see the point of it for wishes, but there I think it was agreed
above that auto-closing should not affect those.
> - when do "git" version bugs EOL?
Hmm, good question. Maybe when a new version is released, all "git" bug
reports should be moved to that version?
> - what defines EOL? supported versions in bugzilla?
Could be. That of course assumes someone maintains the list.
> - What if a user reports a bug against a version that turns EOL next week?
Then either the bug can be reproduced in newer version too and should be
reassigned, or it has already been fixed and will be closed. If your concern
is that the bug report would not get the "about to go EOL" notification, I see
two ways:
1) there's a bot watching for new bugs and it will add the "this
version is
about to go EOL on $data" comment automatically,
2) or we explain the situation again in the final closing comment so
that
users know they still can reassign to newer version and reopen
> - Do we want bugs to be forgotton for 3 years or more and then tell the
> reporter: "we're now dropping support, sorry that nobody ever cared. if you
> want this to go unnoticed for another three years, please reopen the bug"?
>
> A friendly reminder for user and developer (eg. until the bug could be
> CONFIRMED) to keep bugreports alive seems the better - and half a year is
> not exactly "nagging", but will also typically cross many distro updates.
I like the idea of a nag and I don't think it necesarily conflicts with the
ideas above. Having a weekly/bi-weekly nags to developers would IMO work
("hey, you have 10 new bugs this week that you did not comment on or confirmed
yet, please look at them asap"). If the developer ignores the bugs even after
that then it becomes a different problem, but that I don't know how to solve.
Dan
>
> Cheers,
> Thomas
--
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc
Description: This is a digitally signed message part.
Re: RFC: KDE Bugzilla Bugs Expiration
On Friday, July 31, 2015 10:12:00 AM Christoph Cullmann wrote: > Hi, > > I think one of the problems with our current Bugzilla database is that it > contains a lot of "old" bugs and wishs. True that! > > As the manpower is limited and we sometimes not even keep up with the > incoming new bugs, might it be a good idea to adopt a similar strategy like > the Qt Project and expire bugs that got not changed since more than one > year? > > The idea would that a scripts closes all bugs that have no activity in the > last year e.g. on a weekly basis and the closing comment would contain some > gentle note that if the bug is still an issue, the reporter (or any person > on CC) can just reopen it again. We were actually discussing something similar for KDE PIM but our idea was based on Fedora, i.e. closing all bugs for given release when the release goes EOL. There is a comment added by a bot 3 weeks before EOL stating that the release will go EOL and if user thinks the bug is still valid in newer/current release, they should re-assign to newer release. When the release actually goes EOL all bugs still assigned to it are closed. The advantage of this approach IMO is that it also clears out bugs where the reporters are no longer available/willing to provide additional info to devs and at the same time without losing bugs which might be important yet non-trivial to fix (read: take more than a year for a dev to get there). Especially for KDE PIM, given the size of the userbase and the amount of developers (3), bugs often take more than a year to get to and to be fixed. > I think this would make a lot of time consuming bug triaging much easier. Cannot agree more :) Cheers, Daniel > > Greetings > Christoph -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi)
Re: Moving akonadi from kdesupport and akonadi-search from playground
On Friday, July 24, 2015 10:24:10 AM laurent Montel wrote: > Le Friday 24 July 2015, 00:13:48 Albert Astals Cid a écrit : > > El Dimarts, 21 de juliol de 2015, a les 13:52:01, Daniel Vrátil va escriure: > > > On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote: > > > > Hi all, > > > > > > > > we (the KDE PIM team) kinda screwed up when we forgot to communicate > > > > our > > > > intentions about > > > > next KDE PIM release with the release team and we ended up in a > > > > situation that we have > > > > some repositories in modules from which they cannot be released as > > > > part > > > > of KDE Applications, > > > > so releasing KF5-based KDE PIM as part of KDE Applications is > > > > currently > > > > endangered. > > > > > > > > Normally I'd have to ask for the 2-week review period before moving > > > > the > > > > repos but since we are > > > > under a big time pressure and because the modules have both proven > > > > themselves (see below), > > > > I kindly ask for those repositories to be granted an exception to the > > > > review period and they > > > > can be moved right away. > > > > > > > > akonadi-search repository contains PIM-specific code that originally > > > > lived in Baloo repository > > > > and was split out when Baloo switched to KF5. We only ported the code > > > > to > > > > KF5 and removed all > > > > mentions of "Baloo" from code (it's now Akonadi::Search namespace). > > > > Technically this code > > > > already went through review when Baloo has been reviewed for move from > > > > playground, and also > > > > during Baloo development, and has been actively used with KDE PIM 4.x > > > > for several releases. > > > > > > > > akonadi I think has proven itself well enough in during the years :) > > > > > > > > I'd like to move both repositories to kde/pim module where other KDE > > > > PIM > > > > repos (mostly those > > > > split from kdepimlibs) currently live. > > > > > > > > If that's fine with everyone I'd request the move ASAP. > > > > > > Hi all, > > > > > > if there are no objections, I'll request the repos to be move later in > > > the > > > afternoon. > > > > Please let's get this done and end this painful release asap. > > I don't know why it did not do it yet. > > Dan ask it 2 days ago but no news. > > I don't know why it was not done yet. > > Regards The repositories have been moved (thanks Ben!) and I have notified release team about what repos we want to release. Thanks to everyone, and sorry for the noise we caused :) Cheers, Daniel > > > Albert > > > > > Thanks, > > > Dan > > > > > > > Cheers, > > > > Daniel -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi)
Re: Moving akonadi from kdesupport and akonadi-search from playground
On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote: > Hi all, > > we (the KDE PIM team) kinda screwed up when we forgot to communicate our > intentions about > next KDE PIM release with the release team and we ended up in a > situation that we have > some repositories in modules from which they cannot be released as part > of KDE Applications, > so releasing KF5-based KDE PIM as part of KDE Applications is currently > endangered. > > Normally I'd have to ask for the 2-week review period before moving the > repos but since we are > under a big time pressure and because the modules have both proven > themselves (see below), > I kindly ask for those repositories to be granted an exception to the > review period and they > can be moved right away. > > akonadi-search repository contains PIM-specific code that originally > lived in Baloo repository > and was split out when Baloo switched to KF5. We only ported the code to > KF5 and removed all > mentions of "Baloo" from code (it's now Akonadi::Search namespace). > Technically this code > already went through review when Baloo has been reviewed for move from > playground, and also > during Baloo development, and has been actively used with KDE PIM 4.x > for several releases. > > akonadi I think has proven itself well enough in during the years :) > > I'd like to move both repositories to kde/pim module where other KDE PIM > repos (mostly those > split from kdepimlibs) currently live. > > If that's fine with everyone I'd request the move ASAP. Hi all, if there are no objections, I'll request the repos to be move later in the afternoon. Thanks, Dan > > Cheers, > Daniel -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi)
Re: Moving akonadi from kdesupport and akonadi-search from playground
On 20.07.2015 16:44, Martin Sandsmark wrote: On Mon, Jul 20, 2015 at 04:17:16PM +0200, Daniel Vrátil wrote: We only ported the code to KF5 Unless I'm misunderstanding something, isn't this a quite significant change? From experience even seemingly simple ports can introduce pretty serious breakage in edge cases. True, although the core code is mostly plain Qt wrapper around Xapian. We've (me, Laurent and few people on #kontact) been using it for couple weeks - months now without any problems. Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
Moving akonadi from kdesupport and akonadi-search from playground
Hi all, we (the KDE PIM team) kinda screwed up when we forgot to communicate our intentions about next KDE PIM release with the release team and we ended up in a situation that we have some repositories in modules from which they cannot be released as part of KDE Applications, so releasing KF5-based KDE PIM as part of KDE Applications is currently endangered. Normally I'd have to ask for the 2-week review period before moving the repos but since we are under a big time pressure and because the modules have both proven themselves (see below), I kindly ask for those repositories to be granted an exception to the review period and they can be moved right away. akonadi-search repository contains PIM-specific code that originally lived in Baloo repository and was split out when Baloo switched to KF5. We only ported the code to KF5 and removed all mentions of "Baloo" from code (it's now Akonadi::Search namespace). Technically this code already went through review when Baloo has been reviewed for move from playground, and also during Baloo development, and has been actively used with KDE PIM 4.x for several releases. akonadi I think has proven itself well enough in during the years :) I'd like to move both repositories to kde/pim module where other KDE PIM repos (mostly those split from kdepimlibs) currently live. If that's fine with everyone I'd request the move ASAP. Cheers, Daniel -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
Re: [Kde-pim] KF5-QT5 branchgroup - jobs that need developeer attention
On 15.04.2015 09:44, Scarlett Clark wrote: Here is a list of mostly compile failures and other tid bits that need to be resolved by the respective developers. If you know the developer of a project and they are not on this list please forward this. All jobs can be viewed at : https://build-sandbox.kde.org/ Most of these are osx failures. If osx is not to be supported, I need to know that too. Questions - concerns - just ask. Thanks, Scarlett kdepimlibs - osx - compile failure breaks: kalarmcal, kdepim, kmailtransport 00:30:58 In file included from /Users/jenkins/builds/kdepimlibs/kf5-qt5/akonadi/src/core/exception.h:25: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/QByteArray:1: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qbytearray.h:37: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qrefcount.h:37: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qatomic.h:39: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qbasicatomic.h:58: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qatomic_x86.h:38: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qgenericatomic.h:38: 00:30:58 In file included from /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qtypeinfo.h:34: 00:30:58 /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qtypetraits.h:108:1: error: unknown type name 'QT_BEGIN_NAMESPACE' 00:30:58 QT_BEGIN_NAMESPACE This looks like a problem with Qt 5 deployment on the CI? I know that it would imply all other tasks failing with the same error, but I have no idea why this should compile on Linux and not on OSX. kdepim seems to fail due to missing grantlee dependency. Of course even with grantlee available, kdepim won't build until we figure out what's wrong with kdepimlibs. 00:37:47 CMake Error at CMakeLists.txt:91 (find_package): 00:37:47 Could not find a package configuration file provided by "Grantlee5" 00:37:47 (requested version 5.0) with any of the following names: 00:37:47 00:37:47 Grantlee5Config.cmake 00:37:47 grantlee5-config.cmake Also looks like kdepim-runtime kf5-qt5 is missing on the sanbox CI - could you please add it? Thanks, Dan ___ KDE PIM mailing list kde-...@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/ -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
Re: The Future or KDE PIM Releases
On Tuesday, April 14, 2015 12:17:39 AM Albert Astals Cid wrote: > El Diumenge, 12 d'abril de 2015, a les 11:31:26, Daniel Vrátil va escriure: > > Greetings from Toulouse! > > > > Instead we will aim towards releasing KF5-based KDE PIM with "Akonadi 1" > > in > > the next release of KDE Applications in August. That means we now have > > about 4 months to make sure that there are no regressions caused by > > changes in Qt behavior - this should be manageable and not much effort > > really. This is an internal change more or less, users won't notice > > anything. > > Meaning we stop releasing the LTS 4.14 by then? Yes - that is assuming nothing goes terribly wrong and we would have to postpone the Qt 5 release. Dan > > Cheers, > Albert
The Future or KDE PIM Releases
Greetings from Toulouse!
We've been discussing the plans for releases of Akonadi(Next) and KDE PIM as a
whole on the PIM sprint, because the current situation is kinda unclear and
harmful for the project.
Now that we have a better idea of what Akonadi Next will be like, we decided
that we don't want to just basically stop working on PIM and focus all our
efforts towards Akonadi Next because that would cause the entire PIM to be in
sort of a limbo for who-knows-how-long and that would not be good for our
users and for the project in general. We are already losing users so freezing
the development of the project does not sound like a good idea.
Instead we will aim towards releasing KF5-based KDE PIM with "Akonadi 1" in
the next release of KDE Applications in August. That means we now have about 4
months to make sure that there are no regressions caused by changes in Qt
behavior - this should be manageable and not much effort really. This is an
internal change more or less, users won't notice anything.
Once the release is done, Christian will start focusing on Akonadi Next while
me, Laurent and others will focus on preparing PIM applications for the switch
to Akonadi Next (alongside normal development and maintenance). This involves
mostly getting rid of all Akonadi references from the code and replacing them
with domain-specific objects ("Email", "MailFolder" ,"Calendar", etc.), and
writing a translation layer that will translate between Akonadi and the
domain-specific objects. This is basically what Zanshin does and it works
really really well for them. It's something we would have to do with Akonadi
Next anyway. Once this is done (and once Akonadi Next is done) we simply
switch the translation layers in applications to use Akonadi Next instead of
Akonadi and be done with it. We find this to be the least disruptive approach
for users since we will have stable and regular releases of KDE PIM while
steadily working towards the switch and then just switching to Akonadi Next
at some point, ideally without users really noticing.
However we realize that the amount of KDE PIM developers is not really enough
to cover all the PIM projects and applications, so we decided that we will
only release components that have an (active) maintainer and that we feel we
have enough manpower to work on. We will do an extragear release of the
remaining projects at the same time as KDE Applications, but with no guarantee
of further releases or maintenance.
This is the current state - stuff that gets released in August with KDE
Applications is considered "PIM Core", everything else is extragear.
Akregator
- needs maintainer
- release from extragear, unless a maintainer appears, then release with
Applications as part of PIM core
Blogilo:
- needs maintainer
- no release in August, unless a maintainer appears, then release with
Applications as part of PIM core
KAddressBook
- maintained by Laurent
- part of PIM core, release with KDE Applications in August
KOrganizer
- maintained by Sergio
- part of PIM core, release with KDE Applications in August
KAlarm
- maintained by David Jarvie
- release standalone in extragear, if David is willing to take care of that,
otherwise no release
Kleopatra
- needs maintainer
- part of PIM core, release with KDE Applications in August
KMail
- maintained by Laurent
- part of PIM core, release with KDE Applications in August
KNotes
- maintained by Laurent
- part of PIM core, release with KDE Applications in August
Kontact
- maintained by Laurent
- part of PIM core, release with KDE Applications in August
With regard to Akonadi resources, we will NOT release KDE Accounts, Kolab
Proxy (the old Kolab resource), Facebook, OpenXChange, Tags, NNTP and
KBookmarks resources. We are desperately looking for maintainers for Maildir
and MBox resources.
Regarding our underlaying libraries, we intend to release the following
frameworks as soon as possible, since they are kdelibs4support-free, so we
only need to review them:
- GPGME++
- KContacts
- KLDAP
- KMbox
- Syndication
In the next rounds we will release the following frameworks, after we removed
their kdelibs4support dependency:
- KMime
- KIMAP
- KCalCore
We believe that especially KContacts, KCalCore, KMime and KIMAP will draw a
lot of attention to KDE Frameworks, since there seems to be a demand for this
kind of libraries.
The remaining kdepimlibs libraries (including Akonadi libs) will be released
with KDE Applications as "PIM libraries".
We very much encourage other developers to step up for maintainership of any
of the frameworks or applications above to reduce the workload of the current
PIM team and help make KDE PIM awesome again.
We would welcome feedback and opinions from other PIM devs who are not here in
Toulouse. If everyone is fine with this proposal, we will
Re: Plasma 5.2 bits for kdereview
On Friday, December 19, 2014 06:46:11 PM Luigi Toscano wrote: > Jonathan Riddell ha scritto: > > Plasma 5.2 is due out next month and there's a few KDE projects which > > would be good to be included. Please review these for inclusion in > > kde/workspace.. > > > > > kscreen and libkscreen maintained by Dan Vrátil. libkscreen is already > > released with Plasma but isn't in kde/workspace. > > > > https://projects.kde.org/projects/extragear/libs/libkscreen > > https://projects.kde.org/projects/extragear/base/kscreen > > I disagree with moving libkscreen to kde/workspace. It is a dependency for > at least one application (Okular), which has no Framework version for now > but it will have it. It would make more sense to have libkscreen in > Frameworks, like libnm* AFAIK Okular is using KScreen only to get DPI info, which was not provided by QScreen in Qt 4. In Qt 5 you already have DPI API in QScreen, so you should not need KScreen anymore. Dan -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi Software Engineer - KDE Desktop Team, Red Hat Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: [Kde-pim] kdepimlibs splitting done
On Friday, December 12, 2014 05:19:00 AM Aleix Pol wrote: > Hi, > I have performed the first round of kdepimlibs splitting tonight, as we > agreed. Below you can see the for reference how the splitting was > performed. > > Dan, Laurent, can you give me the ok? Then we can proceed to remove > the modules from the kdepimlibs repository. The history of all modules seems to be complete, so +1 from me to remove them from kdepimlibs. Thanks a lot for taking care of the splitting, Aleix! I guess the next steps are to review them, find maintainers and decide when they will get released. I would propose that this is discussed on the next IRC meeting on Monday (I'll send a separate email about that). Cheers, Daniel > > Cheers! > Aleix > > kcontacts -- [1] > kxmlrpcclient -- git filter-branch --tag-name-filter cat > --subdirectory-filter kxmlrpcclient/ -- --all --tags > kblog -- git filter-branch --tag-name-filter cat > --subdirectory-filter kblog/ -- --all --tags > kcalcore-- git filter-branch --tag-name-filter cat > --subdirectory-filter kcalcore/ -- --all --tags > kcalutils -- git filter-branch --tag-name-filter cat > --subdirectory-filter kcalutils/ -- --all --tags > kholidays -- git filter-branch --tag-name-filter cat > --subdirectory-filter kholidays/ -- --all --tags > kalarmcal -- [2] > kimap -- git filter-branch --tag-name-filter cat > --subdirectory-filter kimap/ -- --all --tags > kldap -- git filter-branch --tag-name-filter cat > --subdirectory-filter kldap/ -- --all --tags > kidentitymanagement -- [3] > kmbox -- git filter-branch --tag-name-filter cat > --subdirectory-filter kmbox/ -- --all --tags > kmime -- git filter-branch --tag-name-filter cat > --subdirectory-filter kmime/ -- --all --tags > kontactinterface-- git filter-branch --tag-name-filter cat > --subdirectory-filter kontactinterface/ -- --all --tags > kpimtextedit-- git filter-branch --tag-name-filter cat > --subdirectory-filter kpimtextedit/ -- --all --tags > ktnef -- git filter-branch --tag-name-filter cat > --subdirectory-filter ktnef/ -- --all --tags > kmailtransport -- git filter-branch --tag-name-filter cat > --subdirectory-filter mailtransport/ -- --all --tags > syndication -- git filter-branch --tag-name-filter cat > --subdirectory-filter syndication/ -- --all --tags > gpgmepp -- [4] > > [1] > time git filter-branch --tag-name-filter cat --prune-empty --index-filter ' > git read-tree $GIT_COMMIT:kcontacts || git read-tree --empty > git read-tree --prefix kcontacts $GIT_COMMIT:kcontacts > git read-tree --prefix kabc $GIT_COMMIT:kabc > true > ' master --all --tags > > [2] > time git filter-branch --tag-name-filter cat --prune-empty --index-filter ' > git read-tree $GIT_COMMIT:kalarmcal || git read-tree --empty > git read-tree --prefix kalarm/cal/ $GIT_COMMIT:kalarm/cal/ > true > ' master --all --tags > > [3] > time git filter-branch --tag-name-filter cat --prune-empty --index-filter ' > git read-tree $GIT_COMMIT:kidentitymanagement || git read-tree > $GIT_COMMIT:kpimidentities > true > ' master --all --tags > > [4] > time git filter-branch --tag-name-filter cat --prune-empty --index-filter ' > git read-tree $GIT_COMMIT:gpgme++ || git read-tree --empty > git read-tree --prefix qgpgme/src/ $GIT_COMMIT:qgpgme/src > true > ' master --all --tags > ___ > KDE PIM mailing list kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/ -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi Associate Software Engineer KDE Desktop Team, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: Moving KScreen and libkscreen to extragear
On Monday 08 of July 2013 19:19:08 David Edmundson wrote: > Code wise, things looks pretty good. > > Minor comments: > - the library is GPL, not LGPL which is the norm for libraries. > Is this deliberate? No, I don't think so. I'm just fine with changing it to LGPL (and I guess Alex will be too). > > - Inside kscreen you have a copy of the metadata.desktop file twice. > Just have the one and install it to the two places. Fixed. > You might also want to use the version number from your main CMakeLists.txt > in your .desktop file too, otherwise updating can get messy. Fixed, thanks. > > -Generator::biggestOutput > rename the local variable "total"...it's not a total of anything, I had to > re-read it 10 times to realise the code was correct. Right, confused me too :-) Fixed. > In general though +1 from me. Thanks :) Dan -- Daniel Vrátil KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: Fwd: looking for phonon gstreamer maintainer
On Wednesday 25 of September 2013 12:35:25 Harald Sitter wrote: > -- Forwarded message -- > From: Harald Sitter > Date: Mon, Sep 23, 2013 at 4:55 PM > Subject: looking for phonon gstreamer maintainer > To: "For discussion of multimedia (sound/video) issues under KDE" > > > > Ahoy, > > since everyone who ever was/is/wanted to be Phonon GStreamer > maintainer is either busy or has no interest in it, the backend has as > of right now no actual maintenance. > > If anyone wishes to step up and move the backend forward now is the > time to do it. I'd like to note that this is not a one-man job though > and I am going to continue to be supporting developer. > > In the unfortunate case that no one is willing enough we will have to > look at the possibility of moving the backend out of the support > scope, leaving Phonon VLC as the only actively supported backend on > all platforms. > > As immediate result I will likely have to demote the backend's initial > preference for the upcoming 4.7.0 release below Phonon VLC's. Hi, in Fedora we have a big interest in keeping phonon-gstreamer alive, namely because we can't ship phonon-vlc due to legal issues (you know, US company, software patents and what not...) and our users would not probably be very happy if we had no phonon working backend in Fedora KDE. So far we are happy with gstreamer-0.10, but we realize that sooner or later we will have to start looking into supporting gstreamer-1.0. Even if we are able to keep phonon with gstreamer-0.10 alive by patching the hell out of it in downstream, at some point we will be forced to drop it, and then we would have nothing to switch to. So I'm willing to help keeping phonon-gstreamer alive in upstream (I'm not saying I'll be able to fix all the bugs) and slowly look into the gst-1.0 port. I'm not able to fully maintain yet another project (I already have more than enough :-)), but as said above, I can contribute to keep it alive and push it over the hill to gstreamer-1.0 (come on, how hard can it be? ;-)) Luckily for me, we have a GStreamer guy in the office, so I can get some help from him if necessary :) Cheers, Dan > > HS -- Daniel Vrátil KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: Help solving an IMAP SSL bug
On Tuesday 20 of August 2013 20:42:05 Richard Moore wrote: > On 19 August 2013 10:58, Daniel Vrátil wrote: > > Because it's a socket error KSslSocket will emit socketError() and IMAP > > resource will try to reconnect. The interesting part here is, that calling > > QAbstractSocket::disconnect() will emit the error again (probably it's > > trying to write something to the socket?) and so we end up in an endless > > loop, when we try to disconnect on an error, which causes an error, on > > which we try to disconnect > > You should call abort() rather than disconnect() here. Thanks, that seems to solve the problem with disconnect() generating the error, but it does not solve the problem: after calling abort() in error handler, we try to reconnect. But calling KTcpSocket::connectToHostEncrypted() will generate the same error, so we end up in a loop anyway and the resource is not able to successfully establish a secured connection until it's restarted. Cheers, Dan > > Cheers > > Rich. -- Daniel Vrátil Associate Software Engineer, KDE Desktop Team Red Hat, Inc GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Help solving an IMAP SSL bug
(cross-posting, because this might actually be a bug in KSslSocket or even Qt) Hi, we currently have a quite annoying issue with Akonadi IMAP resource and SSL connection and because my knowledge of this topic is limited, I'm asking you guys for help. When connection to an IMAP server is lost (timeout, server drops connection, etc.) and the resource tries to reconnect it fails due to QAbstractSocket::SslHandshakeFailedError error and so does every next attempt until the Akonadi resource is restarted. Because it's a socket error KSslSocket will emit socketError() and IMAP resource will try to reconnect. The interesting part here is, that calling QAbstractSocket::disconnect() will emit the error again (probably it's trying to write something to the socket?) and so we end up in an endless loop, when we try to disconnect on an error, which causes an error, on which we try to disconnect This results in a constant network traffic around 20kbps and means that we are effectively DOSing the IMAP server, which in the worst case can result in provider banning the IP address. Surprisingly this happens only with some IMAP servers. I can reliably reproduce with Cyrus and Zimbra servers, but it does not happen with Dovecot server or Gmail. Martin Briza was already looking into this problem in June [0], but got to no real solution, except for adding the missing mapping from QAbstractSocket::SslHandshakeFailedError to KTcpSocket::SslHandsakeFailedError, so we are now able to detect this error, but we still have on clue how to act on it and it does not really solve the fact that we can't establish a new connection. Have anyone experienced something similar in past? Any ideas where to look? Thanks, Dani [0] http://lists.kde.org/?l=kde-core-devel&m=137050526303582&w=2 -- Daniel Vrátil Associate Software Engineer, KDE Desktop Team Red Hat, Inc GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: Moving KScreen and libkscreen to extragear
On Thursday 04 of July 2013 22:28:27 Burkhard Lück wrote: > Am Donnerstag, 4. Juli 2013, 01:13:36 schrieb Àlex Fiestas: > > I would like to request a review so we can move KScreen and libkscreen to > > extragear/base. > > > > KScreen is a new manager for outputs such: monitors, projectors, embedded > > > > screens... It contains: > > -KDED Module which does some magic by auto configuring the screens, > > and > > > > saving configurations whenever they are changed. > > > > -KCM allowing to apply any configuration (change resolution, > > rotate...) > > -A plasmoid that does little at the moment. > > It has six qtTr() calls for gui strings, but these messages are not > extracted to l10n-kde4/templates/messages, reported already some time ago > here: > > https://bugs.kde.org/show_bug.cgi?id=316548#c1 Hi, it should be fixed now. I replaced qsTr calls with i18nc and added some context descriptions. Cheers, Dan > > > -A library that offers a good abstraction so we can support multiple > > > > backends. At the moment we support XRandR 1.1 and 1.2/3/4. -- Daniel Vrátil Associate Software Engineer, KDE Desktop Team Red Hat, Inc GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
Re: Buy Sprint tickets !
On Saturday 02 of March 2013 23:23:30 Àlex Fiestas wrote: > Just a reminder that we should buy the plane tickets ASAP so we can get the > cheaper deals. The sprint is only 40 days away. > > See you in Brno ! I already got my bus ticket to get to the office in the morning :P Looking forward to meet you all there :-) Dan -- Daniel Vrátil Associate Software Engineer, KDE Desktop Team Red Hat, Inc GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part.
