Notes for KDE Applications 17.04 release announcement
Please help collect the notable changes applications had for the KDE Applications 17.04 release in https://notes.kde.org/p/applications_17.04_new_features We need this filled in ASAP Cheers, Albert
Re: We need to enable auto close in github pull requests
El diumenge, 26 de març de 2017, a les 11:35:42 CEST, borissh1...@gmail.com va escriure: > On Monday, 13 March 2017 0:31:37 IDT Albert Astals Cid wrote: > > Looking at https://github.com/pulls?q=is%3Apr+org%3Akde+is%3Aopen makes me > > very sad seeing how there's people that want to contribute but will never > > get an answer. > > > > Even if you click to those 109 closed you can see how there are some that > > are from people that clearly got fed up from waiting. > > > > Please people that administer the github account (¿Riddell?) make that > > happen > > > > Cheers, > > > > Albert > > Sorry to barge in, but I believe it would be wise to consider to implement > an integration with github such as https://secure.phabricator.com/D8775. Please don't suggest solutions that do not exist, we need a solution yesterday, not in three years. Cheers, Albert
GSoC Proposal
Hello everyone! I'm Vasudha, a member of WikiToLearn. I'm interested in working on Project Ruqola. Here's the link to my proposal. Any feedback would be highly appreciated :) https://docs.google.com/document/d/1p5TMuk6wBE8LBFsylX3FesuB2Rvjma7huF3wJunytT0/edit?usp=sharing -- Vasudha
Re: kde on windows
On Monday, 27 March 2017 0:46:29 IDT Ralf Habacker wrote: > Am 31.07.2016 um 07:32 schrieb Doug: > > Gentlemen: > > > > I don't know what you think you've accomplished by limiting KDE on > > Windows to just 4 files. Sometimes it's necessary to use Windows, and > > it is (WAS!) nice to > > be able to use some KDE apps: Artha, KSnapshot, Dolphin, Find > > Files-Folders, Okular, Gwenview, KPatience. And Kate--the only file > > you left me that I use! > > And I don't want Amarok--that seems to be what you get if you're not > > careful! > > > > I have several computers, and several Windows installs, as well as > > PCLOS on all of them. I use PCLOS about 95% of the time, but when I > > need Windows, > > damn it! I need it! > > > > Please reconsider your dismal advice and let me have the apps that > > make Windows bearable! (32 and 64 bit, please!) > > > > Thanx--Doug McGarrett, KDE user for over 5 years > > > > PS: Please advise me if or when you bring back the apps! If you are on Win10 , I have had some partial success on win10 with some KDE apps under lxss. You can have some kde apps on windows , and I have managed to work with okular. You should be safe with anything under 14.04 LTS (default dist under lxss). As for neon under under lxss, It failed miserably. Maybe when neon could be loaded under lxss there would be an easier way to use KF5 apps on windows (without even kde-windows).
Re: Scrap Baloo Thread Feedback
Hello all, Sorry to exhume this old thread, but 2016-12-29 13:47 GMT+01:00 Dominik Haumann : > Hi all, > > CC: plasma-devel, due to stability issues > > On Fri, Oct 7, 2016 at 5:56 PM, Christoph Cullmann > wrote: >> Hi, >> > [...] >> Actually, the bugs.kde.org page tells you the facts: The bug number >> was constant increasing since > 1 year. The thread lists some other facts >> what is wrong ATM and should be fixed. > > Btw, the bug count is increasing again, just as before. So it seems > problems remain. > > [...] > >>> Right now, random requirements such as NFS and 32bit systems are >>> coming up. Are these really that important? > > Yes, it is, see below. > >>> I specifically designed >>> Baloo to not care about both network mounts and 32-bit systems. Yes, >>> Baloo has bugs and it won't handle more than 32bit-inodes. These >>> things, as all others, can be fixed. It's really a question of what is >>> important. Lets not target the outliers. Many of these decisions were >>> deliberately taken. >> That are no random requirements, sorry, you could call it random >> restrictions, too. >> That is not that productive, or? >> >> 1) 32-bit systems are still there and if that is a design decision to NOT >> support them, >> that is ok, but then bad for Plasma, no official support for 32-bit systems, >> baloo is IMHO >> the only framework with such requirements. And I see not that we have hinted >> any distro >> that they shall not compile it for 32-bit. >> >> 2) No NFS: Ok, fair game, but then, it should check that and disable itself >> completely if $HOME >> where the db is stored is a NFS, can live with that, too, but not with the >> current "we random >> crash" behavior. => That is a user experience we don't want, or? > > The reason why I am writing this mail is exactly this point: > > At the university where I was previously working, $HOME is mounted via > NFS. After an upgrade from KDE4 to Plasma 5.8, the desktop crashes > very often. And the very reason is baloo. > > The problem, however, is that even the sysadmins do not know that > baloo is the reason for all the crashes. In other words: Hundreds of > users probably get the impression of an unstable Plasma 5.8 - or even > worse - it boils down to "KDE sucks" or "I don't have these issues > with Ubuntu". > > This is a perfect example of extremely negative impact - the Plasma > devs can work as hard as they want, the desktop in this context will > *never* be stable unless baloo is deactivated. > > That said: Baloo needs to disable itself for everything that touches > NFS, or maybe even disable itself after it crashes several times. > > There were many more issues listed and discussed, but as far as I can > see, we did not make real advances besides some prototype based on > tracker (just a test), and some minor fixes in baloo that do not > address the hard problems. > > Sorry that this reads like a rant. This is not the intention. Instead, > the goal is to underline the still severe issues in order to get > closer to a stable desktop for our users. > > Greetings > Dominik > > > >> 3) > 32-bit inodes: That is normal and should work, but even if it should >> not: Atm you get inconsistent >> and then later assertion fails or crashs. >> >> => I can live with all restrictions but the current handling of them, that >> always ends in "crash" is >> IMHO not that acceptable. But that is "my" opinion, that might vary in the >> eyes of others. >> >>> >>> How about requirements such as resource consumption, ease of >>> integration, search speed are taken into consideration? Come on guys. >>> We're engineers over here. >> What is the argument here? If you take a look at bugs.kde.org, you see that >> people are complaining about all >> of that with baloo. I see no evidence nowhere that e.g. baloo is "superior" >> to what GNOME uses >> or any other solution (perhaps beside nepomuk, ok...). >> >> I fixed in a few days more bugs than were fixed in 1 year and triaged more >> than ever, still a lot is to be done. >> (and I did really not do a lot, just remove things like 'self destruct if >> index > 5GB' or 'crash for ever on >> db corruption') >> >> A graph tells more than words: >> >> https://bugs.kde.org/reports.cgi?product=frameworks-baloo&output=show_chart&datasets=CONFIRMED&datasets=ASSIGNED&datasets=REOPENED&datasets=UNCONFIRMED&datasets=RESOLVED&banner=1 >> >> Given the current open bugs, one will need to: >> >> 1) review all extractors, they have still close to zero error handling and >> will just crash or OOM you on bad files >> 2) review + fix the complete data base handling to handle errors and perhaps >> swap the DB >> 3) fix the indexer to have some resource limits to avoid OOM and Co. if e..g >> extractors fail >> ... >> >> Therefore there was my proposal, given we lack manpower, to implement baloo >> API on top of e.g. tracker to avoid all this >> and let tracker handle that. >> >> To check if that is at all feasible, I did some quick an
Re: How am i supposed to use arc? - was - Re: Phabricator: All repositories registered - upcoming workflow changes
On Mon, Mar 27, 2017 at 9:34 AM, Albert Astals Cid wrote: > El diumenge, 26 de març de 2017, a les 20:26:25 CEST, A. Bikadorov va > escriure: >> On 26.03.2017 20:17, Albert Astals Cid wrote: >> > El diumenge, 26 de mar� de 2017, a les 18:41:00 CEST, A. Bikadorov va >> > >> > escriure: >> >> On 26.03.2017 18:36, Boudhayan Gupta wrote: >> >>> Write it in a wiki page? >> >>> >> >>> Freundliche Gr��e >> >>> Boudhayan Gupta >> >>> KDE e.V. - Sysadmin and Community Working Groups >> >>> +49 151 71032970 >> >>> >> >>> On 26 March 2017 at 18:33, Albert Astals Cid wrote: >> El diumenge, 29 de gener de 2017, a les 8:32:21 CEST, Ben Cooksley va >> >> escriure: >> > Hi everyone, >> > >> > We've just completed the registration of all mainline repositories >> > (not including Websites or Sysadmin namespaced ones) on Phabricator. >> > Thanks go to Luigi Toscano for providing significant assistance with >> > this process. >> > >> > From this point forward, communities should be moving away from >> > Reviewboard to Phabricator for conducting code review. Sysadmin will >> > be announcing a timeline for the shutdown of Reviewboard in the near >> > future. >> > >> > Projects which haven't yet looked into Phabricator, including getting >> > things like mailing list notifications and projects setup should do so >> > as soon as practical. >> > >> > As part of the registration process, Sysadmin tagged repositories, >> > associating them to Projects. These tags show what a repository is >> > associated with and it's status. >> > >> > This includes things like whether development is currently active (the >> > Historical Archival and Up For Adoption tags), which release unit it >> > is part of (KDE Applications, Frameworks, etc) and the general >> > development effort it is associated with. >> > >> > It would be appreciated if everyone could please check their >> > repositories to ensure they've been tagged correctly. Adjustments can >> > either be sent as replies to this email (include sysadmin@ in CC >> > please) or by asking a member of the Community Admins project on >> > Phabricator to make the change for you. >> >> I tried using arc today, after reading some documentation it seems i >> need >> to use >> >> arc diff >> >> to upload a patch, but then i got hit by >> >> >> $ arc diff >> Usage Exception: This command requires arc to connect to a Phabricator >> install, but no >> >> Phabricator installation is configured. To configure a Phabricator URI: >> - set a default location with `arc set-config default `; or >> - specify `--conduit-uri=uri` explicitly; or >> - run `arc` in a working copy with an '.arcconfig'. >> >> And i couldn't find more documentation on how to move forward. >> Ultimately >> I >> asked Aleix that told me "copy the .arcconfig file from >> plasma-desktop". >> >> Since newbies usually don't have Aleix at hand, how do we fix this? >> >> Cheers, >> >> Albert >> > >> > Thanks, >> > Ben Cooksley >> > KDE Sysadmin >> >> >> >> Which is already done? >> >> -> https://community.kde.org/Infrastructure/Phabricator#Connecting_to_KDE >> > >> > No, sorry, that doesn't work, it links to the calligra .arcconfig, which >> > has "project.name": "Calligra" >> > What would I write there? >> > >> > Cheers, >> > >> > Albert >> >> >> >> Cheers >> >> Alex >> >> The name of the project for this repo. Sorry, but isn't that pretty obvious? > > No, it is not, let's say that > https://phabricator.kde.org/source/plasma-framework/ > did not have an .arcconfig file > > Should i use plasma.framework? > Should i use "Plasma Framework"? > Should I use "Plasma Framework (Library)"? > And most importantly, what does that project.name do? You should not need to set project.name in .arcconfig. When Arcanist creates a revision (review) it should associate it with the appropriate repository on Phabricator. That in turn will trigger Herald to add any necessary projects and other subscribers - resulting in mails going out to mailing lists, project maintainers and so forth. Creation of Herald rules is restricted to Community Admins as global rules have the power to bypass all access controls and can be used to perform significant actions (bulk subscribing others, etc) Please see https://phabricator.kde.org/H19 for the rule for Plasma. > > Because if you actually look at the plasma-framework .arcconfig you'll see it > doesn't have a project.name > > I sincerely think that Luigi's suggestion is what should be in > https://community.kde.org/Infrastructure/Phabricator#Connecting_to_KDE > or at least as an alternative way. > > Cheers, > Albert Cheers, Ben > >> The wiki says its a template and if you are unsure, y
Re: Will code for mentorship (I need a mentor for GSoC)
On Saturday 25 March 2017 21:30:54 Paulo Lieuthier wrote: > Hello KDE devs, > > I am a brazillian student of CS, interested in working on Kopete in GSoC. I > was also interested last year, sent a few patches [1] and wrote two nice > proposals [2][3]. Problem being there was no mentor available for me and my > proposals were rejected. The ideas for which I proposed are listed again > this year, and I will be proposing for them again. > > I am very familiar to C++ and Qt, having sent other small patches to > KWindowSystem [1] and worked on LXQt for more than a year as a core > developer [4]. That is to say I probably don't need a full-time mentor, but > someone to ask for some help, if needed be. > > Please, be my mentor or point me to someone. :) > > Best, > Paulo Lieuthier > > [1] https://git.reviewboard.kde.org/users/paulolieuthier/ > [2] > https://docs.google.com/document/d/10l5kIePsN69Amvk9I1WYLsU3nuReVZzvtp1fyVIV22E/edit?usp=sharing > [3] > https://docs.google.com/document/d/1xbVpStkpaqqY_xAaaz8tikl8burhIGEo9ffoAjLcHko/edit?usp=sharing > [4] > https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+user%3Alxde+author%3Apaulolieuthier+ Hi Paulo! If you are interested in working on Kopete as GSoC project, then you should first choose and ideally describe in which project you are interested. This could help other people decide if to mentor your project... -- Pali Rohár pali.ro...@gmail.com
Re: We need to enable auto close in github pull requests
On Monday, 13 March 2017 0:31:37 IDT Albert Astals Cid wrote: > Looking at https://github.com/pulls?q=is%3Apr+org%3Akde+is%3Aopen makes me > very sad seeing how there's people that want to contribute but will never > get an answer. > > Even if you click to those 109 closed you can see how there are some that > are from people that clearly got fed up from waiting. > > Please people that administer the github account (¿Riddell?) make that > happen > > Cheers, > Albert Sorry to barge in, but I believe it would be wise to consider to implement an integration with github such as https://secure.phabricator.com/D8775.
