Re: Progress is good for us but bad for documentation
On 6/9/21 6:02 PM, Johannes Zarl-Zierl wrote: Hi, Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer: I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. [...] So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Is this an effort with universal scope, or is there a limit? Obviously you are at least talking about the wikis. Are you also (at the current time) talking about other websites and/or application handbooks? It is meant as an open question. All answers welcome. Of course not everything can be worked on now. But compiling a list of stuff to work on will help pushing and coordinating the work. heers, Frederik
Progress is good for us but bad for documentation
Hi, we are all making progress but the way to notice it can be painful. Looking at something you created years ago might make you cringe, but that's actually a good sign. It indicates, that you made progress. KDE is making progress as well. Here the indicator is outdated documentation. There is still quite some documentation from KDE 4 times where the technology documented already moved on to more modern times. And just as your résumé needs updating once in a while to reflect your newly acquired skills and references, documentation needs updating so it reflects the current state of KDE (as in software, places to communicate, go-to people for all the several parts of the projects, etc.). I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. So to let me know, you can send me an email (on- or off-list) and I will create a ticket for it where further discussion can take place. Of course you could theoretically open a ticket yourself but we still need to find the best place for those topics. I will keep you posted on that one. :) So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Thanks a bunch. :) Cheers, Frederik
Re: KRandom regression + fix
Am 27.04.2016 23:45 schrieb Albert Astals Cid: El dimecres, 27 d’abril de 2016, a les 11:42:46 CEST, Frederik Schwarzer va escriure: Am 27.04.2016 08:48 schrieb Johannes Huber: > thanks for the patch. When i read "randon numbers were predictable" > instantly > a alarm bell rings in my head. Is this a security issue? The docs of rand() state that you should not use it for serious business like cryptography http://en.cppreference.com/w/cpp/numeric/random/rand and the most serious business I could see within KDE was PIN generation for Bluetooth pairing. But you can never know who is using it for what outside of the KDE infrastructure. Since I am neither a core developer (just maintaining a game which was beaten by the consequences of this issue) nor a crypto guy, I cannot really assess the severity of such a regression but my first thoughts were: - why is there no unit test cathing this? Because noone wrote one (obvious answer) Yes, of course that's the obvious answer. :) I asked because the answer could have been something along the lines of "because KRandom is old; do not use it; we have something new in frameworks" or so. From my "i know nothing about random numbers", i guess it's hard to write a unit test for a sequente of random numbers, you can get ten "3" in a row and it's still a valid random sequence. srand() is the same as srand(1) so it uses a fixed seed. Thus two initialisations produce the same sequence. Not sure though if this can be done in a unit test. - should KRandom api doc pass through the note of not using it for serious business in general? Probably makes sense adopting what rand() says, yes. Would you propose a patch? Already did: https://git.reviewboard.kde.org/r/127767/ Comments about the wording welcome. :) Regards, Frederik
Re: KRandom regression + fix
Am 27.04.2016 08:48 schrieb Johannes Huber: Hi Johannes, KRandom saw a regression in KCoreAddon's 5.21.0 release, which impacts a wide range of applications and use cases. Since the rand() was not seeded, the numbers generated were predictable, which is ugly in games and probably alarming for bluetooth pairing. thanks for the patch. When i read "randon numbers were predictable" instantly a alarm bell rings in my head. Is this a security issue? The docs of rand() state that you should not use it for serious business like cryptography http://en.cppreference.com/w/cpp/numeric/random/rand and the most serious business I could see within KDE was PIN generation for Bluetooth pairing. But you can never know who is using it for what outside of the KDE infrastructure. Since I am neither a core developer (just maintaining a game which was beaten by the consequences of this issue) nor a crypto guy, I cannot really assess the severity of such a regression but my first thoughts were: - why is there no unit test cathing this? - should KRandom api doc pass through the note of not using it for serious business in general? That's why I CC'ed kde-core-devel. Regards, Frederik
KRandom broken?
Hi, it seems as if KRandom is currently broken. https://bugs.kde.org/show_bug.cgi?id=362161 Given the potential impact, is there something to be done (besides fixing it) wrt distro packagers? Regards
Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/#review91464 --- Ping? - Frederik Schwarzer On Dec. 5, 2015, 8:38 a.m., Frederik Schwarzer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126249/ > --- > > (Updated Dec. 5, 2015, 8:38 a.m.) > > > Review request for kdelibs. > > > Repository: kio > > > Description > --- > > A full-stop within the first sentence (short description) breaks the line > there. See e.g. > http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c > > > Diffs > - > > src/core/storedtransferjob.h 3f267c9 > src/core/transferjob.h 6d78793 > > Diff: https://git.reviewboard.kde.org/r/126249/diff/ > > > Testing > --- > > > Thanks, > > Frederik Schwarzer > >
Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/ --- (Updated Jan. 23, 2016, 11:20 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs and David Faure. Repository: kio Description --- A full-stop within the first sentence (short description) breaks the line there. See e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c Diffs - src/core/storedtransferjob.h 3f267c9 src/core/transferjob.h 6d78793 Diff: https://git.reviewboard.kde.org/r/126249/diff/ Testing --- Thanks, Frederik Schwarzer
Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/ --- Review request for kdelibs. Repository: kio Description --- A full-stop within the first sentence (short description) breaks the line there. See e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c Diffs - src/core/storedtransferjob.h 3f267c9 src/core/transferjob.h 6d78793 Diff: https://git.reviewboard.kde.org/r/126249/diff/ Testing --- Thanks, Frederik Schwarzer
Review Request: Do not patch strings that can be combined.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104712/ --- Review request for KDE Base Apps. Description --- The way it is now, it created two strings, one of which does not hold anything to translate (just markup). This change merges them to one string with a placeholder which enables the translator to see the whole picture. Diffs - konqueror/settings/konqhtml/css/kcmcss.cpp b4e5146 Diff: http://git.reviewboard.kde.org/r/104712/diff/ Testing --- Thanks, Frederik Schwarzer
Re: Review Request: Display the tab title on root (/) folder properly in konqueror filemanager mode
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/#review3371 --- konqueror/src/konqview.cpp http://git.reviewboard.kde.org/r/101374/#comment2806 Wrong indentation. Its the paren of the outer if block. - Frederik On May 17, 2011, 9:18 p.m., Burkhard Lück wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/ --- (Updated May 17, 2011, 9:18 p.m.) Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- Konqueror in filemanager mode shows an empty tab title on browsing root (/) folder. Dolphin displays the tab title on root (/) folder properly, so this patch is a copy of three lines from dolphin dolphinmainwindow.cpp. This addresses bug 153573. http://bugs.kde.org/show_bug.cgi?id=153573 Diffs - konqueror/src/konqview.cpp 699c9d5 Diff: http://git.reviewboard.kde.org/r/101374/diff Testing --- compiled and works for me Thanks, Burkhard
Re: Review Request: Display the tab title on root (/) folder properly in konqueror filemanager mode
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/#review3375 --- WRT the parenthesis ... the outermost if statement breaks before the opening paren, the second if statement uses paren on the same line as the statement and the third uses no parens at all. Might that be worth unifying? - Frederik On May 17, 2011, 9:18 p.m., Burkhard Lück wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101374/ --- (Updated May 17, 2011, 9:18 p.m.) Review request for KDE Base Apps, David Faure and Peter Penz. Summary --- Konqueror in filemanager mode shows an empty tab title on browsing root (/) folder. Dolphin displays the tab title on root (/) folder properly, so this patch is a copy of three lines from dolphin dolphinmainwindow.cpp. This addresses bug 153573. http://bugs.kde.org/show_bug.cgi?id=153573 Diffs - konqueror/src/konqview.cpp 699c9d5 Diff: http://git.reviewboard.kde.org/r/101374/diff Testing --- compiled and works for me Thanks, Burkhard
Re: Top 15 Mailinglists with messages in moderation May 1st
[Tom Albers - Sonntag, 1. Mai 2011 16:00:57] Hi, New month, new list. If lists are unused, let me know, I will delete them. If someone wants to help with moderation for any of these list, let me know as well. 19 kde-news-de You can put me in change here. I will look into the moderation list ... but the list itself seems pretty dead so, let's see how it turns out. I will contact you, if I figured it out. Regards
Re: 4.6 branches created in git again
On 22/03/2011, Ian Monroe i...@monroe.nu wrote: On Mon, Mar 21, 2011 at 18:13, Alex Merry k...@randomguy3.me.uk wrote: On 21/03/11 20:17, Alexander Neundorf wrote: On Monday 21 March 2011, Ian Monroe wrote: Ben did add this block to his hook. Hooray. :) I'm thinking I should just go ahead and rename KDE/4.6 to 4.6 etc. Wasn't the conclusion more like going with the longer name, i.e. KDE/4.6 ? That's what I understood from the earlier discussion... I get why people like the prefix in theory, since I mean that's why I left it there. It looks nice. From what I understand the problem, it's not a like/dislike question but a real problem if an application has its own version numbers and reaches e.g. version 4.6. But in practice its obviously just been confusing. Even now that creating 4.6 is blocked, that just means its blocked and we won't notice when people struggle. Can the hook not give a message pointing to some Wiki page that explains the issue? Regards
Re: Top 15 Mailinglists with messages in moderation
On 01/03/2011, Harri Porten por...@froglogic.com wrote: On Tue, 1 Mar 2011, Raphael Kubo da Costa wrote: 34 kfm-devel I could help with this one. I do keep an eye on messages held back btw. As long as there's just spam I don't bother logging in to clean it up. Granted, this is slightly risky so any help is welcome. listadmin ftw :) http://blog.lydiapintscher.de/category/productivity/ Regards
