Re: Changes to our Git infrastructure
On Sunday, 4 January 2015 19:32:28 CEST, Jeff Mitchell wrote: I don't follow this line of logic. The end result is software stored in git trees, but how it gets there is a totally different concern. Whether it comes from patches that are then accepted and merged, or direct merging of branches, the end result is the same. - Existing KDE account holders can and do use git for their workflow. - Using non-git workflow for others introduces a different workflow to the mix. - Having two workflows is more complex than having just a single one. Does it make it more understandable? My goal is to help bridge the gap between the existing project maintainers (who produce software in git trees) and the new contributors (who produce patches). KDE purposefully has a very low barrier to entry. A contributor can normally push anywhere. When I said a contributor, I was referring to somebody who is not a KDE developer yet. Please re-read what I wrote again because your understanding assumed that a contributor is someone who can push to git. I can see why you arrived at what you said in that case, but that's not what I said. .NET is a framework, not a language. Maybe you meant C#. ... Thanks for educating me, but I don't think it helps move this discussion forward in a productive manner. I do. Because there are a huge number of languages that have compilers to produce .NET CLI. Some of them are indeed relatively obscure. Saying .NET doesn't mean anything in terms of which languages you are taking issue with. Let's be clear what we're talking about. I was quite obviously referring to any tools which make use of the .NET runtime environment. I do think that mandating these for efficient work with our code review system is a pretty big no-go. As other people have added to the list of requirements, patch management needs to be able to be done via the web UI. Nobody has to install any runtime environment. The requirement I listed was make the changes available as git refs so that I do not use any other tool to work with them. If that is not available, then another requirement is have a nice CLI implemented in a language that is common on KDE desktop. The fact that I can fetch and upload patches via a website does not satisfy this requirement. It's a bandaid help, not a fully usable solution. Those that want to contribute will be required to install a whole slew of development packages. Unless they have e.g. done something with Qt already, or unless they're C++ developers already, etc. Especially if it's only needed if they want to do advanced CLI stuff. Fetching patches is not advanced stuff. It's cool to have a manual bypass for fetching stuff by hand, but that is a hotfix, not a productive solution. The sysadmins appear to have a strong preference for a unified tool to do both. No, our preference is for well-integrated tools, which is the same preference you previously stated. I'm happy to hear this, but then I don't know how to interpret Ben's earlier responses in this thread and our conversations on IRC. Anyway, it's cool that we agree on something :). To put my money where my mouth is, yes, I am willing to maintain the extra systems, and I have been doing this with Gerrit (and CI) for a couple of months already. Yes, because Gerrit is not a tool being provided by the sysadmin team and as such is not in scope for us to maintain. It's great that you're willing to help out, but your offer to help maintain Gerrit has no bearing on whether or not it's what we end up proposing to the community. I'm simply stating that any possible argument saying we prefer a single tool because we don't have manpower to maintain more of them is moot because that manpower is waving its hand and saying I'm gonna do this right now. With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to our Git infrastructure
On Sunday, 4 January 2015 13:21:12 CEST, Thomas Friedrichsmeier wrote: True, but don't forget about the other side of the story: - potential contributors will have to learn more stuff, before they can even _start_ contributing, which may be a real turn-off in some cases. That's a valid concern, so the core question is whether this scenario: - make changes - make a commit - push that commit is any more complex than: - make changes - create a diff - upload that diff via a browser. I have to admit I have no idea which one is *really* easier for a total newbie, and which one is easier for an average contributor. Your project's situation may be very different from mine. Personally, I'm much more worried about keeping the entry barrier as low as possible, than about reducing the amount of effort that I have to put into supporting and educating contributors. That's also a possibility. However, in my experience with Gerrit, GCI students (which are kids aged 12-18, IIRC) were able to upload patches without substantial problems. That's despite our rudimentary state of KDE-specific documentation, and Gerrit having a oh no, let's run away from that beast reputation. In short, I think that there's actually a solution which can be both a low enough barier to entry *and* help maintainers do their job easier. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to our Git infrastructure
On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát j...@kde.org wrote: On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote: Ease of installation and it's the availability of the necessary interpreters within mainstream distributions should be more than sufficient criteria here. Limiting it by any other criteria is playing pure favouritism to a given set of language(s) and unnecessarily limits our options. Ben, you and Jeff appear to disagree with my point that e.g. requiring a PHP tool to be installed client-side on each developers' and contributors' machine might be a little bit discouraging. It is OK to say that you disagree, but it doesn't prove the point to be any less valid. It's fine to have people assign varying importance to different evaluation criteria, so please do not use your sysadmin hat to unilaterally remove this pure favoritism just because you do not see any value in it. My impression was that we're gathering a list of possible requirements and *then* we, as a community, are going to assign some importance factor to each and every item raised. It is therefore acceptable to have mutually exclusive criteria at this point, or even bits which some of us might find to be totally irrelevant. They are going to be sorted out be community's consensus, I suppose. The list of requirements is first gathered from the community. We then summarize it with items being weighted based on the level of support mentioned by various people and send it back. If everyone is broadly happy we then go ahead and prepare solutions which meet this list of requirements. There is no community level sorting of the items because items don't have a priority - it is a best effort basis to meet all of the requested features and functions. These proposals are accompanied by the pros and cons each faces, along with a recommendation for the one we believe best fits the needs of the community. You can see an example of this in the initial git.kde.org setup which Sysadmin did many years ago (2010 I think). With kind regards, Jan Cheers, Ben -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: libkgeomap
On Sun, Jan 4, 2015 at 8:21 PM, Michael G. Hansen m...@mghansen.de wrote: We also had a Google Summer of Code student work on the library, and the project was not rejected by Google. I would actually be surprised if it was. GSoC is run by the Google Open Source Office and this program particularly is done by about 3 people; I don't believe they are actually reviewing all the applications, that's up to the mentoring orgs (KDE). Then Google has tens of thousands employees, I also don't believe everyone of them knows terms to 3rd party usage of some of their products. Just sayin... :) Cheers -- Martin Klapetek | KDE Developer
Re: libkgeomap
Hi, Happy New Year to all in this room. Thanks Micheal for all details about libkgeomap history, especially GoogleMaps rules. Just few words about libkgeomap KF5 port : - Library is fully ported as QT5/KF5 and sound work fine. - Alin Marin Elen alinm.el...@gmail.com currently work on KGeoMap::HTMLWidget class to port from KHTML to Qt5::Webkit. All details are listed in this wiki page section : https://techbase.kde.org/Projects/Digikam/CodingSprint2014#Libkgeomap Michael, if you have some free time to review code later, it will be great. Thanks in advance. Best Gilles Caulier 2015-01-04 20:21 GMT+01:00 Michael G. Hansen m...@mghansen.de: On 03.01.2015 15:09, Tobias Leupold wrote: IMHO, the real question is, shouldn't that pointless wrapper be deprecated in favor of just using Marble directly? Can marble be used in an identical way as libkgeomap, as a QWidget only displaying a map with not only coordinates but also photo thumbnails (grouping the coordinates when the zoom factor is too low to display them all etc.), GPX tracks and so on? If so, we (at KPA) should rethink our implementation (but I don't think that libkgeomap has been written for no reason ...). But after all, it's a eligible question (which surely can be answered by Gilles Caulier and/or Michael Hansen). In the beginning, there was code in digikam that displayed and grouped thumbnails of images on Marble, while in kipi-plugins there was a KHTML-based viewer for Google Maps, which only showed a marker at the position of the photo. Since we wanted both Marble and Google Maps in both places, we went the natural way of turning that code into a library so that it can be used in both places without duplicating code. Originally, we also wanted to show a web-based OpenStreetMap directly via KHTML to allow for more interaction with OpenStreetMap's layering options, but that option was abandoned because of incompatibilities between KHTML and OpenStreetMap's OpenLayer Javascript code at that time. Apart from that: If Google's terms of service allow using Google maps like libkgeomap does, I think it should be a decision of the user which map he/she wants to see. From the way I understood the terms of service, yes, this usage is ok. We also had a Google Summer of Code student work on the library, and the project was not rejected by Google. Of course I would rather see a collection of open data satellite imagery to be used instead, but I could not find any yet. Best regards, Michael Hansen
Re: libkgeomap
On 03.01.2015 15:09, Tobias Leupold wrote: IMHO, the real question is, shouldn't that pointless wrapper be deprecated in favor of just using Marble directly? Can marble be used in an identical way as libkgeomap, as a QWidget only displaying a map with not only coordinates but also photo thumbnails (grouping the coordinates when the zoom factor is too low to display them all etc.), GPX tracks and so on? If so, we (at KPA) should rethink our implementation (but I don't think that libkgeomap has been written for no reason ...). But after all, it's a eligible question (which surely can be answered by Gilles Caulier and/or Michael Hansen). In the beginning, there was code in digikam that displayed and grouped thumbnails of images on Marble, while in kipi-plugins there was a KHTML-based viewer for Google Maps, which only showed a marker at the position of the photo. Since we wanted both Marble and Google Maps in both places, we went the natural way of turning that code into a library so that it can be used in both places without duplicating code. Originally, we also wanted to show a web-based OpenStreetMap directly via KHTML to allow for more interaction with OpenStreetMap's layering options, but that option was abandoned because of incompatibilities between KHTML and OpenStreetMap's OpenLayer Javascript code at that time. Apart from that: If Google's terms of service allow using Google maps like libkgeomap does, I think it should be a decision of the user which map he/she wants to see. From the way I understood the terms of service, yes, this usage is ok. We also had a Google Summer of Code student work on the library, and the project was not rejected by Google. Of course I would rather see a collection of open data satellite imagery to be used instead, but I could not find any yet. Best regards, Michael Hansen
Re: Changes to our Git infrastructure
On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote: Ease of installation and it's the availability of the necessary interpreters within mainstream distributions should be more than sufficient criteria here. Limiting it by any other criteria is playing pure favouritism to a given set of language(s) and unnecessarily limits our options. Ben, you and Jeff appear to disagree with my point that e.g. requiring a PHP tool to be installed client-side on each developers' and contributors' machine might be a little bit discouraging. It is OK to say that you disagree, but it doesn't prove the point to be any less valid. It's fine to have people assign varying importance to different evaluation criteria, so please do not use your sysadmin hat to unilaterally remove this pure favoritism just because you do not see any value in it. My impression was that we're gathering a list of possible requirements and *then* we, as a community, are going to assign some importance factor to each and every item raised. It is therefore acceptable to have mutually exclusive criteria at this point, or even bits which some of us might find to be totally irrelevant. They are going to be sorted out be community's consensus, I suppose. With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to our Git infrastructure
On Monday 05 January 2015 23:57:40 Ben Cooksley wrote: On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát j...@kde.org wrote: On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote: Ease of installation and it's the availability of the necessary interpreters within mainstream distributions should be more than sufficient criteria here. Limiting it by any other criteria is playing pure favouritism to a given set of language(s) and unnecessarily limits our options. Ben, you and Jeff appear to disagree with my point that e.g. requiring a PHP tool to be installed client-side on each developers' and contributors' machine might be a little bit discouraging. It is OK to say that you disagree, but it doesn't prove the point to be any less valid. It's fine to have people assign varying importance to different evaluation criteria, so please do not use your sysadmin hat to unilaterally remove this pure favoritism just because you do not see any value in it. My impression was that we're gathering a list of possible requirements and *then* we, as a community, are going to assign some importance factor to each and every item raised. It is therefore acceptable to have mutually exclusive criteria at this point, or even bits which some of us might find to be totally irrelevant. They are going to be sorted out be community's consensus, I suppose. The list of requirements is first gathered from the community. We then summarize it with items being weighted based on the level of support mentioned by various people and send it back. If everyone is broadly happy we then go ahead and prepare solutions which meet this list of requirements. There is no community level sorting of the items because items don't have a priority - it is a best effort basis to meet all of the requested features and functions. These proposals are accompanied by the pros and cons each faces, along with a recommendation for the one we believe best fits the needs of the community. You can see an example of this in the initial git.kde.org setup which Sysadmin did many years ago (2010 I think). Hm, why don't we do a prioritization poll? Quite some items raised by others are totally unimportant to me, and probably vice versa. While I agree that it would be nice to make everyone happy, I doubt that's going to work out. If we concentrate on the important aspects first, the admins would have less work and most people are still happy. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: Changes to our Git infrastructure
On 4 Jan 2015, at 20:41, Thiago Macieira wrote: On Saturday 03 January 2015 15:35:12 Jeff Mitchell wrote: - Not needing a CLI tool in an obscure language (PHP, Java, .NET,...). .NET is a framework, not a language. Maybe you meant C#. Regardless, I fail to see how any of those are obscure. They're three of the most popular and widespread languages in the world. For command-line applications on Linux? A binary's a binary. As I stated in my example, I use git-annex, which is coded in Haskell. It's not a common language for command-line applications on Linux, but it works and is useful. I don't see why it being in an obscure language matters. --Jeff
Re: Changes to our Git infrastructure
On Monday, 5 January 2015 12:43:06 CEST, Milian Wolff wrote: Hm, why don't we do a prioritization poll? Quite some items raised by others are totally unimportant to me, and probably vice versa. While I agree that it would be nice to make everyone happy, I doubt that's going to work out. If we concentrate on the important aspects first, the admins would have less work and most people are still happy. +1, this is exactly what I wanted to say. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to our Git infrastructure
On Monday 05 January 2015 09:14:36 Jeff Mitchell wrote: On 5 Jan 2015, at 4:05, Jan Kundrát wrote: Ben, you and Jeff appear to disagree with my point that e.g. requiring a PHP tool to be installed client-side on each developers' and contributors' machine might be a little bit discouraging. Yes, because you are repeatedly assuming that such a tool would be required on all developers' and contributors' machines, and are ignoring our repeated statements that this is not a requirement to be a developer or contributor. I think you two are misunderstanding each other. Jan is worried about the cli tools for developers, i.e. what currently is rbt tools. You, otoh, speak about the server-side tools, which of course can be written in any language you are willing to install on the server side. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 4:37, Jan Kundrát wrote: On Sunday, 4 January 2015 13:21:12 CEST, Thomas Friedrichsmeier wrote: True, but don't forget about the other side of the story: - potential contributors will have to learn more stuff, before they can even _start_ contributing, which may be a real turn-off in some cases. That's a valid concern, so the core question is whether this scenario: - make changes - make a commit - push that commit is any more complex than: - make changes - create a diff - upload that diff via a browser. I have to admit I have no idea which one is *really* easier for a total newbie, and which one is easier for an average contributor. Obviously, you forgot another workflow that has been discussed: - make changes - make a commit - use a CLI tool to push the change up for review --Jeff
Re: Review Request 121805: kconfig: fix building when KDE_INSTALL_DIRS_NO_DEPRECATED is set
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121805/#review73185 --- Ship it! Thanks for fixing this, Jeremy! :) - Marko Käning On Jan. 3, 2015, 3:20 nachm., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121805/ --- (Updated Jan. 3, 2015, 3:20 nachm.) Review request for kdelibs and Marko Käning. Repository: kconfig Description --- Use KF5_INSTALL_TARGETS_DEFAULT_ARGS so kconfig will configure when KDE_INSTALL_DIRS_NO_DEPRECATED is set. Diffs - src/kreadconfig/CMakeLists.txt 3804e16 Diff: https://git.reviewboard.kde.org/r/121805/diff/ Testing --- It builds again on osx where it didn't previously. Thanks, Jeremy Whiting
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 10:40, Jan Kundrát wrote: On Monday, 5 January 2015 16:23:15 CEST, Thomas Lübking wrote: To sum up my understanding: - Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a client. - Nobody remotely intends to *require* this (but one can oc. *offer* tools written on any whatsoever exotic requirement) Phabricator has an equivalent of rbtools/rbt called Arcanist which is written in PHP. There are AFAIK no other tools for automating working with Phabricator's code review subsystem. No, but it's all API driven so you are free to write whatever tools you may like. I claim that requiring PHP or JVM or .NET for each developers'/contributors' productive work is bad. I claim that apt-get install php5-cli is not any more difficult than any other package installations developers may have to perform. Since you brought up Java, if we were talking about a Java tool, I would make the same claim about apt-get install (your pick of default-jre, default-jre-headless, openjdk-7-jre). .NET, apt-get install mono-runtime. Jeff's response is that PHP is not really required because they can just juggle patches by hand and paste them to web interfaces or pipe to `git am`. While this is technically correct, I find this logic misleading So is your characterization of my claims. For one, I've never said anything about juggling patches by hand or piping to git am, only about web interfaces. You have claimed that for the occasional contributor with one to two patches a year that installing such a tool is onerous. I disagree with that, but regardless, I've said that submitting patches via a web interface should be perfectly fine for such occasional contributors and that those that will want the power of the CLI tool are likely to be more advanced developers/contributors -- who I don't believe would find the setup of such a tool to be difficult or onerous. I do not claim that in a Phabricator world that advanced/regular developers would be required to always copy and paste diffs into a web UI (and realistically if using the web UI you'd probably save the diff to a file and then just upload it). Those that prefer such a workflow could use it. Those that don't -- and that don't have unwavering language preferences for their tools -- would have command-line options. and say that in absence of tools which are on-par with Arcanist, PHP is effectively required, and I do find this situation a downside of Phabricator. Your hatred of PHP is well noted. I do not feel so strongly as you about the languages in which useful tools are written. As I said before, I can't speak for the broader KDE development community about that (and I doubt you can either). I also point out that there are other tools which do not require a client-side PHP script. Yes, you've made that abundantly clear. --Jeff
Re: Changes to our Git infrastructure
On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote: Your hatred of PHP is well noted. I don't think it's hate - but it remains an undeniable fact that it's of little use on typical client systems. Therefore it's a valid concern that people might very well be pushed off by the requirement to install it for the only purpose of pushing reviews via cli. Cheers, Thomas
Re: Review Request 121805: kconfig: fix building when KDE_INSTALL_DIRS_NO_DEPRECATED is set
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121805/ --- (Updated Jan. 5, 2015, 9:57 a.m.) Status -- This change has been discarded. Review request for kdelibs and Marko Käning. Repository: kconfig Description --- Use KF5_INSTALL_TARGETS_DEFAULT_ARGS so kconfig will configure when KDE_INSTALL_DIRS_NO_DEPRECATED is set. Diffs - src/kreadconfig/CMakeLists.txt 3804e16 Diff: https://git.reviewboard.kde.org/r/121805/diff/ Testing --- It builds again on osx where it didn't previously. Thanks, Jeremy Whiting
Re: Changes to our Git infrastructure
On Monday 05 January 2015 12:06:57 Jeff Mitchell wrote: On 5 Jan 2015, at 11:57, Thomas Lübking wrote: On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote: Your hatred of PHP is well noted. I don't think it's hate - but it remains an undeniable fact that it's of little use on typical client systems. Therefore it's a valid concern that people might very well be pushed off by the requirement to install it for the only purpose of pushing reviews via cli. I really, really don't understand this concern. We're not in the days of 500MB hard drives and nobody is asking anyone to install constantly-running daemons with open ports. I don't shiver with fear when I apt-get install a package and it wants to pull in a bunch of (non-daemon) libraries. Whatever you need to do your job, man. But I recognize that this may be a limitation of my own psyche. Personally, I also fail to see the issue here. PHP is 15.23MiB on my Arch box. Compare that with 34M of karchive build dir when you enable debug symbols (and karchive is small!). Bye -- Milian Wolff m...@milianw.de http://milianw.de
Help solving this month's Bug of the Month
Hi developers! The KDE Gardening Team nominates one particular annoying bug as “The Bug of the Month”, see https://community.kde.org/Gardening This time, kded memory leaks await investigation: https://bugs.kde.org/show_bug.cgi?id=271934 To trace memory leaks in running processes, Milian Wolff created a new tool heaptrack, so if you can reproduce memory leaks, please try it. See http://milianw.de/tag/heaptrack Please help solving it, by adding ideas or patches to the relevant pages, review requests, or bugzilla pages. Anyone is invited to participate and our users will appreciate this bug getting solved. Suggestions for next month's bug to the kde-gardening mailing list. Thanks in advance! -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 11:06, Jan Kundrát wrote: On Monday, 5 January 2015 16:05:07 CEST, Jeff Mitchell wrote: - Existing KDE account holders can and do use git for their workflow. - Using non-git workflow for others introduces a different workflow to the mix. - Having two workflows is more complex than having just a single one. Does it make it more understandable? No. What you're saying is having two tools is more complex. It's still one workflow. I feel like you're just language-lawyering here. The workflow I propose pushes the burden of producing clean patches to the contributor. The workflow you're advocating for appears to center around sending patches around Sending patches around? That's quite the stretch from submitting a diff to a web interface and recalls the KDE 1.0 days. And you're accusing me of language-lawyering? The problem here is that you believe -- incorrectly -- that a single workflow cannot include more than one tool. The reason I can definitively say that you are incorrect is because your own preferred workflow involves more than one tool, regardless of how they interact. And if yours does, you can't complain about other workflows that do. GitHub is a notable example showing that people don't seem to have an issue with a workflow that uses Git + a web-based tool to manage their code reviews. I'm not saying we need to end up with that, I just don't think it's credible to claim that it's too difficult or complex. That isn't an example that proves your point, though. It does if my point was (and it was) that a workflow consisting of producing a commit in Git and having the review take place via a web UI is a very broadly accepted paradigm in software development, and one that is often considered to be friendly to newcomers. and I believe you were saying that it's fine for a CR tool to work on patches and not git trees. Correct. Although I recognize the merits of such an approach, I do not believe that the only acceptable way for a code review tool to work is on git trees instead of via patches. And I do not believe that this one feature is enough to outright dismiss all other options. Given your earlier statements I imagine, but this is only supposition, that one of the reasons you desire such an approach is so that you can have all review actions be performed via SSH commands without requiring either a web UI or external tool. While this is certainly nice to have, I don't believe that it is very usable for newcomers (we've weathered enough complaints over the years about Gitolite SSH commands). Given the earlier distinction you made between contributors and developers, it also requires those that want to contribute patches to have full KDE developer accounts with commit/push access in order to push those diffs up for code review...something not required from a web interface requiring only an Identity account. --Jeff
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 11:57, Thomas Lübking wrote: On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote: Your hatred of PHP is well noted. I don't think it's hate - but it remains an undeniable fact that it's of little use on typical client systems. Therefore it's a valid concern that people might very well be pushed off by the requirement to install it for the only purpose of pushing reviews via cli. I really, really don't understand this concern. We're not in the days of 500MB hard drives and nobody is asking anyone to install constantly-running daemons with open ports. I don't shiver with fear when I apt-get install a package and it wants to pull in a bunch of (non-daemon) libraries. Whatever you need to do your job, man. But I recognize that this may be a limitation of my own psyche. --Jeff
Re: Changes to our Git infrastructure
On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote: Sending patches around? That's quite the stretch from submitting a diff to a web interface and recalls the KDE 1.0 days. And you're accusing me of language-lawyering? The problem here is that you believe -- incorrectly -- that a single workflow cannot include more than one tool. I believe this discussions heat turned into talking in absolutes. Your truth - my truth. It's not a matter of what is possible, but of preferences (while we probably all prefer to not return to send patches on mailing lists ;-) Since they may obviously cover a large range, scale seems a major requirement on workflow and tools. Pure CLI access on alinged syntax for efficient pros is as relevant as an easy GUI access for starters. Correct. Although I recognize the merits of such an approach, I do not believe that the only acceptable way for a code review tool to work is on git trees instead of via patches. I'd assume operating on git trees is certainly far more important for CI than for reviewing patches. And I do not believe that this one feature is enough to outright dismiss all other options. See? Absolutes ;-) No feature trumps all others, but it's a matter of ranking and thus all must be taken into fair and objective consideration. distinction you made between contributors and developers, it also requires those that want to contribute patches to have full KDE developer accounts with commit/push access in order to push those diffs up for code review I don't think this is actually a requirement - the review repo (maybe even branches) could easily have other/lower credential requirements than the vanilla one. Cheers, Thomas
Re: Changes to our Git infrastructure
On Monday, 5 January 2015 18:01:12 CEST, Jeff Mitchell wrote: The problem here is that you believe -- incorrectly -- that a single workflow cannot include more than one tool. The reason I can definitively say that you are incorrect is because your own preferred workflow involves more than one tool, regardless of how they interact. And if yours does, you can't complain about other workflows that do. I was complaining about an IMHO artificial split where drive-by people submit changes in a different way than core developers. I stated that this introduces some needless difference to the way devs and contributors work, and that we should check whether there are tools that remove this difference. I know that e.g. Gerrit removes that difference, so I am not thrilled by the idea of using something without that feature. It does if my point was (and it was) that a workflow consisting of producing a commit in Git and having the review take place via a web UI is a very broadly accepted paradigm in software development, and one that is often considered to be friendly to newcomers. You're right, and I apologise for not understanding you correctly, we're in violent agreement after all. and I believe you were saying that it's fine for a CR tool to work on patches and not git trees. Correct. Although I recognize the merits of such an approach, I do not believe that the only acceptable way for a code review tool to work is on git trees instead of via patches. And I do not believe that this one feature is enough to outright dismiss all other options. That's another thing where I should have probably worded my responses better. The requirements I listed were things which I found valuable for my work. I did not mean to say that it's the only possible way of doing reviews, or that I found everybody who disagrees with me to be a moron. It's just that these features are important for me, so I would like to see them and I wanted to make sure they are listed as a requirement in a list of points gathered by the community. Maybe this misunderstanding is caused by sysadmins likely perceiving the requrements as hard ones which MUST be provided by any solution, while my impression is that we were asked to say what is important for us, and the evaluation is to be performed by us all together, not just the sysadmins. Given your earlier statements I imagine, but this is only supposition, that one of the reasons you desire such an approach is so that you can have all review actions be performed via SSH commands without requiring either a web UI or external tool. While this is certainly nice to have, I don't believe that it is very usable for newcomers. I agree that *that* would suck :). Given the earlier distinction you made between contributors and developers, it also requires those that want to contribute patches to have full KDE developer accounts with commit/push access in order to push those diffs up for code review...something not required from a web interface requiring only an Identity account. There is no need for full KDE developer account to upload changes for review with Gerrit. All that is needed is a regular Identity account. Behind the scenes, it works by Gerrit being a special git server which intercepts pushes and stores each of these changes in a separate ref. I'll be happy to go into more detail in another thread, off-list or on IRC. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 12:15, Thomas Lübking wrote: On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote: It's not a matter of what is possible, but of preferences (while we probably all prefer to not return to send patches on mailing lists ;-) Since they may obviously cover a large range, scale seems a major requirement on workflow and tools. Pure CLI access on alinged syntax for efficient pros is as relevant as an easy GUI access for starters. Totally agree. Correct. Although I recognize the merits of such an approach, I do not believe that the only acceptable way for a code review tool to work is on git trees instead of via patches. I'd assume operating on git trees is certainly far more important for CI than for reviewing patches. Yes, that's correct. But then we need to remember that there is a social component that is not finalized (and discussed in another thread), which is branch policy. Without operating on git trees, a developer could still be working on a feature branch and have a review going for the commits in that feature branch, and the CI could operate on that branch. The harder integration (and by no means should be assumed impossible, I'm just not sure how easy it would be at the moment since I haven't looked) for CI with respect to git trees vs. patches would be for one-off patches that aren't keyed to branches. But, if we're talking about contributors, not KDE developers with commit access, then they can't work with git trees anyways; if someone is already a KDE developer, they could work in a feature branch. Or not. Generally I'm happy providing tools and letting the various projects decide on their own preferred method for handling branches and patches. distinction you made between contributors and developers, it also requires those that want to contribute patches to have full KDE developer accounts with commit/push access in order to push those diffs up for code review I don't think this is actually a requirement - the review repo (maybe even branches) could easily have other/lower credential requirements than the vanilla one. There aren't such things as review repos right now, even on the current infrastructure (you could consider clones to be that, but creating clones and scratch requires full KDE developer accounts). Yes, you are right that highly flexible branch policy may allow something like this, but right now there is no such thing as commit access without having a full developer account. I think changing that -- assuming tool support for this -- would be a deeper policy discussion that is probably best had in a different thread. --Jeff
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 22:26:24, Boudewijn Rempt va escriure: Well, _obviously_ reviewboard supports raising issues and adding comments , but neither facilitates actual conversation, i.e. discussion on what's up with a particular patch at a deeper level. In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. Well, how would you want to have a proper discussion then? What's your desired workflow/UI for it? I see what you mean, but to me it seems more a misuse of the tool by the community, not a fault of the tool itself. Cheers, Albert On Mon, 5 Jan 2015, Albert Astals Cid wrote: El Dilluns, 5 de gener de 2015, a les 18:40:54, Boudewijn Rempt va escriure: I do agree, btw, with Ian, that the current reviewboard workflow is badly broken and can be very discouraging. It doesn't support conversation What do you mean it doesn't support conversation? Cheers, Albert
Re: Changes to our Git infrastructure
On Montag, 5. Januar 2015 22:26:24 CEST, Boudewijn Rempt wrote: In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. I don't think this is a problem w/ RB. When RRs get on k-c-d, many devs who can provide an abstract review are addressed. They can take /this/ load from the actual maintainer/main developer. But if nobody feels in charge for the addressed component, you won't get an informed response. Before Ian started the DrKonqui patches I had not seen the drkonqui code even one single time and my idea who worked on it was from the git history Bottom line: things are maintained by an individuum or not at all. If everybody is in charge, nobody actually is. Cheers, Thomas
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 22:29:36, Thomas Lübking va escriure: On Montag, 5. Januar 2015 21:36:54 CEST, Albert Astals Cid wrote: What's the problem with php? Dynamic typing ;-) I don't think there's a particular issue with php in this context. To me the concern seemed to have more been around try to not require stuff that's not likely around anyway We have ruby scripts Where (wrt code submission?)? Oh, rbtools is python, somehow i thought it was ruby. Well goes to show it doesn't matter the least what a tool is written on, you just install it and run it :) Cheers, Albert
Re: Changes to our Git infrastructure
Well, this getting to a pretty useless discussion. You set out to prove that you find it all very simple, and I am sure you find it simple. You don't have to rebut everything I say point by point to prove whatever you think you are proving because the point is this: you find it simple, others don't. What you have to do is accept is this: others don't. The rest of the world is fine with accepting that you think it's simple, that's not the point of the discussion. So, yes, you cannot write a git-for-dummies manual, for that we need a genius like David Revoy. Just get this: you hope everyone has met a DVCS. I regularly meet people for whom git is a magic way of getting new features, and who have _no_ idea at all about what version control is, or what source code is. And many of them turn out to be awesome contributors, and some even, after a year or two, help with git bisecting a particular bug. So all I want to make sure here is that participation in KDE is as accessible as possible to the great majority of the world that doesn't want to play the 'serious software engineer', qt-project.org-style. That is why I've given the link to what non-engineers active in #krita think about KDE's infrastructure, and that's why I've tried to show you how intimidating something you find very simple actually is, how many steps that you know are optional, or necessary, you actually forgot to mention in your little list. On Mon, 5 Jan 2015, Albert Astals Cid wrote: El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure: On Mon, 5 Jan 2015, Albert Astals Cid wrote: I think this is due to the fact that it's quite simple git clone kde:repo This requires: * setting up gitconfig with the kde: alias. That requires finding the right info on techbase, as well as the awareness that techbase exists. You can always just use the full url. * figuring out the reponame for a particular project (and that isn't as easy as just downloading the entire trunk of kde's svn repo -- even if I never did that myself) Sure, if you don't know the repo name you're out of luck, not that downloading the whole trunk would help you much more (you can still grep but it may take ages) do coding git commit * using the commit template You don't really need a commit template (though it's nice if you use it) * with the relevant keywords You don't really need to use the keywrods (though it's nice if you use it) * having a grasp of what a git commit is, especially that a commit isn't visbile to anyone else Any modern (i.e. DVCS) has that concept, sure it's complicated for cvs/svn people, i'd like to think most of us has worked with a DVCS at the moment. git push But not before you have * realized that you need to push, i.e. what local and remote is Same as above, it's DCVS. * figured out what branches are for, and how different projects handle those Right, that's hardly documentable though (and will get old soon most probably) * got your kde indenity Every system needs it's own identity system, we use ours. * posted it on the right reviewboard Reviewboard is not mandatory (though it's nice) * to the right reviewers Yes, you either have to pick the reviewers or let a robot do your job. That said, i'm not saying contributing is easy, i'm just saying the pure git part is not that hard, it's all the project overhead (branches, review, account, etc) that really makes it harder (in my opinion). Cheers, Albert
Re: Changes to our Git infrastructure
On Montag, 5. Januar 2015 22:58:43 CEST, Boudewijn Rempt wrote: For me, personally, RB's mails are even worse. Ok, but that's pretty much OT, isn't? (Same problem with this thread, or rather mailing list. Why the heck do I need to get two copies of every reply to a mail of mine... One is _enough_. And yes, I know about the whole reply-to-mangling-is-dangerous lunacy.) You get them, because you send them. kcd is cc'd by your mails what will in the end make mail clients reply to all rather than just to the mailing list. Reviewboard isn't limited to kde-core-devel. It's not only not limited, it's not even bound to kcd. The receivers depend on the groups you attach to the RR. And it doesn't answer my main complaint: reviewboard, by its design, is made to whine about whitespace, extra white at the end of lines and other one-line complaints. a) breaking coding style is bad style anyway. Get a better editor, don't introduce tabs and trailing spaces and weird indention etc. and there'll be no complains. b) You missed my argument. MANY ppl. can give you an abstract review (whitespace, hot loop, performs crap, this may crash) but only VERY FEW ppl. can make a feature comment. If none of the latter ever shows up because the component has vacant maintainance, you might oc. feel that ppl. only nitpick, but the alternative is that your patch remains entirely uncommented and if you at some point just push it, you'd introduce unnecessary style breaks and bad code on top of that. It gives the reviewer a happy feeling of a job well-done That's nonsense. It ideally maintains general code quality by many eyes. If you are in charge of a component and have fundamental comments, you certainly won't restrict yourself to comment the patch on an abstract level. and the submitter a cold shower. Eye of the beholder? It's a tasklist. Nothing more, nothing less. If that scares you, you probably would not want to hear fundamental concerns at all. There might be a cultural gap between rather polite (lying) and rather direct (offending) societies, but that won't be fixed by any communcation tool in the near future. Cheers, Thomas
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 23:46:18, Alexander Neundorf va escriure: On Monday, January 05, 2015 22:35:23 Albert Astals Cid wrote: El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure: ... * figured out what branches are for, and how different projects handle those Right, that's hardly documentable though (and will get old soon most probably) this is IMO one of the main issues. This really should be documented, and ideally should be consistent for all KDE repositories. And this policy also shouldn't change often. How to deal with branches correctly, i.e. how the project maintainers expect it, is a big part what can make using git hard. But that hasn't changed since svn, no? (Not saying it's good or bad, just saying i don't see this is a difference in git) Cheers, Albert E.g. using git for cmake is easier, because there the workflow (how to branch etc.) is fully documented. Alex
Re: Changes to our Git infrastructure
I'm just trying to make clear that reviewboard is a crappy tool inciting people to write crappy reviews that drive people away. Apart from any other nonsense about cultural differences (the standard cop-out from Dutchmen and Germans -- I ain't rude, I'm just honest, it's cultural!), I think that people should read Ian's mail, with attention: Speaking for myself, I find this a huge turnoff in the KDE world and am now planning to retire from KDE as soon as I can. But then I am 76 and git is my 10th source-code control system since 1965-66, so I have little interest in mastering it. I have also found ReviewBoard utterly counter-productive this year, either because one writes an entry and nobody reviews it, or nobody understands it, or because one gets nitpicked about syntax and white space when one is really looking for helpful advice about how better to solve the problem at hand. I think I must have lost a month or two on ReviewBoard during the year, with very little helpful advice gained. I consider nitpick reviews harmful. If you have nothing better to do than nitpick, don't, and reviewboard is a tool which encourages you to do. On Mon, 5 Jan 2015, Thomas Lübking wrote: On Montag, 5. Januar 2015 22:58:43 CEST, Boudewijn Rempt wrote: For me, personally, RB's mails are even worse. Ok, but that's pretty much OT, isn't? (Same problem with this thread, or rather mailing list. Why the heck do I need to get two copies of every reply to a mail of mine... One is _enough_. And yes, I know about the whole reply-to-mangling-is-dangerous lunacy.) You get them, because you send them. kcd is cc'd by your mails what will in the end make mail clients reply to all rather than just to the mailing list. Reviewboard isn't limited to kde-core-devel. It's not only not limited, it's not even bound to kcd. The receivers depend on the groups you attach to the RR. And it doesn't answer my main complaint: reviewboard, by its design, is made to whine about whitespace, extra white at the end of lines and other one-line complaints. a) breaking coding style is bad style anyway. Get a better editor, don't introduce tabs and trailing spaces and weird indention etc. and there'll be no complains. b) You missed my argument. MANY ppl. can give you an abstract review (whitespace, hot loop, performs crap, this may crash) but only VERY FEW ppl. can make a feature comment. If none of the latter ever shows up because the component has vacant maintainance, you might oc. feel that ppl. only nitpick, but the alternative is that your patch remains entirely uncommented and if you at some point just push it, you'd introduce unnecessary style breaks and bad code on top of that. It gives the reviewer a happy feeling of a job well-done That's nonsense. It ideally maintains general code quality by many eyes. If you are in charge of a component and have fundamental comments, you certainly won't restrict yourself to comment the patch on an abstract level. and the submitter a cold shower. Eye of the beholder? It's a tasklist. Nothing more, nothing less. If that scares you, you probably would not want to hear fundamental concerns at all. There might be a cultural gap between rather polite (lying) and rather direct (offending) societies, but that won't be fixed by any communcation tool in the near future. Cheers, Thomas
Re: Changes to our Git infrastructure
On Monday, January 05, 2015 23:53:02 Boudewijn Rempt wrote: I'm just trying to make clear that reviewboard is a crappy tool inciting people to write crappy reviews that drive people away. Apart from any other nonsense about cultural differences (the standard cop-out from Dutchmen and Germans -- I ain't rude, I'm just honest, it's cultural!), I think that people should read Ian's mail, with attention: Speaking for myself, I find this a huge turnoff in the KDE world and am now planning to retire from KDE as soon as I can. But then I am 76 and git is my 10th source-code control system since 1965-66, so I have little interest in mastering it. I have also found ReviewBoard utterly counter-productive this year, either because one writes an entry and nobody reviews it, or nobody understands it, or because one gets nitpicked about syntax and white space when one is really looking for helpful advice about how better to solve the problem at hand. I think I must have lost a month or two on ReviewBoard during the year, with very little helpful advice gained. I consider nitpick reviews harmful. If you have nothing better to do than nitpick, don't, and reviewboard is a tool which encourages you to do. I wouldn't blame it on reviewboard, I don't have the impression it differs in this regard e.g. from gerrit. Alex
Re: Changes to our Git infrastructure
On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote: In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. That is a development culture issue than no tool can fix. Reviewboard is great for discussing changes in the hands of people who value that sort of interaction. It also can be used to deliver only nitpicking in a non- constructive manner. The difference in experience comes down to the what the people using it value. Where reviewboard is not good enough is in making it easy to quickly try the patch (bi-directional scm integration) ... but the commenting and discussion features are pretty much as good as it gets. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Changes to our Git infrastructure
On Mon, 5 Jan 2015, Aaron J. Seigo wrote: On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote: In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. That is a development culture issue than no tool can fix. Not fix, but a tool can encourage one way or another. Reviewboard is great for discussing changes in the hands of people who value that sort of interaction. It also can be used to deliver only nitpicking in a non- constructive manner. The difference in experience comes down to the what the people using it value. Where reviewboard is not good enough is in making it easy to quickly try the patch (bi-directional scm integration) ... but the commenting and discussion features are pretty much as good as it gets. -- Aaron J. Seigo
Re: Changes to our Git infrastructure
On Montag, 5. Januar 2015 23:53:02 CEST, Boudewijn Rempt wrote: I'm just trying to make clear that reviewboard is a crappy tool inciting people to write crappy reviews that drive people away. And I was trying to make clear that those crappy reviews are just the house cleaning stuff that should ideally go along w/ the functional reviews. That you believe it's the only kind of review you get implies that you would simply not have gotten any other review otherwise. Not ideal, but rather unrelated. Apart from any other nonsense about cultural differences (the standard cop-out from Dutchmen and Germans -- I ain't rude, I'm just honest, it's cultural!) Sorry, I was just trying to understand what could get anyone scared about a very simple and direct please fix this, this and that list - it would have to be fixed anyway at some point. I'm sorry if you or anyone feels offended by the way it's presented, but to change that, one would first need to have a remote idea, what's so driving away about it. And sorry again, but I really cannot even imagine - wheter you may call that rude or dumb. Ian and the DrKonqui bug: --- I think that people should read Ian's mail, with attention: I have read Ian's mail and I do recall his review requests on DrKonqi. I agree that the process was anything but fluid - though ultimately successful. Apparently nobody actually felt in charge of DrKonqi then (and now, since Ian will apparently be sadly lost, again), so other developers, unfamiliar w/ DrKonqi commented on the patches - the first two of them actually focussing on OSX specific (or rather triggered) issues. The last one addressed DrKonqi being broken due to bugzilla changes. It was presented first on 30/9/2014, saw an immediate coding style and function design review, resolved 3/10/2014. Followed up by a minor nitpick to not use fprintf, but kdebug and a call for someone w/ experience on the codebase to review on 5/10/2014 On 6/10/2014 Ian worried that he's perhaps the person most familiar with the codebase of Dr Konqi, having worked on it for a few months now and sugested to push the patch within the next 24h. This raised immediate concerns from the release team about the size of the patch, discouraging to submit it to 4.14 what caused a hyperactive 7/10/2014 with the discussion leading to the consensus that a vastly simplified version of the patch would still be the best option for 4.14 (and suggestions on how to simplify things) with the result being finally presented 9/10/2014 and submitted and submitted in time 23h later. I would fully agree that 7/10/2014 should have been 30/9/2014, but the most important thing is: IT TOOK A VETO FROM THE RELEASE TEAM and thus THE THREAT OF A BROKEN DR KONQI FOR KDE SC4 to cause major interest in the patch, what is, given the DrKonqi bug was reported long before, a clear sign that nobody actually had a special interest. In the end, blind ppl. were supposed to guide the one-eyed. AND NO TOOL ON EARTH WILL EVER FIX SUCH A SITUATION. Tools are as good or bad as the ppl. that use them. The problem is *not* that RB encourages nitpicks, but the problem is that there's completely unmaintained code where nobody feels qualified to sign off patches. Ian is certainly the one person permitted to retire whenever he feels like, but /actually/, now that the worst time is passed, he would be the one to fix *this* problem for DrKonqi, ie. become the person to sign off patches. Cheers, Thomas
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 12:40, Boudewijn Rempt wrote: All this back-and-forth about cli tools actually sounds weird to me. I know that the beginners who start hacking on Krita would never use any of them. Git on the command line is often already something they can be rightly proud of when they master the beginnings. Heck, I myself haven't used rbtools, even though the reviewboard site urges it strongly. Let the real experts use cli tools, and they can handle a bit of obscurity. So I don't think obscure cli tools matter even one whit -- what matters is having the nicest possible web tools that make life for people as easy as possible. Ideally, people shouldn't need a kde identity to submit something (patch, bug report, idea, screenshot, plea for help), and reviewers should be able to drop into a private conversation with only very little effort. Agreed. We've been looking for more friendly, better-integrated, and more usable tools for a long time. Not just for newcomers, but especially for newcomers. When you're an old hand at development, minimal setup of a useful tool is just not a huge burden. I do disagree about needing a KDE identity to submit things like bug reports; it is not useful to be unable to follow-up with someone, and if they don't have an email address they're much less likely to remember to check back. Not to mention link spam and all sorts of other nastiness. Possibly allowing non-Identity account providers for non-developers is a good middle ground (Google, Twitter, Facebook, GitHub). --Jeff
Re: Changes to our Git infrastructure
On Mon, 5 Jan 2015, Jeff Mitchell wrote: I do disagree about needing a KDE identity to submit things like bug reports; it is not useful to be unable to follow-up with someone, and if they don't have an email address they're much less likely to remember to check back. Not to mention link spam and all sorts of other nastiness. Possibly allowing non-Identity account providers for non-developers is a good middle ground (Google, Twitter, Facebook, GitHub). Yes, that should be totally fine. The intersection of people who don't want a kde identity (or find it too much bother) and those people who feel g, t, f, gh are too invasive is really small, and, honestly, likely too individual to be helpful. Boudewijn
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 12:39, Jan Kundrát wrote: On Monday, 5 January 2015 18:01:12 CEST, Jeff Mitchell wrote: The problem here is that you believe -- incorrectly -- that a single workflow cannot include more than one tool. The reason I can definitively say that you are incorrect is because your own preferred workflow involves more than one tool, regardless of how they interact. And if yours does, you can't complain about other workflows that do. I was complaining about an IMHO artificial split where drive-by people submit changes in a different way than core developers. I stated that this introduces some needless difference to the way devs and contributors work, and that we should check whether there are tools that remove this difference. I know that e.g. Gerrit removes that difference, so I am not thrilled by the idea of using something without that feature. Understandable, although I think that as our policy currently stands over who can commit to repos, this is necessary anyways (since you need a developer account to commit, and once you have that you could work on a topic branch). It's also pretty common -- e.g. most GitHub repos don't allow people to commit directly, but rather go through a merge request workflow. But I understand why you feel that this would be a regression. That's another thing where I should have probably worded my responses better. The requirements I listed were things which I found valuable for my work. I did not mean to say that it's the only possible way of doing reviews, or that I found everybody who disagrees with me to be a moron. It's just that these features are important for me, so I would like to see them and I wanted to make sure they are listed as a requirement in a list of points gathered by the community. OK, sorry for misunderstanding. Maybe this misunderstanding is caused by sysadmins likely perceiving the requrements as hard ones which MUST be provided by any solution, while my impression is that we were asked to say what is important for us, and the evaluation is to be performed by us all together, not just the sysadmins. It's definitely why Ben put out a call for people to list requirements. We want to make sure that we understand what people are looking for. But it did seem like some people (not just you) were essentially saying if it doesn't have X we must not use it, regardless of whether a solution has A, B, C, ... Given the earlier distinction you made between contributors and developers, it also requires those that want to contribute patches to have full KDE developer accounts with commit/push access in order to push those diffs up for code review...something not required from a web interface requiring only an Identity account. There is no need for full KDE developer account to upload changes for review with Gerrit. All that is needed is a regular Identity account. OK. I was unaware of that since (normally speaking) Gerrit intercepts pushed refs and then pushes them into g.k.o. --Jeff
Re: Changes to our Git infrastructure
Hi, 2015-01-05 19:03 GMT+01:00 Jeff Mitchell: On 5 Jan 2015, at 12:40, Boudewijn Rempt wrote: All this back-and-forth about cli tools actually sounds weird to me. I know that the beginners who start hacking on Krita would never use any of them. Git on the command line is often already something they can be rightly proud of when they master the beginnings. Heck, I myself haven't used rbtools, even though the reviewboard site urges it strongly. Let the real experts use cli tools, and they can handle a bit of obscurity. So I don't think obscure cli tools matter even one whit -- what matters is having the nicest possible web tools that make life for people as easy as possible. Ideally, people shouldn't need a kde identity to submit something (patch, bug report, idea, screenshot, plea for help), and reviewers should be able to drop into a private conversation with only very little effort. Agreed. We've been looking for more friendly, better-integrated, and more usable tools for a long time. Not just for newcomers, but especially for newcomers. yes, I fully agree. It certainly makes sense to improve our tools such that they are more convenient for maintainers and others who contribute very frequently, but taking the needs of newcomers into account is also very important. Ultimately, a constant stream of newcomers is the only thing that keeps a free software project alive in the long term. I have read a large number of bug reports during the past few years, and I have very often seen first-time contributions which consisted of a patch which was generated by redirecting the output of git diff to a file and then attached to the bug report. In my experience, thanking the new contributor for their efforts and asking them to upload their patch file to http://reviewboard.kde.org/ via the web interface has a success rate of close to 100%, and often, the contributors will then continue to fix bugs and submit more patches. I'm a bit worried that any new patch review system which requires more effort before one can submit a patch for review might put some potential new contributors off. And I'm not talking about the requirement to not introduce unit test regressions or follow the coding style or fix white space issues here - that certainly makes sense! - but the effort that is required before one can even use the patch review system. Having said that, I do acknowledge that tools which are best suited for newcomers may not be the most efficient to use for frequent contributors and maintainers (and I appreciate all efforts that try to improve the situation for the latter). I just wanted to highlight that as little setup effort as possible may be a desirable property of a patch review system if attracting many newcomers is considered an important goal. Cheers, Frank
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 17:57:19, Thomas Lübking va escriure: On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote: Your hatred of PHP is well noted. I don't think it's hate - but it remains an undeniable fact that it's of little use on typical client systems. Therefore it's a valid concern that people might very well be pushed off by the requirement to install it for the only purpose of pushing reviews via cli. Is there any logical reason people would people be pushed off? Or is it just irrational? Cheers, Albert Cheers, Thomas
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 12:47, Thomas Lübking wrote: Stuff that relies on present and known libraries/executables has a lower barrier. I've no gtk3 installation atm. and when I need to pick among different tools, the one that doesn't require gtk3 wins. That may be irrational, but still happens. I'd put window-oriented tools in a different class than CLI tools, because the tool using gtk3 may have a very different look and feel, which many users can find legitimately jarring. Whatever you need to do your job, man. Erheemmm i doubt need to do your job holds for potential new contributors in any aspect :-P This was a comment to package X wanting to pull in a bunch of non-daemon libraries...not to people. :-) --Jeff
Re: Changes to our Git infrastructure
On Montag, 5. Januar 2015 16:10:51 CEST, Jeff Mitchell wrote: Not at all. I perfectly understand what Jan is talking about. To sum up my understanding: - Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a client. - Nobody remotely intends to *require* this (but one can oc. *offer* tools written on any whatsoever exotic requirement) Is that correct? In case and as this does not imply a real disagreement, the issue necessarily /is/ a simple misunderstanding - and apparent ambiguity on the other side :-P Cheers, Thomas
Re: Changes to our Git infrastructure
On 5 Jan 2015, at 10:23, Thomas Lübking wrote: On Montag, 5. Januar 2015 16:10:51 CEST, Jeff Mitchell wrote: Not at all. I perfectly understand what Jan is talking about. To sum up my understanding: - Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a client. Jan doesn't want to. I can't speak for the entire developer community. - Nobody remotely intends to *require* this (but one can oc. *offer* tools written on any whatsoever exotic requirement) Correct. --Jeff
Re: Changes to our Git infrastructure
On Monday, 5 January 2015 16:05:07 CEST, Jeff Mitchell wrote: - Existing KDE account holders can and do use git for their workflow. - Using non-git workflow for others introduces a different workflow to the mix. - Having two workflows is more complex than having just a single one. Does it make it more understandable? No. What you're saying is having two tools is more complex. It's still one workflow. I feel like you're just language-lawyering here. The workflow I propose pushes the burden of producing clean patches to the contributor. The workflow you're advocating for appears to center around sending patches around, so by definition in your workflow there's a big difference in the way 3rd party contributors work as opposed to what KDE developers do. My proposal aims at closing this gap. GitHub is a notable example showing that people don't seem to have an issue with a workflow that uses Git + a web-based tool to manage their code reviews. I'm not saying we need to end up with that, I just don't think it's credible to claim that it's too difficult or complex. That isn't an example that proves your point, though. The GitHub workflow actually involves a `git push` to be done by the contributor. That means that the GitHub workflow relies on contributors to curate git trees, and as such I like that workflow [1] because both core developers and contributors produce the same sort of artefacts. It's a different workflow from uploading patches via browser or via some client-side tool, though, and I believe you were saying that it's fine for a CR tool to work on patches and not git trees. [1] GitHub manages to screwup things when one does a rebase, but that's an implementation detail for the purposes of this discussion. Yes, it does make the workflow hardly usable for me. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 18:40:54, Boudewijn Rempt va escriure: I do agree, btw, with Ian, that the current reviewboard workflow is badly broken and can be very discouraging. It doesn't support conversation What do you mean it doesn't support conversation? Cheers, Albert
Re: Changes to our Git infrastructure
On Monday, January 05, 2015 16:15:09 Ian Wadham wrote: ... I wonder also how many people have just tiptoed quietly away from the KDE Community rather than speak out about frustrations they may have been feeling. Where *did* all those people go in the last few years? And why? I didn't really walk away, but the move from svn to git has made contributing to KDE for me harder/less fun. Just svn up in trunk/ was really nice. Now we have hundreds of repositories, and as far as I know there is still no using-git-for-KDE-development-for-dummies documentation (maybe because there is no common workflow for all of these many repositories). Having said that, the mail flood I get from Qt gerrit also isn't fun. After every comment a new review is requested... I don't have that time. Having a system where every repository (project) automatically has its own wiki and bug tracker is something I would really like to have. I think this is especially useful with the frameworks effort. I'd really like to see a homepage for each of the frameworks, and such a wiki page would be a natural place to put it. Alex
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 21:51:34, Alexander Neundorf va escriure: On Monday, January 05, 2015 16:15:09 Ian Wadham wrote: ... I wonder also how many people have just tiptoed quietly away from the KDE Community rather than speak out about frustrations they may have been feeling. Where *did* all those people go in the last few years? And why? I didn't really walk away, but the move from svn to git has made contributing to KDE for me harder/less fun. Just svn up in trunk/ was really nice. Now we have hundreds of repositories, and as far as I know there is still no using-git-for-KDE-development-for-dummies documentation (maybe because there is no common workflow for all of these many repositories). I think this is due to the fact that it's quite simple git clone kde:repo do coding git commit git push Obviously i think it is simple but you think it's not, i can't write a guide for dummies because i think it's simple and you can't write it because you don't know how to write it, it'd need to people to collaborate on it. If you can write somewhere your questions I'm sure we can find people to write the answers :) Cheers, Albert Having said that, the mail flood I get from Qt gerrit also isn't fun. After every comment a new review is requested... I don't have that time. Having a system where every repository (project) automatically has its own wiki and bug tracker is something I would really like to have. I think this is especially useful with the frameworks effort. I'd really like to see a homepage for each of the frameworks, and such a wiki page would be a natural place to put it. Alex
Re: Changes to our Git infrastructure
El Dilluns, 5 de gener de 2015, a les 17:25:48, Thomas Lübking va escriure: On Montag, 5. Januar 2015 16:40:52 CEST, Jan Kundrát wrote: Phabricator has an equivalent of rbtools/rbt called Arcanist which is written in PHP. So this is actually a concern on a particular tool. Leaving aside that Phabricator seems to be owned/maintained by Facebook Inc. (what alone may cause significant, though irrational, veto...) this is sth. that needed to be accounted. You should check your facts before calling for an irrational veto :) http://phabricator.org - Phabricator's development is lead by Phacility, Inc. Cheers, Albert How much of a problem it is is imo. atm out of scope, but eg. it would be less a problem on a fork/pullrequest driven workflow (esp. if a smart git hook would eg. support a PULLTHIS! keyword) but pretty much a showstopper for a RB/gerrit like approach. == The only relevant question to be answered in the current discussion is whether Just install php! is an acceptable answer to such concerns. I'd say no (because php /is/ uncommon on client systems...) - but there's also phc which *might* cure this particular problem for Phabricator. Cheers, Thomas
Re: Changes to our Git infrastructure
On Mon, 5 Jan 2015, Albert Astals Cid wrote: I think this is due to the fact that it's quite simple git clone kde:repo This requires: * setting up gitconfig with the kde: alias. That requires finding the right info on techbase, as well as the awareness that techbase exists. * figuring out the reponame for a particular project (and that isn't as easy as just downloading the entire trunk of kde's svn repo -- even if I never did that myself) do coding git commit * using the commit template * with the relevant keywords * having a grasp of what a git commit is, especially that a commit isn't visbile to anyone else git push But not before you have * realized that you need to push, i.e. what local and remote is * figured out what branches are for, and how different projects handle those * got your kde indenity * posted it on the right reviewboard * to the right reviewers Of course it's doable, but even with cats just getting source and building it poses hurdles that need articles like http://www.davidrevoy.com/article193/building-krita-on-linux-for-cats to help people jump them. I am a very fortunate and happy person: there is hardly a week when I don't have to guide someone through the process. Usually, half-way through they ask me, why doesn't KDE use github (or, less often) phabricator. Then I point them at the manifesto, and we usually spend another half hour discussing that -- most often with good results! Our story about not using github is not hard, but our contribution process often is. Obviously i think it is simple but you think it's not, i can't write a guide for dummies because i think it's simple and you can't write it because you don't know how to write it, it'd need to people to collaborate on it. If you can write somewhere your questions I'm sure we can find people to write the answers :) Cheers, Albert Having said that, the mail flood I get from Qt gerrit also isn't fun. After every comment a new review is requested... I don't have that time. Having a system where every repository (project) automatically has its own wiki and bug tracker is something I would really like to have. I think this is especially useful with the frameworks effort. I'd really like to see a homepage for each of the frameworks, and such a wiki page would be a natural place to put it. Alex
Re: Changes to our Git infrastructure
Well, _obviously_ reviewboard supports raising issues and adding comments , but neither facilitates actual conversation, i.e. discussion on what's up with a particular patch at a deeper level. In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. On Mon, 5 Jan 2015, Albert Astals Cid wrote: El Dilluns, 5 de gener de 2015, a les 18:40:54, Boudewijn Rempt va escriure: I do agree, btw, with Ian, that the current reviewboard workflow is badly broken and can be very discouraging. It doesn't support conversation What do you mean it doesn't support conversation? Cheers, Albert
