API Breakage?: Re: [kcmutils] src: Fix typo in headers generation
On Tuesday 9 December 2014 16:16:23 Martin Klapetek wrote: Git commit 0256b80e9ac7c1459afe0ac021d27e985cba14d3 by Martin Klapetek. Committed on 09/12/2014 at 16:16. Pushed by mklapetek into branch 'master'. Fix typo in headers generation Also install to properly capitalized subdirectory And it seems that we have our first breakage in Frameworks. Programs that compile against Frameworks 5.5, will no longer compile against Frameworks 5.6 and vice versa. The change of the directoryname causes issues as that for 5.5 you need to have the ksettings/includefile.h, but this will fail on 5.6 as that one would require KSettings/includefile.h. I was hoping that the camelcase headers could help out here, but they are installed in the same directoy. Regards Raymond
Re: API Breakage?: Re: [kcmutils] src: Fix typo in headers generation
On Wed, Dec 10, 2014 at 9:56 AM, Raymond Wooninck tittiatc...@gmail.com wrote: On Tuesday 9 December 2014 16:16:23 Martin Klapetek wrote: Git commit 0256b80e9ac7c1459afe0ac021d27e985cba14d3 by Martin Klapetek. Committed on 09/12/2014 at 16:16. Pushed by mklapetek into branch 'master'. Fix typo in headers generation Also install to properly capitalized subdirectory And it seems that we have our first breakage in Frameworks. Programs that compile against Frameworks 5.5, will no longer compile against Frameworks 5.6 and vice versa. The change of the directoryname causes issues as that for 5.5 you need to have the ksettings/includefile.h, but this will fail on 5.6 as that one would require KSettings/includefile.h. I was hoping that the camelcase headers could help out here, but they are installed in the same directoy. Ah hmm...I did this because at some other places there are KSettings/includefile.h and the build was failing. I guess I'll just revert the directory capitalization then, but leave the typo fix itself. Cheers -- Martin Klapetek | KDE Developer
Re: New framework to review: KPackage
On Wednesday 10 December 2014, Albert Astals Cid wrote:
I would like to submit it (kpackage repo) for the usual 2 weeks period of
review.
Add const
void setDefaultMimeTypes(QStringList mimeTypes);
void setMimeTypes(const char *key, QStringList mimeTypes);
You probably want a Q_DISABLE_COPY or similar in PackageLoader
done
Add const
foreach (QString prefix, d-contentsPrefixPaths) {
done
All those char * params make me a bit unhappy, any reason those are not
QString or QByteArray?
made them QByteArrays
--
Marco Martin
Re: Review Request for KDecoration
On Wednesday 10 December 2014 08:07:25 Martin Gräßlin wrote: My personal opinion is that it doesn't need the tooltips. If one cannot recognize the buttons than the design language of the decoration is really bad. Every interactive on-screen element must have a text, either as a label, or as a tooltip. This is a simple accessibility requirement. Christoph Feck (kdepepo)
Re: [Kde-pim] Problems with infrastructure
[I love our infrastructure, just this bit triggered my reply-to-email reflex] On Wednesday, December 10, 2014 10:28:59 Christian Mollekopf wrote: * deleting branches: This is the only major gripe I have with the kde infrastructure. I think everyone should be able to delete branches (except some blacklisted ones). If I cannot delete my branches when I no longer need them I try to avoid pushing them, which doesn't help. Personal clones are not a solution IMO because you have to manage additional remotes. IMO the benefits outweigh the danger of someone accidentally deleting someone else's branch. Perhaps a naming scheme could be established for such branches, such as: dev/$foo or feature/$foo In Plasma, we usually name branches username/topic, so for example sebas/breakpluginloader. It'd be supersweet if the user who owns this branch would be able to delete it. I often leave these branches lingering for too long before I ask notmart to delete them, so that would be a useful addition. I quite like not being able to delete arbitrary branches. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: New framework to review: KPackage
The binary is called kpackagetool. Given the complications we've had with frameworks co-installability does it make sense to call it kpackagetool5? The class name in kpackagetool/kpackagetool.cpp should probably be renamed Documentation at the top of PackageLoader should avoid saying Plasma quite so much commented line at 773 of package.cpp looks concerning. I think it is just dead code. Installation command of plasmoids.knsrc are wrong (in fact they're wrong for current plasmapkg) Should kpackage even be providing this file? I think it should be with the plasmoid definition. IMHO PackageJob probably shouldn't set a parent to the packagestructure. Otherwise if you create a PackageStructure on the stack then call install/uninstall it will delete the job before it's finished. There's a Qt5 TODO on PackageJobThread::removeFolder
Re: Review Request for KDecoration
On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph Feck wrote: Every interactive on-screen element must have a text, either as a label, or as a tooltip. This is a simple accessibility requirement. Does this imply a formal representation (eg. to be accessed as object property from some screen reader etc.) or just please provide some text somewhere, at least optionally? Basically the KWin core can not really control what the client does (as usage of DecorationButton is not mandatory) and one could eg. replace the titlebar label w/ the action description rather than adding a tooltip. Cheers, Thomas
Re: [Kde-pim] Problems with infrastructure
On Wednesday, 10 December 2014 10:28:59 CEST, Christian Mollekopf wrote: * pull requests/the webinterface: reviewboard is awesome for single patches every now and then, it's rather useless when you work with branches IMO. With github we have a nice webinterface to review branches while keeping it simple. Gerrit may be what I'm looking for though (never used it, looking forward to see how the testing goes). That depends on what you're looking for. Gerrit puts emphasis on review of individual patches. It will present related patches together, but you won't be able to review them as a single entity -- the goal of Gerrit is to ensure that the history is clean, and it is operating under an assumption that each commit matters. Unless I'm mistaken, a GitHub pull request shows you a diff which represents the starting point and the final point of that branch as a single unit, with an option to go into individual commits. Gerrit is different -- not worse, different :). Regarding the testing of Gerrit, I haven't received much feedback yet. Three repositories are using it so far (kio, plasma-framework, trojita), and if a repo owner/maintainer of some other project is willing to take part in this testing, I won't see a problem with it. With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [Kde-pim] Problems with infrastructure
El Dimecres, 10 de desembre de 2014, a les 16:53:09, Jan Kundrát va escriure: On Wednesday, 10 December 2014 10:28:59 CEST, Christian Mollekopf wrote: * pull requests/the webinterface: reviewboard is awesome for single patches every now and then, it's rather useless when you work with branches IMO. With github we have a nice webinterface to review branches while keeping it simple. Gerrit may be what I'm looking for though (never used it, looking forward to see how the testing goes). That depends on what you're looking for. Gerrit puts emphasis on review of individual patches. It will present related patches together, but you won't be able to review them as a single entity -- the goal of Gerrit is to ensure that the history is clean, and it is operating under an assumption that each commit matters. Unless I'm mistaken, a GitHub pull request shows you a diff which represents the starting point and the final point of that branch as a single unit, with an option to go into individual commits. Gerrit is different -- not worse, different :). Regarding the testing of Gerrit, I haven't received much feedback yet. Three repositories are using it so far (kio, plasma-framework, trojita), and if a repo owner/maintainer of some other project is willing to take part in this testing, I won't see a problem with it. I see some problems with gerrit: A) it makes our messaging more complex, we tell people to use reviewboard, except for these 3 repos, which you have to use a different tool B) As a gardener it makes my life harder, now I have to go through two different patch tracking systems and see if people forgot to commit or review stuff in two different systems. C) In case I was a developer of some of those projects it would it harder for me to also check what's the status of my patches since i would need to visit two webs instead of one. D) There's no way to create a review without using relatively unfriendly gerrit process A, B, and C are solved if gerrit is only in testing to eventually replace reviewboard totally; but not if it is meant to coexist with reviewboard (which would make some people happier but would in my opinion be negative for the common good). D is really important to me since it makes it harder to contribute to non hardcore git users; it took me days to start understanding Qt's gerrit and i am still not sure i understand it fully, with reviewboard i do git diff and use the web to upload a patch, as simple as it gets. And yes, i know people complain about reviewboard, but that is because it's the tool we use, if we used gerrit, we would probably get complains too. I want to make sure we're not investing time in what at the end is most probably a zero sum height. Cheers, Albert With kind regards, Jan
Re: [Kde-pim] Problems with infrastructure
Albert Astals Cid ha scritto: I see some problems with gerrit: [...] D) There's no way to create a review without using relatively unfriendly gerrit process [...] D is really important to me since it makes it harder to contribute to non hardcore git users; it took me days to start understanding Qt's gerrit and i am still not sure i understand it fully, with reviewboard i do git diff and use the web to upload a patch, as simple as it gets. git-review should solve (or ease) most of the issues there (send and update the reviews). See other projects using it: https://wiki.openstack.org/wiki/Gerrit_Workflow http://www.mediawiki.org/wiki/Gerrit/git-review In order to check the existing reviews, there are other tools with various degree of completeness like: * https://github.com/berrange/gerrymander * https://github.com/stackforge/gertty (yep, many coming from the OpenStack project :) Ciao -- Luigi
Re: Review Request for KDecoration
El Dimecres, 10 de desembre de 2014, a les 15:44:02, Thomas Lübking va escriure: On Mittwoch, 10. Dezember 2014 13:11:07 CEST, Christoph Feck wrote: Every interactive on-screen element must have a text, either as a label, or as a tooltip. This is a simple accessibility requirement. Does this imply a formal representation (eg. to be accessed as object property from some screen reader etc.) or just please provide some text somewhere, at least optionally? I'll go for both. Basically the KWin core can not really control what the client does (as usage of DecorationButton is not mandatory) and one could eg. replace the titlebar label w/ the action description rather than adding a tooltip. Sure, you can't control the client, but if you provide a nice class and the example uses it, everybody will copypaste from it and we'll be all happy :) Cheers, Albert Cheers, Thomas
Re: API Breakage?: Re: [kcmutils] src: Fix typo in headers generation
El Dimecres, 10 de desembre de 2014, a les 10:17:23, Martin Klapetek va escriure: On Wed, Dec 10, 2014 at 9:56 AM, Raymond Wooninck tittiatc...@gmail.com wrote: On Tuesday 9 December 2014 16:16:23 Martin Klapetek wrote: Git commit 0256b80e9ac7c1459afe0ac021d27e985cba14d3 by Martin Klapetek. Committed on 09/12/2014 at 16:16. Pushed by mklapetek into branch 'master'. Fix typo in headers generation Also install to properly capitalized subdirectory And it seems that we have our first breakage in Frameworks. Programs that compile against Frameworks 5.5, will no longer compile against Frameworks 5.6 and vice versa. The change of the directoryname causes issues as that for 5.5 you need to have the ksettings/includefile.h, but this will fail on 5.6 as that one would require KSettings/includefile.h. I was hoping that the camelcase headers could help out here, but they are installed in the same directoy. Ah hmm...I did this because at some other places there are KSettings/includefile.h and the build was failing. I guess I'll just revert the directory capitalization then, but leave the typo fix itself. Can we get both the correct and the old way and mark it as deprecated? the correct way is cool since it helps us by having the same way of using stuff on all frameworks, predictibility is awesome. the old way gives us the compatibility we promise. Now, i've no clue what i'm talking about so excuse me if i'm suggesting something stupid :D Cheers, Albert Cheers
Re: API Breakage?: Re: [kcmutils] src: Fix typo in headers generation
On Thu, Dec 11, 2014 at 12:09 AM, Albert Astals Cid aa...@kde.org wrote: Can we get both the correct and the old way and mark it as deprecated? the correct way is cool since it helps us by having the same way of using stuff on all frameworks, predictibility is awesome. And it eases up porting from kdelibs4support but not having to change all the includes. the old way gives us the compatibility we promise. Now, i've no clue what i'm talking about so excuse me if i'm suggesting something stupid :D I was acutally thinking about the same, would mean the headers are duplicated though. Additionally the old headers could have some #pragma message so it tells people while building. The argument against was that whatever would use the correct wouldn't build against older frameworks...which in the cases I know about wouldn't be a problem because they depend on master anyway, so bumping the min version in their find_package(..) wouldn't be a problem. Cheers -- Martin Klapetek | KDE Developer
Re: [Kde-pim] Problems with infrastructure
On Wednesday, 10 December 2014 19:41:31 CEST, Albert Astals Cid wrote: D is really important to me since it makes it harder to contribute to non hardcore git users; it took me days to start understanding Qt's gerrit and i am still not sure i understand it fully, with reviewboard i do git diff and use the web to upload a patch, as simple as it gets. Please take your time to try out KDE's Gerrit and don't judge it based on your experience with Qt's Gerrit (in fact, try to forget that one if possible). There's been more than two years of development which went into the version which we use, and this effort is IMHO quite visible. As a random data point, I've had two newcomers (one of them a GCI student) submitting their first patch ever through Gerrit within 15 minutes after I asked them to use Gerrit, with no prior experience whatsoever. I'm pretty sure that the GCI students in general aren't considered an etalon of quality. Also, uploading a patch with Gerrit is a matter of `git push gerrit HEAD:refs/for/master`. Are you suggesting that this is harder than `git format-patch origin/master` and uploading the resulting file manually? And yes, i know people complain about reviewboard, but that is because it's the tool we use, if we used gerrit, we would probably get complains too. I want to make sure we're not investing time in what at the end is most probably a zero sum height. Right, I believe that one. As a project maintainer though, I can say that Gerrit does make my life much easier -- being able to tests patch series myself by a single `git pull` is *so* different to the experience of fetching patches by hand from RB (and undoing the occasional breakage). Also, there's no early CI feedback with RB, and nobody is neither working on this, not had announced any plans to work on this topic during the past years. That alone would change the ballance for me. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [Kde-pim] Problems with infrastructure
El Dijous, 11 de desembre de 2014, a les 00:41:56, Jan Kundrát va escriure: On Wednesday, 10 December 2014 19:41:31 CEST, Albert Astals Cid wrote: D is really important to me since it makes it harder to contribute to non hardcore git users; it took me days to start understanding Qt's gerrit and i am still not sure i understand it fully, with reviewboard i do git diff and use the web to upload a patch, as simple as it gets. Please take your time to try out KDE's Gerrit and don't judge it based on your experience with Qt's Gerrit (in fact, try to forget that one if possible). There's been more than two years of development which went into the version which we use, and this effort is IMHO quite visible. As a random data point, I've had two newcomers (one of them a GCI student) submitting their first patch ever through Gerrit within 15 minutes after I asked them to use Gerrit, with no prior experience whatsoever. I'm pretty sure that the GCI students in general aren't considered an etalon of quality. Also, uploading a patch with Gerrit is a matter of `git push gerrit HEAD:refs/for/master`. Are you suggesting that this is harder than `git format-patch origin/master` and uploading the resulting file manually? Yes, it is harder. Yyou need to setup git correctly, so that gerrit in that command is valid, you need to understand you're pushing to a different server than the real one, you need to commit (i never do format-patch, just git diff), all in all needs you go have a bigger git-understanding. Besides in reviewboard i could get a tarball, produce a diff and upload it easily, i have not investigated Luigi's links yet, but as far as i know that is not easy/doable in gerrit. Cheers, Albert And yes, i know people complain about reviewboard, but that is because it's the tool we use, if we used gerrit, we would probably get complains too. I want to make sure we're not investing time in what at the end is most probably a zero sum height. Right, I believe that one. As a project maintainer though, I can say that Gerrit does make my life much easier -- being able to tests patch series myself by a single `git pull` is *so* different to the experience of fetching patches by hand from RB (and undoing the occasional breakage). Also, there's no early CI feedback with RB, and nobody is neither working on this, not had announced any plans to work on this topic during the past years. That alone would change the ballance for me. Cheers, Jan
Re: [Kde-pim] Problems with infrastructure
On Thursday, 11 December 2014 00:51:28 CEST, Albert Astals Cid wrote: Yes, it is harder. Yyou need to setup git correctly, so that gerrit in that command is valid, you need to understand you're pushing to a different server than the real one, you need to commit (i never do format-patch, just git diff), all in all needs you go have a bigger git-understanding. I see what you're saying, and you're probably right -- there's a bar, indeed. That bar could however be effectively removed by having a spoonfeeding, step-by-step documentation on how to submit patches with Gerrit. I'm still hoping that I'm not the only guy who cares about this, and that maybe someone else is going to produce such a howto (hint for bystanders: now is the time, I've put quite a few hours into this already). Furthermore, there are upstream patches under review for making it possible to create a review through the web, with no use of CLI tools or a `git push` equivalent of any sort. When these are released, I'll be happy to upgrade, as usual. Besides in reviewboard i could get a tarball, produce a diff and upload it easily, i have not investigated Luigi's links yet, but as far as i know that is not easy/doable in gerrit. Do we have some stats saying how many people download tarballs / zips from ReviewBoard? Is there a User-Agent breakdown for the patch submission to RB so that we could look on how many people do push files around, and can we compare that to the number of people using rb-tools? I'll be happy to do the number crunching myself, but I don't have access to the logs. Anyway, I understand that my experience is probably going to differ from the experience of anybody else to some extent, but to me, the hardest thing in making a patch is usually finding out what changes to make in a random C++ file of a project whose sources I'm seeing for the first time. Compared to *that*, creating a git diff has always been much easier for me. Moreover, when that patch is ready, someone still need to commit it and make sure that it doesn't introduce any regressions. Right now, all parts of this duty are effectively up to the project maintainer, which means that the process doesn't scale at all. Unless the patch author is a KDE developer already (in which case I fully expect them to be able to copy-paste three commands from a manual to be able to push to Gerrit), a project maintainer has to fetch stuff from RB by hand, copy-paste a commit message, perform a build cycle, verify that stuff still works and upload the result to git. Considering a typical turnover time of patches which I see within KDE, I don't think that we have superfluous reviewers or project maintainers, so my suggestion is to prioritize making their workflow easier at the expense of, well, forcing the contributors to spend their time copy-pasting a couple of commands from a manual *once* during the course of their involvement with a given project. Anyway, I know that pre-Gerrit proccess was so painful for me that I actually decided to invest dozens of hours of my time into this, and get the Gerrit + CI ball rolling, and I'm not really willing to go back into shuffling bits around by hand. This is 2014, and we have computers to do repeated bits for us, don't we? I've had my fair share of beers tonight, so I hope I won't manage to offend people by my blutness here. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Facebook Flint vis-à-vis Krazy
Il 02/12/2014 21:40, Allen Winter ha scritto: Howdy, Today I was informed that Facebook has a tool similar in concept to Krazy, called Flint [1] You might want to read [1] and let me know if there are any checkers listed there that you'd like to see added to Krazy. Krazy already does many of the Flint checks, but I'm interested in new ideas. [1] https://code.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourcing-flint/ vis-à-vis in relation to; with regard to as compared with; as opposed to. Dunno if it's already done, but checking the ABI mutations between releases would be interesting: alas http://ispras.linuxbase.org/index.php/ABI_compliance_checker (I'm doing this with Gentoo but yet have to add a check when upgrading packages) regards, Francesco Riosa
Re: API Breakage?: Re: [kcmutils] src: Fix typo in headers generation
Martin Klapetek wrote: I was acutally thinking about the same, would mean the headers are duplicated though. Additionally the old headers could have some #pragma message so it tells people while building. And you also have to check whether the file system you're installing to is case-sensitive to begin with, and only install the compatibility headers on case-sensitive file systems. Kevin Kofler
Re: New framework to review: KPackage
Marco Martin wrote: In the past weeks I have been working on a new framework, called KPackage. You ARE aware that KPackage was the name of an old frontend for RPM and other package managers that used to be part of the KDE Software Compilation 4? Kevin Kofler
Re: [Kde-pim] Problems with infrastructure
On Wednesday, December 10, 2014 15.27:31 Ben Cooksley wrote: It has come to my attention that some developers have issues with KDE infrastructure in certain areas. This is the first time i've heard I suspect the issues are the same ones that led us to experiment with gitlab a while back. Christian's response seems to back that up. A modern, consistent, unified, user-friendly interface to the source lifecycle of a project is pretty desirable. Github and the like have really set people's expectations there pretty high. Having a bunch of separate tools with somewhat-to-less-clunky interfaces, each with their own individual learning curves is just not very attractive when Github sits there shiny and usable. It's also what more and more new developers get to know through their first experiences. Whether gerrit is a useful too or not, another separate tool won't bring the desired changes. It's an attempt to answer a rather different question, actually. I don't know if it matters to KDE or not, but if appealing to new generations of developers and keeping existing ones as happy as possible is a goal[1], then it would make a lot of sense to orchestrate a move to something that provides such a github-like experience, even if it has other drawbacks. Those drawbacks probably don't matter as much. If they did, github wouldn't be thriving quite as much as it does. [1] thinking that it would be nice or that would be a good idea does not make it a goal -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
